diff options
| -rw-r--r-- | .claude/commands/brainstorm.md | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/.claude/commands/brainstorm.md b/.claude/commands/brainstorm.md index b22196d..c2b57e6 100644 --- a/.claude/commands/brainstorm.md +++ b/.claude/commands/brainstorm.md @@ -36,6 +36,7 @@ Dialogue, not interrogation. Before the first question, read the project context - **Prefer multiple choice.** Easier to answer, faster to skim, surfaces the option space for free. - **Open-ended when the option space is too large to enumerate.** Then refine with follow-ups. - **Focus the first questions on purpose, not mechanism.** Mechanism comes in phase 2. +- **Timebox the dialogue.** One-question-at-a-time sharpens the idea, it isn't an open-ended interview. Aim to reach the one-sentence restatement in roughly five to eight questions. Once you have enough to state the idea back, move to Phase 2 even with some topics unresolved — park the rest as open questions rather than stretching the dialogue for completeness. **Topics to cover (not a script — skip what's already clear):** @@ -72,6 +73,8 @@ Why tail samples matter: most teams converge on the first conventional option. T - What's being traded away - What becomes an open decision for `arch-decide` later +**Ground high-stakes claims in fresh sources.** A consequential design rests on claims about the world — what a market does, what a regulation requires, what a tool, vendor, or current API supports. Those age and are easy to misremember. Check anything load-bearing against a current source before it shapes the recommendation, and mark what you couldn't verify as an assumption rather than a fact. An unchecked "X can't do Y" that turns out wrong can steer the whole design off a cliff. + ### Phase 3 — Present the Design Once a direction is chosen, describe it in **200-300 word chunks**. After each chunk, ask "does this look right so far?" Never dump a wall of design prose — the user skims walls. @@ -107,6 +110,10 @@ One paragraph. What, who, why now. Bullet list of what this explicitly does not address. Prevents scope creep. +## Assumptions + +The load-bearing claims this design rests on, each marked as a **researched fact** (with its source) or an **assumption** (unverified, to confirm before building). Keeps a reader from mistaking a guess about a market, regulation, tool, vendor, or API for a checked fact. + ## Approaches Considered ### Recommended: <name> |