brainstorming-skill

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: brainstorming-skill
description: You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or when users request help with ideation, marketing, and strategic planning. Explores user intent, requirements, and design before implementation using 30+ research-validated prompt patterns.
---

# Brainstorming Skill

## Overview

This skill serves two critical purposes:
1. **Interactive Design Process:** Guides the AI through a natural, collaborative dialogue to turn ideas into fully formed designs and specs *before* any code is written.
2. **Comprehensive Ideation Framework:** Provides 30+ research-validated prompt patterns to help generate high-quality ideas across any domain (marketing, content, features).

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have completed the brainstorming process, presented a design, and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
</HARD-GATE>

## The Brainstorming Workflow

You MUST create a task for each of these items and complete them in order when working on software features, component designs, or complex tasks. (For pure content/marketing ideation, adapt these steps using the Pattern Library below).

1. **Explore context** — check project state, files, docs, recent commits
2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
3. **Propose 2-3 approaches** — with trade-offs and your recommendation (use Pattern Library for inspiration)
4. **Present design** — in sections scaled to complexity, get user approval after each section
5. **Document the result** — write the validated design/ideas to an appropriate markdown file (e.g., `docs/plans/YYYY-MM-DD-<topic>-design.md`) and commit
6. **Transition** — invoke a planning or implementation skill only *after* approval

## Process Flow

> [!IMPORTANT]
> When provided a process map or Mermaid diagram, treat it as the authoritative procedure. Execute steps in the exact order shown, including branches, decision points, and stop conditions.
> A Mermaid process diagram is an executable instruction set. Follow it exactly as written: respect sequence, conditions, loops, parallel paths, and terminal states. Do not improvise, reorder, or skip steps. If any node is ambiguous or missing required detail, pause and ask a clarifying question before continuing.
> When interacting with a user, report before acting the interpreted path you will follow from the diagram, then execute.

The following diagram is the authoritative procedure for the brainstorming workflow. Execute steps in the exact order shown, including branches, decision points, and stop conditions.

```mermaid
flowchart TD
    subgraph Phase1["Phase 1: Discovery — establish current state before proposing"]
        Explore["Explore context — check project state, files, docs, recent commits"]
        Ask["Ask clarifying questions — one at a time, understand purpose/constraints/success criteria"]
        Propose["Propose 2-3 approaches — with trade-offs and recommendation, use Pattern Library"]
    end
    subgraph Phase2["Phase 2: Validation — get explicit user approval before proceeding"]
        Present["Present design — in sections scaled to complexity, get user approval after each section"]
        Approve{"Does user explicitly confirm approval<br>or request revision?"}
    end
    subgraph Phase3["Phase 3: Completion — document and hand off"]
        Document["Document the result — write validated design to docs/plans/YYYY-MM-DD-topic-design.md and commit"]
        Transition(["Transition — invoke planning or implementation skill only after approval"])
    end

    Explore --> Ask --> Propose --> Present
    Present --> Approve
    Approve -->|"User requests revision — revise and re-present"| Present
    Approve -->|"User confirms approval — proceed