# 01 Brainstorm

> Discover requirements through structured multi-round dialog. Use when the request is ambiguous, needs discovery, or describes a new idea/product.

- Skill: `leing2021/01-brainstorm` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add leing2021/01-brainstorm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leing2021/01-brainstorm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: leing2021 (https://skillmd.com/u/leing2021)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leing2021/01-brainstorm

---


# Brainstorm

Use this skill when the request is ambiguous, needs requirements discovery, or the user describes a new idea/product.

See [shared pipeline instructions](../references/pipeline-config.md) for model routing and pipeline behavior.

## Core rules

- Use **`brainstorm_dialog`** to manage multi-round conversations (`start` → `refine` → `summarize`).
- Ask **one question at a time**.
- Every question ships with a **recommended answer**: mark exactly one option with a `✓ 推荐` prefix in `ask_user_question` and give a one-line reason before asking. Questions without a recommendation are a blocking violation.
- Compare **2-3 approaches** when multiple directions are plausible.
- Keep focused on **what** to build, not implementation details.
- **Explicit user approval required** before handoff to `02-plan`.
- Write result to `docs/brainstorms/` as durable requirements document.

## Mode selection

After initial context, determine mode via `ask_user_question`:

> What's your goal?
> - **Building a startup** → Startup Diagnostic
> - **Intrapreneurship** → Startup Diagnostic
> - **Side project / hackathon** → Builder Mode
> - **Adding a feature** → CE Brainstorm

Skip question if mode is obvious from request.

**Mode mapping:**
- Startup / intrapreneurship → **Startup Diagnostic** (see `references/startup-diagnostic.md`)
- Side project / hackathon → **Builder Mode** (see `references/builder-mode.md`)
- Feature addition → **CE Brainstorm** (see `references/ce-brainstorm-mode.md`)

## Mode summaries

| Mode | Key principle | End goal |
|---|---|---|
| Startup Diagnostic | Specificity is currency, narrow beats wide | One concrete next action |
| Builder Mode | Delight is currency, ship something showable | Concrete build steps |
| CE Brainstorm | Requirements clarity | Implementation-ready spec |

See reference files for full question sets and patterns.

## Premise Challenge

After mode-specific questions, run Premise Challenge. See `references/premise-challenge.md`.

## Design checklist

Before summarizing, ensure the design answers:
- What are we building?
- Why does it exist?
- What files/modules will change?
- What are the responsibility boundaries?
- What can fail, and how?
- How will we verify success?

## Domain vocabulary (optional)

After mode-specific questions, check if the project has a `CONTEXT.md` at root.
If not, and the brainstorm reveals 3+ domain-specific terms with ambiguous meanings,
offer to create one using `references/context-glossary.md` (contract: `../references/domain-language.md`).
Update it inline during the session — don't batch. If it exists, cross-reference and flag conflicts:

> "Your CONTEXT.md defines 'cancellation' as X, but you seem to mean Y — which is it?"

## Stop conditions

Stop and ask instead of guessing when: requirements conflict, success criteria unclear, task spans multiple systems, or user hasn't approved design. Before fleshing out an idea, grep `docs/out-of-scope/` for prior rejections — surface matches before proceeding.

## Approval gate

**Required:** Explicit user approval before handoff to `02-plan`.

## Workflow

1. Scan repository for nearby context
2. Check for existing `CONTEXT.md` at repo root
3. Determine mode (Startup / Builder / CE)
4. Run mode-specific questions (use reference files)
5. Run Premise Challenge
6. Generate 2-3 alternatives (minimal viable + ideal architecture)
7. Validate against design checklist
8. Offer to create/update `CONTEXT.md` if domain terms emerged
9. Use `brainstorm_dialog` `summarize` to finalize
10. Capture requirements in `docs/brainstorms/`
11. Get explicit user approval
12. Handoff to `02-plan` using `references/handoff.md`

## Artifact contract

Use `references/requirements-template.md` to structure the document. Keep implementation details out unless specifically about architecture.

Before finishing this skill, apply the completion checklist in [shared pipeline instructions](../references/pipeline-config.md).