mhylle/claude-skills-collection/brainstorm

Brainstorm

<!-- contents: generated by tests/skill_structure.py --write; edit headings, not this block -->

Contents

• How this skill runs
• Phase 1: Capture and classify
• Phase 2: Socratic clarification
• Phase 3: Research, when it adds something
• Phase 4: Focused analysis
• Phase 5: Write the brainstorm
• Before you finish

Reference files (open one when a step points to it):

• references/frameworks.md: Analysis Frameworks
• references/output-template.md: Brainstorm Output Template
• references/questioning.md: Socratic Questioning
• references/research.md: Research Briefs

<!-- /contents -->

Turn a rough idea into a concept that is ready to plan, by asking good questions, bringing in the facts that matter and applying the one or two analysis frameworks that fit. The guiding rule: adapt the analysis to the idea, not the idea to the analysis. A risky migration needs a premortem, not SCAMPER; a product feature needs SCAMPER, not a risk table.

How this skill runs

• Inline, with the user. It waits for answers, writes a file and offers follow-up skills, so it runs in the main conversation. Don't add context: or agent: keys to the frontmatter.
• One session, one document. The result is docs/brainstorms/YYYY-MM-DD-<topic-slug>.md. If the argument is a path to an earlier brainstorm, or one on the same topic already exists in docs/brainstorms/, read it and continue from its open gaps instead of starting over.
• Start talking, not announcing. No scripted opener. If the user has described the idea, play back your understanding and ask the first questions; if not, ask what they're thinking about.
• Use what the conversation already holds. If the idea, constraints or decisions were discussed before this skill was invoked, build on them and don't ask again.

Phase 1: Capture and classify

Pin down the core concept, the stated goals, the constraints (said or implied), whether it touches an existing codebase, and the idea type. The type drives framework choice in Phase 4.

Two more checks:

• Codebase context. If the user names files, modules or features, talks about "the current system", or wants to extend something that exists, plan codebase research for Phase 3.
• Size. If the idea spans several problem domains, more than five or six major components or stakeholders, or a multi-month timeline, say so and agree with the user which angles this session covers. The rest become Gaps in the output, with status Needs More Exploration, ready for another session.

Play your understanding back in a few lines, then move to Phase 2.

Phase 2: Socratic clarification

Ask in rounds of two to four questions, mixing the categories: scope, assumptions, alternatives, consequences, evidence, and occasionally whether this is the right problem at all. Question bank and pacing → references/questioning.md.

• Build on the previous answers rather than working through a list; ask "what" and "how" more than "why"; acknowledge a good insight before probing further.
• Hold criticism back until Phase 4. Here you are understanding, not judging.
• Keep a parking lot: tangents and "we could also…" ideas that aren't central. They go into the output so good ideas aren't lost.
• Ask in plain text. Open questions don't fit a multiple-choice picker.
• After each round, say what you'd still like to probe and let the user choose: keep going, or move to analysis. Continue until they are ready; there is no minimum number of rounds, and no reason to hurry them.

Phase 3: Research, when it adds something

Research only what the brainstorm needs. Most ideas benefit from a look at external practice and prior art; purely internal ones may not. Codebase research is for ideas that touch existing code.

When this collection is installed as a plugin, the agents are named devflow:<name>. Send all the research you need in one message so the agents run in parallel, and keep working with the user while they run. Ready-to-use briefs and how to fold the results in → references/research.md. Research informs the discussion; it doesn't replace the user's thinking, so bring the findings back as input for them to react to.

Phase 4: Focused analysis

Pick one framework, or two when the idea clearly needs both. Running every framework on every idea produces filler.

How to run each one, and the prompts → references/frameworks.md. Skip hats or letters that produce nothing for this idea. Share the main findings with the user before writing; they often correct or sharpen them.

Phase 5: Write the brainstorm

Write docs/brainstorms/YYYY-MM-DD-<topic-slug>.md (create the directory if needed), or update the earlier file when continuing one. Template and section rules → references/output-template.md. Include only sections with real content.

Set the status honestly:

• Ready for Planning when the scope is clear, the key choices are made and no gap blocks a plan.
• Needs More Exploration otherwise, and say exactly what is missing.

Then:

1. Give the path and a summary of three to five lines: the refined idea, the decisions, the biggest risk, open gaps.
2. Offer the next step that fits: /create-plan <file>, or /tt-create-plan <file> when the project is tracked in TaskTracker; /user-story <file> when the user wants requirements first; another /brainstorm <file> session when the status is Needs More Exploration.
3. Offer /adr only if a real architectural or strategic decision was made during the session, such as choosing between competing approaches.

Before you finish

• The user's answers, not your assumptions, shaped the refined idea.
• The frameworks fitted the idea type, and only useful findings were kept.
• Every risk has a mitigation and every gap a suggested next step.
• The parking lot is in the document.
• The file is written and the status matches what is actually settled.