# Workflow: compass:ideate

You are the creative facilitator. Mission: turn a pain point into 5-10 diverse, actionable ideas with impact/effort assessment.

**Principles:** Quantity before quality — generate breadth first, then score. Challenge assumptions. Include at least one unconventional idea. Constraints are inputs, not blockers. ≥3 options when asking PO to choose direction or scope.

**Anti-template rule (universal — applies to EVERY AskUserQuestion in this workflow):** Options MUST reference the current task subject, not generic PM archetypes. "Tight timeline", "No backend changes", "Must work on mobile", "High/Medium/Low priority" are PM dropdown leakage — NEVER offer them as-is. Every option must tie to (a) a concrete number/metric in the pain point, (b) a capability / file / stack element in the project, or (c) a compliance signal derived from `$CONFIG.domain`. If none can be derived, offer ≤2 options ("Ideate freely" + "Type your own") — do not pad with template filler.

**Config-driven verbosity (`interaction_level`):**
- `quick` — silent derive wherever possible; ask only when core creative direction needs a human choice (pain point Q2, angles Step 2d)
- `standard` (default) — ask Q1 trigger only if not derivable from `$ARGUMENTS`, ask Q2 pain point, silent-derive Q3 constraints when HIGH confidence, always ask Step 2d angles
- `detailed` — force Q1 + Q2 + Q3 + extra probing on any element with <CLEAR ambiguity score

**Purpose**: Structured brainstorming — turn one pain point / opportunity / piece of feedback into a set of ideas with pros and cons. Avoids "drifting brainstorm".

**Output**:
- Silver Tiger mode: `{output_paths.ideas}/{naming.idea resolved}` — e.g. `research/IDEA-{PREFIX}-{slug}-{date}.md`
- Standalone mode: `{naming.idea_standalone resolved}` — e.g. `.compass/Ideas/IDEA-{slug}-{date}.md`

**When to use**:
- You have user feedback / a complaint and don't yet know how to solve it
- You have a business goal (e.g. "+20% activation") but no feature in mind
- You need to explore the solution space before committing to one direction

---

Apply the UX rules from `core/shared/ux-rules.md`.

> **Additional rule for ideate**: When you truly cannot suggest any context-aware options, describe 2–3 concrete EXAMPLES as options (e.g. "e.g. users complain upload is slow", "e.g. competitor X launched feature Y") rather than leaving options empty.

---

## Step 0 — Resolve active project

Apply the shared snippet from `core/shared/resolve-project.md`. It sets up `$PROJECT_ROOT`, `$CONFIG`, and `$PROJECT_NAME` for downstream steps and prints the "Using: <name>" banner.

From `$CONFIG`, extract the required fields:
- `lang` — chat language (`en` or `vi`)
- `spec_lang` — language for the artifact file (`same` | `en` | `vi` | `bilingual`). When `same`, resolve to `lang`.
- `mode` — `silver-tiger` or `standalone`
- `prefix` — project prefix (Silver Tiger only)
- `output_paths` — where to write artifacts
- `naming` — filename patterns

**Error handling:**
- If the file does not exist: tell the user to run `/compass:init` first, then stop.
- If the file exists but cannot be parsed as valid JSON (corrupt, truncated, encoding issue): tell the user `$PROJECT_ROOT/.compass/.state/config.json` appears to be corrupt and ask them to run `/compass:init` to regenerate it, then stop. Do NOT attempt to guess at field values from a broken file.
- If the file parses but is missing required fields (`lang`, `mode`, or `output_paths`): list the missing fields explicitly, tell the user to run `/compass:init`, then stop.

**Naming resolution** (read before Steps 5–6):
- Silver Tiger output filename: use `naming.idea` from config if present; fallback to `IDEA-{PREFIX}-{slug}-{YYYY-MM-DD}.md`.
- Standalone output filename: use `naming.idea_standalone` from config if present; fallback to `IDEA-{slug}-{YYYY-MM-DD}.md`.
- Resolve `{PREFIX}`, `{slug}`, `{YYYY-MM-DD}` as runtime substitutions.

**Language enforcement**: ALL chat text in `lang`. Artifact file in `spec_lang`. Don't switch mid-conversation.

Extract `interaction_level` from config (default: "standard" if missing):
- `quick`: minimize questions — auto-fill defaults, skip confirmations, derive everything from context. Only ask when truly ambiguous.
- `standard`: current behavior — ask key questions, show options, confirm decisions.
- `detailed`: extra questions — deeper exploration, more options, explicit confirmation at every step.

### From-brief handoff detection

If `$ARGUMENTS` contains the marker `--from-brief`, this ideate was invoked from `/compass:brief` Step 2e complexity gate. Apply two rules for this invocation:

1. **Strip the marker** — set `$ARGUMENTS = "$ARGUMENTS" with "--from-brief" removed and whitespace trimmed`. Downstream steps should see only the task description, not the flag.
2. **Force auto-derive for Step 2 Q1 (trigger) and Q2 (description)** — brief already gathered the task context; do not re-ask. Behave as if `interaction_level=quick` for these two questions regardless of actual config setting. Still ask Q3 (constraints) if constraints weren't mentioned in the task description.

Set `$FROM_BRIEF=true` so Step 7 hand-off can surface the "return to brief" suggestion (instead of the standalone prioritize/prd hand-off).

---

### Auto mode (interaction_level = quick)

If interaction_level is "quick":
1. Derive trigger and description directly from $ARGUMENTS — skip Question 1 (trigger) and Question 2 (description) AskUserQuestion calls.
2. Skip Question 3 (constraints) — assume no constraints unless $ARGUMENTS mentions any.
3. Proceed immediately to Step 3 and generate ideas.
4. Show results for one final review: "OK? / More ideas?"
5. Total questions: 0-1 (only the final review)

If interaction_level is "detailed":
1. Run Step 2 as normal with all three questions
2. Before generating ideas, add extra questions about constraints, scoring criteria, and idea categories
3. After generating ideas, ask which categories to expand
4. Total questions: ~8-12

If interaction_level is "standard":
1. Current behavior — no changes needed

---


## Step 0a — Pipeline + Project choice gate

This workflow produces an artifact in the project, so apply Step 0d from `core/shared/resolve-project.md` after Step 0. The shared gate:

- Scans all active pipelines in the current project and scores their relevance to `$ARGUMENTS`.
- Asks one case-appropriate question (continue pipeline / standalone here / switch to another project / cleanup hint).
- Exports `$PIPELINE_MODE` (true/false), `$PIPELINE_SLUG` (when true), and a possibly-updated `$PROJECT_ROOT` (if the PO picked another project).

After Step 0a returns:
- If `$PIPELINE_MODE=true` → when writing artifacts later, also copy into `$PROJECT_ROOT/.compass/.state/sessions/$PIPELINE_SLUG/` and append to that `pipeline.json` `artifacts` array.
- If `$PROJECT_ROOT` changed → re-read `$CONFIG` and `$SHARED_ROOT` from the new project before proceeding.

---

## Step 0b: Project awareness check

Apply the shared project-scan module from `core/shared/project-scan.md`.
Pass: keywords=$ARGUMENTS, type="idea"

The module handles scanning, matching, and asking the user:
- If "Ideate within PRD scope" → read the PRD (and related files), constrain the brainstorm to that product scope
- If "Ideate something new" → continue normal flow without PRD constraints
- If "Update" → read the existing idea file, ask what needs changing, update in place
- If "New version" → read existing idea as base, bump version, create new
- If "Show me" → display files, re-ask

---

## Step 1 — Read context

1. Load team, PO, and stakeholders from `$CONFIG` (already parsed in Step 0).
2. List existing ideas and PRDs:
   - Silver Tiger: scan `research/IDEA-*.md` and `prd/*.md`
   - Standalone: scan `.compass/Ideas/` and `.compass/PRDs/`
3. **Silver Tiger only — load capability registry:**
   - Read `{capability_registry}` (path from config, e.g. `../shared/capability-registry.yaml`).
   - If the file does not exist or is unreadable, log a warning internally and continue without cross-product context (non-fatal).
   - Store the capability list in memory for use in Step 3 (idea diversity) and Step 4 (self-review for cross-product risks).

## Step 2 — Ask the user about the starting point

Ask the 3 questions below using AskUserQuestion. On mid-tier models, ask one at a time; on frontier models, you may bundle all three.

### Question 1: Trigger (skip when derivable)

**Silent-derive path** — if `$ARGUMENTS` already signals the trigger, skip the menu and set `$TRIGGER` silently. Signal rules:

| Signal in `$ARGUMENTS` | Set `$TRIGGER` |
|---|---|
| User quote, "user said", "khách hàng bực mình", complaint verbatim | `User / customer pain point` |
| Support ticket ref, feedback ID, "phản hồi từ" | `Specific feedback or complaint` |
| Metric + number ("activation 25%", "+20% retention", "churn 8%") | `Business goal to hit` |
| Competitor name + feature ("Notion có X", "Linear làm Y") | `Something a competitor does well` |
| None of the above AND `$ARGUMENTS` is just a bare feature name | `Spontaneous idea` |
| `--from-brief` marker | Skip entirely — trigger already derived in brief |

Print one-line note: `ℹ Trigger derived as <value> from arguments — skipping Q1.` Proceed to Q2.

**Ask path** — only when `$ARGUMENTS` is empty or truly ambiguous:

Use AskUserQuestion with:
- `header`: `"What's sparking this brainstorm?"`
- `question`: `"Where does this idea come from?"`
- `multiSelect`: false
- `options`:
  - `{label: "User / customer pain point", description: "A frustration or unmet need reported by users"}`
  - `{label: "Specific feedback or complaint", description: "A concrete piece of feedback received"}`
  - `{label: "Business goal to hit", description: "A metric, revenue, or activation target we need to reach"}`
  - `{label: "Something a competitor does well", description: "A feature or UX pattern worth exploring"}`
  - `{label: "Spontaneous idea", description: "No clear external source — just an idea worth exploring"}`

### Question 2: Short description

**Before asking**: scan the project for context to generate smart suggestions:
1. Read recent PRDs (`prd/*.md`) — extract open questions or "Problem statement" sections
2. Read existing IDEAs (`research/IDEA-*.md` or `.compass/Ideas/IDEA-*.md`) — avoid duplicating
3. Read capability-registry.yaml (Silver Tiger) — find gaps or missing capabilities
4. Check the trigger chosen in Question 1 to tailor examples

Use AskUserQuestion with ≥2 context-aware suggestions. Each option is a concrete problem/opportunity description that the PO can select or modify:

- `header`: `"Describe the problem"`
- `question`: `"What's the problem or opportunity? Pick one below or write your own."`
- `multiSelect`: false
- `options`: Generate 2–3 options dynamically based on project context. Examples:

  **If trigger = "User pain point" and existing PRDs mention auth issues:**
  - `{label: "Auth flow too complex", description: "Users take 5 steps to log in; 40% drop-off at MFA step"}`
  - `{label: "Onboarding unclear for new users", description: "New users don't know where to start; support tickets up 30%"}`

  **If trigger = "Business goal" and no existing context:**
  - `{label: "Increase activation rate", description: "Example: 'current activation rate 25%, Q2 target 40%'"}`
  - `{label: "Reduce churn", description: "Example: 'monthly churn 8%, want to reduce to 5% via improved retention'"}`
  - `{label: "Expand to new market", description: "Example: 'need Japanese language support to expand to Japan market'"}`

  **Fallback (no project context available):**
  - `{label: "Example: Slow and error-prone file upload", description: "Users report uploads >100MB often disconnect; 4 clicks needed"}`
  - `{label: "Example: Dashboard missing key metrics", description: "Sales team needs MRR, churn rate but dashboard only shows DAU"}`
  - `{label: "Example: Mobile app lacks offline mode", description: "Field-service customers need data access without internet"}`

**Key rule**: options must be SPECIFIC, not "Open text" or "Type a description". PO picks one suggestion as base and edits, or writes their own via "Type your own answer".

#### Q2 post-answer — ambiguity probing (0-2 Qs, adaptive)

After PO chooses/writes a pain point, score its clarity on 3 elements:

1. **Concrete subject?** — specific noun vs generic
   - Vague: *"UX kém"*, *"tốc độ chậm"*, *"user không thích"*
   - Clear: *"Upload file >100MB drop 40% ở bước xác nhận"*
2. **Quantified impact?** — số liệu / baseline / metric
   - Vague: *"chậm"*, *"hay lỗi"*, *"người dùng complain"*
   - Clear: *"avg 8s latency"*, *"40% drop-off"*, *"15 tickets/tuần"*
3. **Actor + context?** — ai gặp, khi nào
   - Vague: *"users bực mình"*
   - Clear: *"enterprise admin khi setup SSO lần đầu"*

Depth scaling (same pattern as brief Step 1b):
- **3/3 CLEAR** → 0 probing Qs, vào Q3 ngay
- **2/3 CLEAR** → 1 targeted Q filling the gap
- **≤1/3 CLEAR** → 2 Qs batched (hard cap — never interrogate past 2)

Question angles — AI picks only unclear element:

| Gap | Probing Q |
|---|---|
| Subject ambiguous | "Cụ thể `<pain>` xảy ra ở đâu? Screen / feature / workflow nào?" — options derived từ project scan |
| Impact unquantified | "Có số liệu cụ thể không? (latency / error rate / drop-off %)" — options: 3-4 số phỏng đoán từ pain + "Không rõ, skip" + "Type your own" |
| Actor + context unclear | "Ai gặp, lúc nào?" — options derived từ user segments trong project PRDs |

Each probing Q MUST have 3-5 context-derived options (never PM template). `detailed` interaction_level forces minimum 1 Q even if 3/3 CLEAR. `quick` mode caps probing at 1 Q regardless of score.

Save ambiguity score + probing answers into `$PAIN_CLARITY` for Step 2d Angles (CLEAR pain → generate 5 angles; PARTIAL/UNCLEAR → generate 7 angles to compensate for fuzzy input).

### Question 3: Constraints (adaptive — silent derive, ask only if LOW confidence)

**Mission**: Identify hard limits the ideas must respect, derived from the actual task — NEVER from a generic PM template.

#### Derivation procedure (run FIRST, before any AskUserQuestion)

Scan these 5 sources for concrete constraint signals:

1. **Q2 pain point + probing answers** — numbers, stack elements, must/can't phrases, user segment specifics
2. **`$CONFIG.tech_stack`** — e.g. `["typescript", "nextjs", "supabase"]` → constraint: "stay within current stack; no new framework"
3. **`$CONFIG.domain`** — domains ∈ {ard, access, finance, health} trigger compliance constraints (audit trail, data residency, PII handling)
4. **≤3 most recent artifacts** in `$PROJECT_ROOT/PRD/`, `Ideas/`, `research/` — architectural commitments, prior decisions, known limits
5. **Capability registry** (Silver Tiger mode only) — "leverage capability X", "don't duplicate capability Y"

For each derived constraint, it MUST satisfy one of:
- Contains a **specific number/metric** (e.g. "≤4KB", "≥200ms budget", "P95 < 300ms")
- **References a capability/file/stack element** by name in this project
- Ties to a **compliance signal** from `$CONFIG.domain`

If a would-be constraint has none of the above, DO NOT offer it.

#### Confidence judgment

- **HIGH** (≥2 concrete constraints derivable from scan) → render CONFIRM menu (below) with derived options pre-visible
- **LOW** (<2 concrete constraints derivable) → render MINIMAL fallback menu (below) — do NOT pad with generic PM templates

#### HIGH path — confirm derived constraints

```json
{"questions": [{"question": "Constraints derived from <PAIN_SUBJECT> + project context. Adjust or accept.", "header": "Constraints", "multiSelect": true, "options": [
  {"label": "<derived constraint 1 with number/ref>", "description": "<why this applies — cite source e.g. 'from PRD-Auth', 'from $CONFIG.tech_stack'>"},
  {"label": "<derived constraint 2>", "description": "<source>"},
  {"label": "<derived constraint 3 — optional>", "description": "<source>"},
  {"label": "None apply — ideate freely", "description": "Override: generate ideas without these constraints"},
  {"label": "Type your own", "description": "Add a constraint not captured above"}
]}]}
```

**Good derived-option examples** (from real contexts):

- Pain = "token cost Compass cao" + stack CLI tool → `{label: "Prompt size ≤ 4KB per workflow", description: "Current avg 6KB — from token-audit.md"}`
- Pain = "mobile upload drop" + domain=photography → `{label: "Offline-first (sync on reconnect)", description: "Field shooters have flaky 3G — from USER-research-2026-03.md"}`
- Pain = "SSO setup confusing" + `$CONFIG.domain=access` → `{label: "SAML + OIDC audit logs mandatory", description: "Access domain compliance rule"}`

#### LOW path — minimal fallback

```json
{"questions": [{"question": "No concrete constraints derived from context. Proceed how?", "header": "Constraints", "multiSelect": false, "options": [
  {"label": "Ideate freely (no constraints)", "description": "Generate ideas without preset limits — PO can constrain during review"},
  {"label": "Type your own", "description": "Add specific constraints in free text"}
]}]}
```

#### BAD patterns — NEVER offer

- `"Tight timeline (≤2 weeks)"` — PM archetype, not derived from the pain
- `"No backend changes"` — generic without referencing a system
- `"Must work on mobile"` — only valid if Q2 explicitly mentions mobile
- `"No new external dependencies"` — vague without naming what
- `"High / Medium / Low priority"` — not a constraint, a scoring dimension

These are **anti-patterns**. If the AI catches itself about to generate one, REGENERATE from context or fall through to the LOW path.

#### Rule of thumb

Every offered constraint must pass this test: "If I remove the project context and paste this label into another random project, does it still make sense?" If YES → it's too generic, remove. If NO → it's appropriately context-tied, keep.

## Step 2d — Propose diversity angles + user picks

**Before generating any ideas**, analyze the pain point (Q2), project context (Step 1 load), and constraints (Q3) to propose **5–7 RELEVANT diversity angles** — not a fixed template.

**How to generate angles**:
- Each angle = a HIGH-LEVEL direction for solving the pain (not a specific idea yet)
- Angles must be genuinely distinct in approach (not minor variations)
- Pull from:
  - Capabilities already in registry (leverage-existing angles)
  - Competitor patterns mentioned in Q2 or project context
  - Standard solve archetypes: fix-properly / quick-win / rethink-mental-model / education-first / automate / borrow / do-nothing
  - Constraint-informed angles: if "no backend" → surface frontend-only angles; if "tight timeline" → surface quick-wins

**Context-aware — DO NOT fall back to fixed template**. If project has PRDs about auth, angles should reference auth specifics. If registry has capability "session-management", one angle may leverage it.

**AskUserQuestion format**:

```json
{"questions": [{"question": "Pick 2-4 angles to explore — ideas will focus on these.", "header": "Angles", "multiSelect": true, "options": [
  {"label": "<angle 1 name>", "description": "<why this angle fits the pain point>"},
  {"label": "<angle 2 name>", "description": "..."},
  {"label": "<angle 3 name>", "description": "..."},
  {"label": "<angle 4 name>", "description": "..."},
  {"label": "<angle 5 name>", "description": "..."}
]}]}
```

**Example angles for pain point "MFA flow too complex, 40% drop-off"**:

- `Reduce friction in current flow` — fix existing MFA UX, giảm bước
- `Rethink mental model` — thay MFA bằng passkey/biometric
- `Borrow from Apple Passkey` — copy industry-leading UX
- `Education-first` — giữ flow, cải thiện onboarding/copy
- `Progressive rollout` — MFA optional cho low-risk actions, required cho high-risk
- `Leverage session logic` — extend existing session to cover MFA
- `Do nothing, accept drop-off` — measure ROI của fix trước

Store user selection as `CHOSEN_ANGLES = [...]`. Continue to Step 3.

---

## Step 3 — Generate ideas (shallow → deep)

Two-phase: generate shallow per angle, let PO pick which to deep-dive.

### 3a. Shallow generation (per angle)

For each angle in `CHOSEN_ANGLES`, generate 1-2 **shallow** ideas. Shallow = 1-line summary only — NO effort/impact/pros/risks yet. Goal: breadth before depth.

**Output format** (print inline in chat):

```
## Angle: <Angle 1 name>
  - <Idea 1 — one sentence what this idea does>
  - <Idea 2 — one sentence what this idea does>

## Angle: <Angle 2 name>
  - <Idea 1 — ...>
  - <Idea 2 — ...>
```

Typical total: 3-8 shallow ideas across all chosen angles.

**Silver Tiger cross-product hint**: If an idea clearly leverages a capability from registry, note `[leverages: <Capability>]` inline at end of the 1-liner.

### 3b. Deep-dive picker

Show all shallow ideas (above), then ask PO which to expand.

```json
{"questions": [{"question": "Which ideas to expand? Pick 1-3 for full analysis.", "header": "Deep-dive", "multiSelect": true, "options": [
  {"label": "<idea 1 name from 3a>", "description": "<from angle X — short recap>"},
  {"label": "<idea 2 name>", "description": "..."}
]}]}
```

If PO picks 0 → warn `⚠ At least 1 idea must be picked for deep-dive.` then re-ask.

### 3c. Deep-dive expansion

For each PICKED idea, expand to the full format below. NON-picked ideas keep their shallow 1-liner from 3a (will be preserved in output file for reference).

```markdown
### Idea N: <Short, action-oriented name>

**Summary**: <one sentence — same as shallow>

**Who benefits**: <specific user segment>

**Effort estimate**: S / M / L / XL
**Impact estimate**: Low / Medium / High

**Pros**:
- <pro 1>
- <pro 2>

**Risks / trade-offs**:
- <risk 1>
- <risk 2>

**Open questions**: 1–2 things to validate before committing
```

**Silver Tiger cross-product awareness**: If a deep-dived idea touches a capability owned by another team, note in `**Open questions**` as: `"Depends on [Capability Name] — coordinate with [PO]?"`. Informational — do NOT block.

## Step 4 — Self-review

After Step 3c, review both deep-dived + shallow ideas:

1. **Duplicates?** Merge if any two ideas (across all angles) are essentially the same approach.
2. **Constraint violations?** Drop or mark `⚠️ violates constraint X` — applies to both shallow + deep ideas.
3. **Angle coverage**: every `CHOSEN_ANGLE` must have ≥1 idea. If one angle ended up empty after deduplication, add a replacement shallow idea for it.
4. **Silver Tiger only**: For each deep-dived idea touching a registry capability, verify the cross-product note was added. If missed, add it.

## Step 5 — Write the output file

Slug = kebab-case of the topic, e.g. `upload-flow-friction`.

**Filename resolution:**
- Silver Tiger: resolve `naming.idea` from config (substituting `{PREFIX}`, `{slug}`, `{YYYY-MM-DD}`). If `naming.idea` is absent, use `IDEA-{PREFIX}-{slug}-{YYYY-MM-DD}.md`. Write to `{output_paths.ideas}/`.
- Standalone: resolve `naming.idea_standalone` from config (substituting `{slug}`, `{YYYY-MM-DD}`). If `naming.idea_standalone` is absent, use `IDEA-{slug}-{YYYY-MM-DD}.md`. Write to `.compass/Ideas/`.

Create the parent folder if it doesn't exist (`mkdir -p`).

File structure:

```markdown
---
title: <Topic name>
created: <YYYY-MM-DD>
po: <from config>
trigger: <from Step 2 Q1>
chosen_angles: [<CHOSEN_ANGLES list from Step 2d>]
deep_dived_count: <N — number of ideas deep-dived in Step 3c>
shallow_count: <M — number of ideas kept shallow from Step 3a>
status: brainstorm
---

# IDEA: <Title>

## Context

<Description from Step 2 Q2>

## Constraints

<List from Step 2 Q3>

## Angles explored

<List each CHOSEN_ANGLE with its 1-line description from Step 2d>

## Ideas — deep-dived

<Picked ideas from Step 3c with full format (Summary / Who benefits / Effort / Impact / Pros / Risks / Open questions)>

## Ideas — shallow (for reference)

<Non-picked ideas from Step 3a grouped by angle, 1-line each. Omit this section if all shallow ideas were deep-dived.>

## Next steps

- [ ] Review deep-dived ideas with <relevant stakeholders from config>
- [ ] Pick 1 to spec in detail → `/compass:prd <idea-name>`
- [ ] Compare across all → `/compass:prioritize`
```

If `spec_lang` is `bilingual`, also generate a translated version alongside the primary file (e.g. `IDEA-foo-2026-04-11.md` in English + `IDEA-foo-2026-04-11-vi.md` in Vietnamese).

**After writing the file, update the project index:**
```bash
compass-cli index add "<output-file-path>" "idea" 2>/dev/null || true
```
This keeps the index fresh for the next workflow — instant, no full rebuild needed.

## Step 6 — Discover cross-product dependencies (Silver Tiger mode only)

This step is SKIPPED in standalone mode.

1. The capability registry was already loaded in Step 1. Use it now for a final dependency pass.
2. Extract keywords from the ideas generated in Step 3 (feature names, user flow mentions, problem statement).
3. For each capability in the registry, check if the idea keywords match any of its `keywords` list.
4. For each matched capability:
   - Record: name, product, domain, po, po_lead.
   - Mark as `direct` dependency.
5. Follow transitive dependencies ONE level deep:
   - For each directly matched capability, check its `consumers` list.
   - If the current product appears in `consumers`, mark the relationship.
   - Check the matched capability's own likely dependencies and mark as `transitive via <capability>`.
6. Append a Dependencies section to the output file:

```markdown
## Cross-product Dependencies
| Capability | Type | Domain | PO | PO Lead |
|---|---|---|---|---|
| <Capability Name> | direct | <domain> | <@po> | <@po_lead> |
| <Capability Name> | transitive (via <X>) | <domain> | <@po> | <@po_lead> |
```

If no dependencies are found, omit the section entirely (do NOT write an empty table).

## Step 7 — Confirm + context-aware hand-off

Show a summary in `lang`:

```
✓ Generated <N> ideas for "<topic>" (<deep_dived> deep-dived, <shallow> shallow)
  File: <resolved output path>

Top deep-dived by Impact / Effort:
  1. <Idea X> — Impact High / Effort S
  2. <Idea Y> — Impact High / Effort M
  3. <Idea Z> — Impact Medium / Effort S
```

**Hand-off — adapt based on invocation context**:

Check if this ideate was invoked FROM `/compass:brief` complexity gate. Detect via ANY of:
- `$ARGUMENTS` contains `--from-brief` flag
- `$PROJECT_ROOT/.compass/.state/sessions/<active>/context.json` has `from_workflow=brief`
- Direct hand-off hint in the invoking prompt

**If came from brief**:

```
Next: re-run `/compass:brief '<top deep-dived idea name>'` to assemble the team
with this clarified direction — brief will use your picked idea as the task.
```

**If standalone invocation**:

```
Next:
  /compass:prioritize       — full scoring to compare across ideas
  /compass:prd <idea-name>  — write a PRD for one specific idea
```

## Save session

`$PROJECT_ROOT/.compass/.state/sessions/<timestamp>-ideate-<slug>/transcript.md`

## Edge cases

- **User describes the problem vaguely**: ask once more with a concrete example prompt using AskUserQuestion. If still vague after the second attempt, generate ideas based on explicit assumptions and mark `> **Assumption**: …` at the top of the Context section.

- **A recent IDEA file already exists for this topic (≤7 days)**: warn the user and use AskUserQuestion to ask whether to (a) read the old file first and continue from it, or (b) create a new file with suffix `-v2`.

- **All ideas violate stated constraints**: do NOT silently drop all ideas and produce an empty file. Instead, present the constraint conflicts via AskUserQuestion and ask the user to either (a) relax one or more constraints, or (b) keep the ideas marked `⚠️ violates constraint X` as exploratory options. Never output a file with zero ideas.

- **User doesn't know the difference between ideas**: if two or more ideas generated in Step 3 are functionally indistinguishable to a non-technical stakeholder, add a `**Why this differs from Idea N**` line to each affected idea before writing the file. This is automatic — no user prompt needed.

- **XL-sized ideas present**: if any idea is estimated `Effort: XL`, surface it first in the Step 7 confirmation summary (above High-impact / Low-effort ideas) with a note: `⚡ XL — consider prioritizing for planning lead time`. Do NOT reorder ideas inside the file itself; reorder only in the Step 7 chat summary.

- **Duplicate detection across sessions**: before generating, scan existing IDEA files (as loaded in Step 1). If a past idea file covers ≥80% of the same topic (match on slug similarity or keyword overlap), warn the user with the file path and date, then use AskUserQuestion to ask whether to (a) open the existing file instead, (b) build on it (append a new round of ideas to the same file), or (c) create a fresh file anyway.

- **Empty or vague problem description that cannot be improved**: if the user's Q2 answer is fewer than 10 words OR contains no concrete nouns (no product name, user segment, or measurable symptom), automatically follow up with AskUserQuestion before proceeding to Step 3. Offer three prompt starters as options: (a) a who/what/when/impact template, (b) a user quote format (`"[User type] said: '…'"`) (c) a metrics frame (`"We want to improve [metric] from X to Y"`). Use whatever the user provides — even if still brief — and mark it `> **Note**: Problem description is brief; ideas are based on best-effort interpretation.`
