brainstorming-cn

Brainstorming: Turning Ideas into Requirements

Through natural collaborative dialogue, help turn rough ideas into clear, actionable product requirements.

First understand the current project context, then ask questions one by one to refine the idea. The goal is to produce a complete, unambiguous product requirements document (PRD) that answers what to build (WHAT) and why to build it (WHY). How to build it (HOW) is left to later stages.

Anti-pattern: "This is too simple, it doesn't need a PRD"

Every project goes through this process. A to-do list, a single-function tool, a configuration change—all of them need it. "Simple" projects are exactly where untested assumptions cause the most waste. A PRD can be very short (a few sentences are enough for a truly simple project), but you must write it and get approval.

Checklist

You must create a task for each of the following items and complete them in order:

Explore project context — Check files, documentation, and recent commits to understand what already exists
Provide a visual companion(if the topic involves visual issues) — This is a separate message; do not merge it with clarifying questions. See the "Visual Companion" section below
Ask clarifying questions — One at a time, to understand the purpose, users, constraints, and success criteria
Propose 2-3 requirements options — Different scope, feature priority, or user flow options, with trade-off analysis and your recommendation
Present requirements — Present them in sections by complexity, and get user approval after each section
Write the PRD — Save to docs/prd/<topic>.md and commit
PRD self-check — Quickly check inline for placeholders, contradictions, ambiguities, and scope (see below for details)
User reviews the PRD — Ask the user to review the PRD file before continuing
Transition to design — Invoke the design or implementation planning skill

Flowchart

digraph brainstorming {
    "探索项目上下文" [shape=box];
    "有视觉相关问题?" [shape=diamond];
    "提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box];
    "提出澄清问题" [shape=box];
    "提出 2-3 种需求方案" [shape=box];
    "分节展示需求" [shape=box];
    "用户批准需求?" [shape=diamond];
    "编写 PRD" [shape=box];
    "PRD 自检\n（内联修复）" [shape=box];
    "用户审查 PRD?" [shape=diamond];
    "调用 design/\n规划技能" [shape=doublecircle];

    "探索项目上下文" -> "有视觉相关问题?";
    "有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"];
    "有视觉相关问题?" -> "提出澄清问题" [label="否"];
    "提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题";
    "提出澄清问题" -> "提出 2-3 种需求方案";
    "提出 2-3 种需求方案" -> "分节展示需求";
    "分节展示需求" -> "用户批准需求?";
    "用户批准需求?" -> "分节展示需求" [label="否，修改"];
    "用户批准需求?" -> "编写 PRD" [label="是"];
    "编写 PRD" -> "PRD 自检\n（内联修复）";
    "PRD 自检\n（内联修复）" -> "用户审查 PRD?";
    "用户审查 PRD?" -> "编写 PRD" [label="要求修改"];
    "用户审查 PRD?" -> "调用 design/\n规划技能" [label="批准"];
}

The terminal state is to invoke the design or implementation planning skill. Do not invoke any implementation skill. After brainstorming, what you should invoke is the design/planning skill.

Process Details

Understand the idea:

First look at the current project state (files, documentation, recent commits)
Before asking detailed questions, first assess scope: if the requirements describe multiple independent features or user journeys (for example, "build a platform with chat, file storage, billing, and analytics"), point this out immediately. Do not spend time using questions to refine a project that needs to be split first.
If the project is too large for a single PRD to cover, help the user break it down into subprojects: what are the independent parts, how do they relate to each other, and in what order should they be built? Then brainstorm the first subproject through the normal PRD process. Each subproject has its own PRD.
For appropriately scoped projects, ask one question at a time to refine the idea
Try to use multiple-choice questions; open-ended questions are also acceptable
Ask only one question per message—if a topic needs more exploration, split it into multiple questions
Focus on understanding: who the users are, what problem is being solved, what success looks like, what the constraints are

Explore requirement options:

Propose 2-3 different requirement options. These are product/feature-level options, not technical options. For example:
- Different scope levels (MVP vs full vision vs phased rollout)
- Different user flows or interaction models
- Different feature priorities (which capabilities matter most)
- Different target users or use case priorities
Present the options in a conversational way, with your recommendation and reasoning
Present your recommended option first and explain why

Present requirements:

Once you believe you understand what is needed, present the requirements
The length of each section should match its complexity: a few sentences for simple ones, at most 200-300 words for complex ones
After presenting each section, ask whether it is correct
Cover: problem statement, target users, user stories/use cases, functional requirements, non-functional requirements (performance, accessibility, security), acceptance criteria, success metrics, out of scope items
Be ready to go back and clarify anything unclear at any time

PRD structure

A good PRD should clearly answer the following questions:

Problem statement: What problem are we solving? For whom?
Target users: Who will use this feature? Are there multiple user personas?
User stories / use cases: What do users need to accomplish? Write it in the format "As a [user], I want [to do something], so that [I achieve some result]".
Functional requirements: What must the system do? Be specific and testable.
Non-functional requirements: Performance expectations, accessibility requirements, security considerations, browser/device support.
Acceptance criteria: How do we know each requirement has been met? Use specific, verifiable statements.
Success metrics: How will we measure whether this feature is successful after launch?
Out of scope: What are we explicitly not building? This is just as important as what we are building.

After the PRD

Documentation:

Write the validated PRD to docs/prd/<topic>.md
If available, use the elements-of-style:writing-clearly-and-concisely skill
Commit the PRD to git

PRD self-check: After writing the PRD document, review it with fresh eyes:

Placeholder scan: Are there any "TBD", "TODO", unfinished sections, or vague requirements? Fix them.
Internal consistency: Are there contradictions between requirements? Are the user stories aligned with the functional requirements?
Scope check: Is this focused enough to be covered by one implementation plan, or does it need to be split further?
Ambiguity check: Are there any requirements that could be understood in two ways? If so, choose one and state it explicitly.
Testability check: Is each requirement verifiable? If you cannot describe how to test it, the requirement is too vague.

Fix issues inline as you find them. No re-review needed—fix and keep moving.

User review gate: After the PRD self-check is complete, ask the user to review the written PRD before continuing:

"PRD has been written and committed to <path>. Please review it and let me know if you want any changes before we move into design and implementation."

Wait for the user's reply. If they request changes, make the changes and re-run the PRD self-check. Only continue after the user approves.

Implementation:

The PRD is the input for the next phase: technical design and implementation planning.
Do not jump straight into coding. Invoke the appropriate design or implementation planning skill based on the project situation.

Core principles

One question at a time — do not throw out multiple questions at once
Prefer multiple choice — easier to answer than open-ended questions whenever possible
Strictly follow YAGNI — remove unnecessary features from all requirements
Focus only on WHAT, never discuss HOW — no technology choices, architecture, or code structure
Incremental validation — present requirements section by section, get approval, then continue
Stay flexible — if anything is unclear, go back and clarify
Being explicit about what is out of scope is a virtue — clearly stating what will not be built effectively prevents scope creep

Visual companion

A browser-based companion tool for showing prototypes, diagrams, and visual options during brainstorming. It is a tool—not a mode. Accepting the companion means it is available for problems suited to visual presentation; it does not mean every question must go through the browser.

Offer the companion: When you anticipate that upcoming questions will involve visual content (prototypes, layouts, user flows), offer it once to get consent:

"Some of what we discuss next may be more intuitive if I show it to you in the browser. I can create prototypes, diagrams, comparison charts, and other visual materials for you during the discussion. This feature is still fairly new and may consume more tokens. Want to try it? (Requires opening a local URL)"

This offer must be a separate message. Do not combine it with clarifying questions, context summaries, or anything else. The message should contain only the offer above, nothing else. Wait for the user's reply before continuing. If they decline, continue with text-only brainstorming.

Per-question decisions: Even if the user accepts, decide separately for each question whether to use the browser or the terminal. Criteria:Would the user understand it more easily by seeing it than by reading it?

Use the browser to present content that is inherently visual—prototypes, wireframes, layout comparisons, user flow diagrams, side-by-side feature comparisons
Use the terminal to present textual content—requirements questions, scope decisions, user story discussions, acceptance criteria, success metrics, prioritization conversations

Questions about UI themes are not necessarily visual questions. "What should the onboarding flow accomplish?" is a requirements question—use the terminal. "Which layout of the onboarding wizard feels right?" is a visual question—use the browser.

If they agree to use a companion, read the detailed guide before proceeding: skills/brainstorming-cn/visual-companion.md