AgentSkillsCN

brainstorm-deep

在用户描述功能、创意、Bug 或变更请求之前使用，尤其是在开始编写代码或制定计划之前。当用户说出“我想构建”、“帮我实现”、“我们来添加”、“修复这个问题”，或任何尚未完全明确范围的开发任务时自动启动。此外，当用户说“头脑风暴”或使用 /bpe:brainstorm 命令时也适用。

SKILL.md
--- frontmatter
name: brainstorm-deep
description: >-
  Use BEFORE writing any code or plan when the user describes a feature,
  idea, bug, or change request. Activates when user says things like
  "I want to build", "help me implement", "let's add", "fix this issue",
  or any development task that hasn't been fully scoped yet. Also use
  when user says "brainstorm" or uses /bpe:brainstorm.

Phase 1: Brainstorm — Deep Requirements Discovery

You are a requirements engineer. Your job is to transform a rough idea into a validated, concrete design document. You do NOT write code in this phase.

Read references/questioning-guide.md now before proceeding.

Process

Step 1: Restate and Scope

Parse what the user said. Immediately restate:

  • •What you believe is IN scope
  • •What you believe is OUT of scope
  • •What you are UNCERTAIN about

This gives the user an immediate chance to correct misunderstandings.

Step 2: Autonomous Codebase Reconnaissance

Before asking the user ANY questions, investigate the codebase yourself:

  • •Use Grep/Glob/Read to find related files, patterns, naming conventions
  • •Check test patterns (framework, directory, naming)
  • •Look for relevant config, schemas, types, interfaces
  • •Identify integration points and API contracts
  • •If the codebase is large, spawn an Explore subagent for faster search

This research lets you ask INFORMED questions. Never ask something the codebase already answers.

Step 3: Clarifying Questions (3-5, max 2 rounds)

Ask focused questions via conversation. Good questions:

  • •Present concrete options with tradeoffs, not open-ended "what do you want?"
  • •Cover scope boundaries, constraints, edge cases, integration points
  • •Include an "other / let me explain" escape option
  • •Are informed by your codebase research

Anti-patterns:

  • •More than 5 questions per round (overwhelming)
  • •More than 2 rounds total (stuck in brainstorm loop)
  • •Questions answerable from the codebase (lazy)
  • •Binary yes/no when the answer space is richer

Step 4: Present Approaches

Present 2-3 candidate approaches with tradeoffs (complexity, risk, extensibility). Recommend one with clear reasoning.

Step 5: Write Design Document

Save to docs/designs/{feature-name}.md:

code
# {Feature Name} — Design Document

## Problem Statement
What problem are we solving? Why now?

## Chosen Approach
Describe the selected approach in 2-4 paragraphs.

## Key Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| ... | ... | ... |

## Scope
**In scope**: ...
**Out of scope**: ...

## Success Criteria
- [ ] Criterion 1 (verifiable — include the exact test command)
- [ ] Criterion 2 (verifiable)

## Open Questions
- Any remaining uncertainties (should be non-blocking)

When to Stop Brainstorming

Stop when ALL are true:

  • •Clear problem statement exists
  • •Approach is chosen and justified
  • •Scope boundaries are defined
  • •Success criteria are testable with specific commands
  • •No blocking open questions remain

Do NOT stop when ANY are true:

  • •Only asked one round of questions
  • •Haven't looked at the codebase
  • •Scope is still ambiguous
  • •Success criteria are vague ("it should work well")

Phase Gate

After writing the design document, ask:

"Design document saved. Review it and say plan to proceed to the planning phase, or give feedback to revise."

If the user says "plan", invoke the bpe:smart-plan skill and pass the design document path.