idea-brainstorm

name	idea-brainstorm
description	Use this skill when a user shares multiple ideas, features, or rough concepts — as a numbered list, bullet points, or loose collection — and wants them organized into structured documents. Trigger when the user has 3+ raw items and asks to: organize/整理 them, group by theme/按主题分类, expand into vision docs/展开分析, assess feasibility/可行性, write user stories, prioritize, or turn rough notes into proper specs. Covers brainstorm dumps, feature wishlists, user feedback batches, project vision lists, and whiteboard outputs. Also trigger when someone describes having collected many ideas (e.g. 'I have 20 ideas', '收集到30多条反馈') even before listing them all. Key pattern: multiple loosely-related items in → structured thematic analysis out. Do NOT use for: single-feature design docs, competitive analysis, code generation, PR reviews, or general Q&A.
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, Task, WebSearch, WebFetch

Idea Brainstorm Skill

Turn a messy pile of ideas into structured, cross-referenced vision documents that are ready for team discussion and prioritization.

Why this skill exists

Raw brainstorm ideas are cheap to generate but expensive to evaluate. A list of 30 bullet points is psychologically overwhelming — nobody reads it carefully, priorities stay fuzzy, hidden dependencies go unnoticed, and the best ideas drown alongside the mediocre ones. This skill bridges the gap between "we had a brainstorm session" and "we have a clear picture of what's possible, what depends on what, and what questions we need to answer."

What you produce

Given N raw ideas (typically 10-50), you produce:

1. README.md — Master index with idea-to-document mapping, a quick-reference table of ALL ideas, key cross-cutting concepts, and a suggested reading order
2. K thematic documents (typically 4-8) — Each covers a cluster of related ideas, expanded into full analysis
3. Each idea within a document gets:
   • Verbatim original quote (blockquote, preserved exactly as the user wrote it)
   • Problem definition — What pain does this address? Why does it matter?
   • User story — "As a [role], I want [capability], so that [value]"
   • Expected outcomes — Concrete day-in-the-life scenario, step by step
   • Technical direction — Architecture sketch with mermaid diagrams where helpful
   • Dependencies & prerequisites — What must exist first? Table format
   • Complexity assessment — Low/Medium/High with explanation of key risks
4. Cross-references — Ideas that relate across documents are explicitly linked
5. Probing questions — 10-15 tough questions per document, designed to surface hidden assumptions and force concrete decisions

Workflow

Phase 0: Understand context

Before touching the ideas, understand the project they belong to.

• Read the project's CLAUDE.md, README, architecture docs — whatever gives you the lay of the land
• If no project context exists (standalone brainstorm), ask the user for a 2-3 sentence description of what this is for
• This context shapes every expansion: user stories need realistic roles, technical directions need to fit existing architecture, dependencies need to reference real components

Phase 1: Ingest and cluster

Read all raw ideas. Then cluster them by thematic affinity — NOT by superficial keywords, but by the underlying concerns they address.

Clustering heuristics:

• Ideas that would be implemented by the same team or in the same codebase area → same cluster
• Ideas that share dependencies or prerequisites → same cluster
• Ideas that represent different aspects of the same user need → same cluster
• Aim for 4-8 clusters. Fewer than 4 means your clusters are too broad to be useful. More than 8 means you're over-splitting

Cross-cluster ideas: Some ideas genuinely span multiple themes. Don't force them into one cluster — mention them in their primary cluster with full analysis, and add cross-references in secondary clusters.

Output a clustering proposal and confirm with the user before proceeding. Format:

Proposed clustering (K clusters from N ideas):

1. [Theme Name] — Ideas #X, #Y, #Z
   Core concern: [one sentence]

2. [Theme Name] — Ideas #A, #B
   Core concern: [one sentence]

...

Cross-cluster: Idea #M spans clusters 2 and 5 (primary: 2)

Does this grouping make sense? Want to adjust anything?

Phase 2: Parallel expansion

After the user confirms clustering, expand all clusters in parallel using subagents (one per cluster). This is the most time-intensive phase and parallelism matters — 6 clusters done sequentially takes 6x longer.

Each subagent receives:

• The full project context from Phase 0
• Its assigned cluster of ideas (with original text)
• The complete idea list (so it can create cross-references)
• The document template (see references/document-template.md)
• The output path

Subagent prompt template:

You are expanding a cluster of brainstorm ideas into a structured vision document.

Project context:
[insert context from Phase 0]

Your cluster: "[Theme Name]"
Your ideas: [list with original text]

All ideas (for cross-referencing): [complete list with cluster assignments]

Write the document following this structure:
[insert template from references/document-template.md]

Key rules:
- Preserve every original idea's text as a blockquote, exactly as written
- User stories must use the "As a [role], I want [X], so that [Y]" format
- Technical direction should include mermaid diagrams for non-trivial architectures
- Dependencies table: columns are Dependency, Status, Description
- Complexity: rate Low/Medium/High and explain the key risk factors
- Cross-reference related ideas in other clusters using "[see XX-theme-name.md, Idea #N]" format
- Write in the same language as the original ideas

Save to: [output_path]/[NN]-[theme-slug].md

Phase 3: Cross-reference pass

After all cluster documents are written, do a cross-reference pass:

• Read all documents
• Identify any missing cross-references
• Add a "Key architectural concepts (cross-document)" section to README.md for concepts that appear in 3+ documents

Phase 4: Build the index

Create README.md with:

1. Header with date, status, source description
2. Idea-to-document mapping table
3. Full idea quick-reference table (every idea, one-line summary, document assignment, core direction)
4. Key cross-cutting concepts (with links to where each is defined)
5. Suggested reading order
6. Relationship to existing project plans/roadmaps (if applicable)

Phase 5: Probing questions

For each thematic document, generate 10-15 probing questions. These are NOT softballs — they should:

• Challenge hidden assumptions ("You assume X, but what if Y?")
• Force scope decisions ("Is this MVP or Phase 2?")
• Expose missing stakeholders ("Who maintains this after it ships?")
• Probe technical feasibility ("What happens when Z fails?")
• Question ROI ("Is the complexity justified for the expected usage?")
• Surface conflicts between ideas ("Idea #3 assumes A, but Idea #7 assumes not-A")

Add questions as a final section (## N. 待讨论问题 or ## N. Discussion Questions) in each document.

Phase 6: Present results

Summarize what was produced:

• Number of ideas processed
• Number of thematic documents created
• Total questions generated
• Key cross-cutting themes discovered
• Suggest which document to read first and why

Output directory structure

[output-dir]/
├── README.md                          # Master index
├── 01-[theme-slug].md                # Thematic document 1
├── 02-[theme-slug].md                # Thematic document 2
├── ...
└── NN-[theme-slug].md                # Thematic document N

Naming conventions

• Document filenames: NN-kebab-case-theme.md (NN = zero-padded sequence)
• Headings within documents use Chinese section numbers (一、二、三...) if ideas are in Chinese, Roman numerals or plain numbers otherwise
• Idea references: 想法 N or Idea #N matching the original numbering

Language

Match the language of the original ideas. If ideas are in Chinese, all analysis is in Chinese. If mixed, default to the dominant language. Technical terms (mermaid, YAML, API) stay in English regardless.

Handling edge cases

Fewer than 5 ideas: Skip clustering. Write a single document with all ideas expanded, still with full analysis per idea.

More than 50 ideas: Do a pre-clustering pass — group into rough buckets of ~30, then apply the normal workflow within each bucket. Or ask the user if they want to prioritize a subset first.

Vague ideas ("make it better", "improve UX"): Don't skip them. In the Problem Definition, explicitly call out the vagueness and propose 2-3 concrete interpretations. Add a question in the probing section asking the user to clarify.

Duplicate or overlapping ideas: Merge them in the same section, noting that multiple original ideas converge on the same concept. Preserve both original quotes.