blafourcade · Oct 22, 2026 · Oct 21, 2026 · Oct 21, 2026
@@ -29,18 +29,13 @@ Auto-generated index of skills, agents, references and assets shipped by the `ai
 | Group | File | Description |
 |-------|------|---|
 | `actions` | [01-capture.md](skills/01-brainstorm/actions/01-capture.md) | - |
-| `actions` | [02-probe.md](skills/01-brainstorm/actions/02-probe.md) | - |
-| `actions` | [03-integrate.md](skills/01-brainstorm/actions/03-integrate.md) | - |
-| `actions` | [04-finalize.md](skills/01-brainstorm/actions/04-finalize.md) | - |
+| `actions` | [02-explore.md](skills/01-brainstorm/actions/02-explore.md) | - |
+| `actions` | [03-conclude.md](skills/01-brainstorm/actions/03-conclude.md) | - |
 | `assets` | [discovery-brief.md](skills/01-brainstorm/assets/discovery-brief.md) | - |
-| `references` | [completion-options.md](skills/01-brainstorm/references/completion-options.md) | - |
 | `references` | [discovery-map.md](skills/01-brainstorm/references/discovery-map.md) | - |
-| `references` | [interview-depth.md](skills/01-brainstorm/references/interview-depth.md) | - |
 | `references` | [persistence.md](skills/01-brainstorm/references/persistence.md) | - |
 | `references` | [probing.md](skills/01-brainstorm/references/probing.md) | - |
-| `references` | [question-angles.md](skills/01-brainstorm/references/question-angles.md) | - |
-| `references` | [readiness.md](skills/01-brainstorm/references/readiness.md) | - |
-| `-` | [SKILL.md](skills/01-brainstorm/SKILL.md) | `Clarify a vague product or technical intent through natural discovery. Use when the user has a half-formed idea, ambiguous request, or asks to brainstorm, discover, refine, or clarify. Not for artifact gap scans, planning, or code.` |
+| `-` | [SKILL.md](skills/01-brainstorm/SKILL.md) | `Clarify a vague idea through questions. Use when the user has a half-formed idea, ambiguous request, or asks to brainstorm, discover, refine, or clarify. Not for artifact gap scans, planning, or code.` |
 
 #### `skills/02-challenge`
 

@@ -1,34 +1,29 @@
 ---
 name: 01-brainstorm
-description: Clarify a vague product or technical intent through natural discovery. Use when the user has a half-formed idea, ambiguous request, or asks to brainstorm, discover, refine, or clarify. Not for artifact gap scans, planning, or code.
+description: Clarify a vague idea through questions. Use when the user has a half-formed idea, ambiguous request, or asks to brainstorm, discover, refine, or clarify. Not for artifact gap scans, planning, or code.
 argument-hint: idea
 ---
 # Brainstorm
 
+## Actions
+
 ```mermaid
 flowchart LR
-  capture --> probe --> integrate
-  integrate -->|"open fork"| probe
-  integrate -->|"clear enough"| finalize
-  finalize -->|"user wants more"| probe
+  capture["capture<br>actions/01-capture.md"] --> explore["explore<br>actions/02-explore.md"]
+  explore -->|"ask questions"| user((user answers))
+  user --> explore
+  explore -->|"clear enough, or user stops"| conclude["conclude<br>actions/03-conclude.md"]
+  conclude -->|"correct: revise, show again"| conclude
+  conclude -->|"explore more"| explore
+  conclude -->|"approve: offer where to keep it"| persist["persistence<br>references/persistence.md"] --> done((done))
 ```
 
-## Actions
-
-Run the flow above. Read only the next action's file before running it.
-
-| Action | Does |
-| ------ | ---- |
-| capture | restate the idea and pick what matters next |
-| probe | ask the next useful questions |
-| integrate | fold answers and decide whether to continue |
-| finalize | produce the approved refined idea |
+Each box is a file: read it, then do what it says.
 
 ## Transversal rules
 
-- Clarify intent, never plan, build, or code.
-- Ask only questions that can change what gets built.
-- Flag assumptions as assumptions.
-- State a leaning and its tradeoff when facts already point one way.
-- Hide process words: no density, coverage, nodes, completeness, matrix, or frame unless the user asks for an audit.
-- Wait after questions, approval, and persistence choices.
+- Clarify only: never plan or code.
+- Ask a question only if its answer changes the outcome.
+- Talk about the idea, never the skill's steps or files.
+- After questions, approval or persistence options, wait.
+- When the user wants to stop or asks for a summary, go to conclude and produce the brief in the chat.
@@ -1,29 +1,17 @@
 # 01 - Capture
 
-Restate the idea and pick what matters next.
-
-## Goal
-
-Start from the user's words without turning them into a solution.
+Understand the idea.
 
 ## Input
 
-The user's idea, however vague, at any level.
+The user's idea, however vague.
 
 ## Process
 
-1. **Require.** If no idea is present, ask for one and wait.
-2. **Restate.** Capture the idea in short bullets, preserving uncertainty.
-3. **Scan.** Apply [interview depth](../references/interview-depth.md) and [discovery map](../references/discovery-map.md) silently.
-4. **Open.** Hand the highest-impact open point to probe.
+1. With no idea, ask for one and stop.
+2. Say the idea back briefly, in the user's words, keeping what is still uncertain.
+3. Go to explore.
 
 ## Output
 
-The idea so far and first open point.
-
-## Test
-
-- The first open point is known before probing.
-- With no idea, the action asks for one and stops.
-- User-facing text does not expose process labels.
-- No solution, plan, or code is committed.
+The idea said back.
@@ -0,0 +1,26 @@
+# 02 - Explore
+
+Clarify the idea through questions until it is clear enough to conclude.
+
+## Input
+
+The conversation so far.
+
+## Process
+
+1. Take stock: what is clear, what is assumed and why, what is open.
+2. If no point in the [discovery map](../references/discovery-map.md) could still change the outcome, propose concluding.
+3. Otherwise, pick the next point: what the last message opened, or the next one in the map.
+4. Ask about it with the [probing techniques](../references/probing.md) that fit.
+5. Wait for the answer, then repeat from step 1.
+
+## Output
+
+A few focused questions on one point.
+
+## Rules
+
+- On a contradiction, ask which one stands.
+- When facts converge, state your leaning and its tradeoff.
+- Stay at the user's level; leave the how to planning.
+- Sound like a conversation, not a form.
@@ -0,0 +1,24 @@
+# 03 - Conclude
+
+Produce the approved refined idea.
+
+## Input
+
+The conversation so far.
+
+## Process
+
+1. Fill the [discovery brief](../assets/discovery-brief.md).
+2. Show it and ask to approve, correct, or explore more.
+3. On a correction, revise it and show it again.
+4. To explore more, go to explore.
+5. On approval, offer where to keep it, per [persistence](../references/persistence.md).
+
+## Output
+
+The approved brief.
+
+## Rules
+
+- Write the brief's bullets as facts about the idea, not as a list of categories.
+- Write nothing unless the user chooses it.
@@ -2,16 +2,16 @@
 
 # <Idea title>
 
-<One or two natural paragraphs that make the idea clear to someone who missed the conversation. Include who it is for, what should happen, why it matters, and the strongest boundaries or constraints.>
+<One sentence: who it is for, what changes, why it matters.>
 
-## What Is Clear
+## Clear
 
-- <Decision, behavior, boundary, evidence, or constraint that changes what gets made.>
+- <Decision, behavior, boundary, or done signal that changes what gets made.>
 
-## Still Open
+## Assumed
 
-- <Only unresolved assumptions, risks, or deferred build-changing decisions.>
+- <Default taken, and why. The user can correct it.>
 
-## Next Move
+## Open
 
-<Plain-language next step. No plugin or skill name.>
+- <Question whose answer could change what gets made.>
@@ -1,25 +1,29 @@
 # Discovery Map
 
-Use this map internally to decide what matters. Do not print labels, branches, or tables unless the user asks for an audit view.
+Use this map to decide what to explore next.
 
-## Core Points
+Go down the list and take the first point still unclear. Ask with one of its angles, only when it fits.
 
-| Point | Means | Depends on |
-| ----- | ----- | ---------- |
-| A | outcome, actor, pain, desired change | - |
-| B | trigger, flow, visible behavior | A |
-| C | scope, non-goals, smallest useful slice | A, B |
-| D | inputs, state, API, permissions, invariants | B, C |
-| E | acceptance, metric, observable done signal | A-D |
-| F | edge case, dependency, rollout, operational risk | C-E |
+In the first round, a vague idea (a topic or a solution only) starts at the first point with one example. A precise one (most points there) starts at its single riskiest gap.
 
-## Transversal Branches
+## Points
 
-Open one only when it can change a core point.
+| Means | Angle |
+| ----- | ----- |
+| actor, pain, desired change | who benefits, what changes, why now? |
+| trigger, steps, visible behavior | one case that should work, one that should not |
+| non-goals, smallest useful slice | the smallest useful version, where this stops |
+| inputs, state, API, permissions, invariants | dependency, platform, cost, latency, security, ownership |
+| acceptance, metric, observable done signal | what proves it works, what fails the idea? |
+| edge case, dependency, rollout, operational risk | empty, duplicate, concurrent, stale, missing, hostile, partial |
+
+## Beyond the list
+
+Open one only when it can change a point above.
 
 | Branch | Use for |
 | ------ | ------- |
-| T | technical or operational tradeoff |
-| CB | codebase boundary or ownership |
-| TS | type, schema, service, or data contract |
-| CP | change path, compatibility, migration, or rollout |
+| Tradeoff | technical or operational tradeoff |
+| Codebase boundary | codebase boundary or ownership |
+| Data contract | type, schema, service, or data contract |
+| Change path | change path, compatibility, migration, or rollout |
@@ -1,14 +1,9 @@
 # Persistence
 
-Persist only after the user approves the brief and chooses a destination.
+Where the approved brief can live.
 
-## File
-
-- Create a new dated task folder by default: `aidd_docs/tasks/<yyyy_mm>/<yyyy_mm_dd>_<slug>/brainstorm.md`.
-- Reuse an existing folder only when it is clearly the same current work.
-- When a folder is stale, ambiguous, or already has `brainstorm.md`, ask before updating.
-- Offer a new dated brief instead of touching an old file when in doubt.
-
-## Ticket
-
-Hand off to the project's ticketing capability when one exists. Do not create or update a ticket silently.
+| Destination | Do |
+| ----------- | -- |
+| Conversation | Keep it in the chat. |
+| File | `aidd_docs/tasks/<yyyy_mm>/<yyyy_mm_dd>_<slug>/brainstorm.md`, with `status: approved`. Ask first if the folder is not clearly this work or already has one. |
+| Ticket | Hand it to the project's ticketing tool. |
@@ -1,13 +1,15 @@
 # Probing
 
-Probe the live fork, not the whole map.
+Techniques to sharpen a question when the live point needs it. 
 
-Rules:
+| Technique | Use when | Example question |
+| --------- | -------- | --- |
+| Name the fork | two outcomes are still possible | "Is it X or Y?" |
+| Force a choice | a fork is unranked | "If only one could stay, which?" |
+| Reach the outcome | the idea is a solution | "What does this get you?" |
+| Alternatives | the user holds to one solution | "What else would get the same result?" |
+| Hidden assumption | success is taken for granted | "What must be true for this to work?" |
+| Limits | limits are unsaid | "What must it never do?" |
+| Premortem | a risk matters | "It shipped and failed: why?" |
 
-- Ask at the user's altitude: product, technical, operational, or mixed. Leave finer how-to as a flagged assumption for planning.
-- Follow the thread opened by the last answer before switching points.
-- Name the fork when two different outcomes are still possible.
-- Ask for examples when a word can mean two things.
-- Challenge a solution-shaped idea by asking what outcome it serves.
-- Use premortem for risk: shipped, failed, why?
-- Stop when remaining gaps are explicit assumptions, not hidden ambiguity.
+Adapt the example question to the idea.