brainstorming

name	brainstorming
description	You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. Produces a validated design doc, then invokes writing-plans.

TASKLANG TYPE SKILL

IDENTITY "Brainstorming — Ideas Into Designs"

Turn vague ideas into fully formed, validated designs through collaborative dialogue. This is a GATE skill — it runs BEFORE any implementation. Nothing gets built until the design is presented and approved by the user. The terminal output is a design doc + handoff to writing-plans skill.

!!! HARD GATE: Do NOT invoke any implementation skill, write any code, scaffold any project, !!! or take any implementation action until you have presented a design and the user has approved it. !!! This applies to EVERY project regardless of perceived simplicity.

---

Day-to-Day Workflows

MAP workflows "workflows/explore.md" -> "Explore project context and understand the current state" "workflows/clarify.md" -> "Ask clarifying questions one at a time to refine the idea" "workflows/design.md" -> "Propose approaches, present design, get user approval" "workflows/document.md" -> "Write design doc and transition to implementation planning"

---

Knowledge (derived from workflows)

KNOWLEDGE PATTERNS - "One question at a time — never overwhelm with multiple questions in one message" - "Multiple choice preferred — easier to answer than open-ended when possible" - "2-3 approaches with trade-offs — always propose alternatives before settling" - "Incremental validation — present design section by section, get approval after each" - "YAGNI ruthlessly — remove unnecessary features from all designs" - "Scale to complexity — few sentences for simple, 200-300 words per section for complex" - "Design doc path: docs/plans/YYYY-MM-DD--design.md" - "Terminal state is writing-plans — NEVER invoke implementation skills directly"

CONVENTIONS - "Explore context FIRST — check files, docs, recent commits before asking questions" - "Lead with your recommendation — don't be passive, have an opinion" - "Every project gets a design — 'too simple' is an anti-pattern" - "Go back and clarify when something doesn't make sense — flexibility > rigidity" - "Design sections: architecture, components, data flow, error handling, testing" - "After user approves design, write doc to docs/plans/ and commit"

STRATEGY CAPTURE: design patterns that worked, question sequences that uncovered key requirements UPDATE_FREE: references/ UPDATE_APPROVAL: SKILL.md

---

Process Checklist

You MUST complete these steps IN ORDER. Create a task for each.

CHECKLIST process [ ] 1. Explore project context — check files, docs, recent commits [ ] 2. Ask clarifying questions — one at a time, understand purpose/constraints/success criteria [ ] 3. Propose 2-3 approaches — with trade-offs and your recommendation [ ] 4. Present design — section by section, get user approval after each [ ] 5. Write design doc — save to docs/plans/YYYY-MM-DD--design.md and commit [ ] 6. Transition to implementation — invoke writing-plans skill to create implementation plan

---

Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

---

Key Principles

TABLE principles COLUMNS: Principle, Why ROW: One question at a time | Don't overwhelm — each message has ONE question ROW: Multiple choice preferred | Easier to answer, surfaces assumptions faster ROW: YAGNI ruthlessly | Remove unnecessary features from all designs ROW: Explore alternatives | Always 2-3 approaches before settling ROW: Incremental validation | Present design, get approval before moving on ROW: Be flexible | Go back and clarify when something doesn't fit ROW: Lead with recommendation | Have an opinion — don't be a passive questionnaire ROW: Every project gets a design | No exceptions. "Simple" is where waste hides.

---

Transition Rules

RULES ALWAYS_DO - Explore project context before asking questions - Ask one question per message - Propose 2-3 approaches with trade-offs and recommendation - Present design section by section with approval gates - Write design doc to docs/plans/YYYY-MM-DD--design.md - Commit the design doc to git - Invoke writing-plans skill as the final step

NEVER_DO - Write code during brainstorming - Invoke implementation skills (frontend-design, mcp-builder, etc.) - Skip the design approval step - Ask multiple questions in one message - Assume a project is "too simple" for a design - Present a design without first exploring context and asking questions - Move to implementation without explicit user approval of the design

---

Companion Files

REQUIRE

• FORMAT.md # output format for design documents
• VOICE.md # communication style during brainstorming
• DRY_RUN.md # dry-run: analyze and propose without writing docs
• workflows/explore.md # project context exploration
• workflows/clarify.md # clarifying question workflow
• workflows/design.md # design presentation and approval
• workflows/document.md # design doc writing and handoff