brainstorming

Brainstorming — Design Before Code

Register: TECHNIQUE Goal: Understand what's being built and why, produce a design both human and agent can commit to. Constraints: No code before SPEC_APPROVED: true set in spec frontmatter. Terminal state: audit-design → writing-plans. Never invoke writing-plans directly. Adapt: questions, pace, and depth to conversation — but every checkpoint must be reached.

Announce: "Using brainstorming to design before implementation."

---

Pre-check

# Load domain context if available:
!head -40 docs/superskills/CONTEXT.md 2>/dev/null || echo "No CONTEXT.md — consider running domain-alignment first for new projects"

If CONTEXT.md is missing and this is a new project or unfamiliar domain → recommend domain-alignment first. If human prefers to proceed → proceed, but note vocabulary may need alignment mid-session.

---

Checklist (complete in order)

1. Explore project context — check files, docs, recent commits, CONTEXT.md
2. Assess scope — multiple independent subsystems? Decompose first.
3. Ask clarifying questions — one at a time; purpose, constraints, success criteria
4. Propose 2-3 approaches — trade-offs + your recommendation
5. Present design — in sections, get approval after each section
6. Write design doc — save + commit
7. Spec self-review — fix placeholders, contradictions, ambiguity inline 7b. DPS SYSTEM INTENT check — C3+ only, or if project has DPS / spec will be promoted to DPS (see Step 7b below)
8. User reviews written spec — wait for explicit approval
9. Set SPEC_APPROVED — triggers audit-design

---

The Conversation

Goal: understand what's being built, why, and what success looks like. Constraints:

• One question per message — multiple choice preferred
• Don't ask for information you can infer from the codebase
• Scope before detail — if scope is unclear, ask about scope first
• YAGNI: propose the simplest approach that meets the actual need