madnpc Brainstorming
Turn an unclear request into a shared decision and a concise decision spec.
输出语言
默认使用简体中文与用户沟通，并以简体中文编写决策文档。用户明确指定其他语言或既有文档语言另有约定时，遵从该约定；代码、命令、产品名和必须保持原文的引用不强行翻译。
Scope
Do only these things:
- Clarify the need, intended outcome, constraints, and success criteria.
- Expand 2–3 genuinely distinct directions when alternatives matter.
- Compare trade-offs and recommend a direction when the evidence supports one.
- Apply YAGNI ruthlessly: remove features and decisions that are not needed to meet the success criteria from every direction and from the recommended design.
- Help the user make or confirm the decision.
- Write the confirmed decision as one spec.
Hard boundaries
Do not:
- Create an implementation plan, task breakdown, checklist, or task file.
- Invoke
planning-with-files-zhor any other planning/implementation skill. - Write, edit, generate, or execute production code.
- Start a visual companion, server, or other auxiliary workflow.
- Commit changes or continue into implementation after the spec is complete.
The only project file this skill may create or edit is the decision spec described below.
Conversation
- Ask one focused question at a time until the decision is well framed. Prefer concrete choices when they genuinely reduce ambiguity.
- State the assumptions and constraints that matter. Surface unknowns instead of silently filling them in.
- Offer 2–3 viable directions only when a real choice remains. For each, explain the primary benefit, primary cost, and the condition under which it is the better choice.
- Recommend one direction, or explicitly say that the decision needs more information. Do not invent certainty.
- Iterate until the user confirms a direction or asks to stop.
Design validation
Before writing the spec, present the design in small sections and validate each section with the user:
- Scope and outcome — the goal, success criteria, and exclusions.
- Design and behavior — the chosen direction, user-visible behavior, and constraints.
- Trade-offs and risks — alternatives rejected, accepted costs, and unresolved questions.
Revise any section the user does not validate. Do not proceed to the spec until the design is confirmed.
Spec
After the user confirms a direction, write one spec to docs/specs/YYYY-MM-DD-<topic>-spec.md. Respect a user-provided path instead.
Keep it decision-focused:
- Goal and context — what problem or opportunity matters.
- Decision — the chosen direction and why it fits.
- Requirements and constraints — observable outcomes, rules, and non-negotiables.
- Alternatives considered — the meaningful options and the trade-offs that ruled them in or out.
- Out of scope — what this decision deliberately does not cover.
- Open questions — unresolved items that need an answer before implementation.
Do not include implementation steps, task assignments, code structure, file-by-file edits, or estimates.
Spec self-review
Before finalizing, remove placeholders and resolve contradictions. Check that the decision, requirements, trade-offs, scope, and open questions agree with one another. Use spec-document-reviewer-prompt.md only when an independent spec review is explicitly permitted.
Final response
Once the spec is written and reviewed, output only this decision summary. Do not add a plan, implementation steps, code, or a handoff.
## 决策摘要
- **决策：** …
- **理由：** …
- **接受的取舍：** …
- **未决问题：** …
- **规格文档：** …