brainstorming

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: brainstorming
description: >-
  Use before any creative or architectural work — migrations, adding features,
  restructuring, or modifying site behavior. Explores intent, requirements,
  and design before implementation.
---

# Brainstorming

Turn rough ideas into validated designs through structured dialogue before touching code or config.

**Do NOT start implementation until a design is presented and the user approves it.** This applies regardless of perceived simplicity — "simple" tasks are where unexamined assumptions cause the most wasted work.

## Process

### 1. Explore context

Check the project state first: files, config, recent changes, existing patterns. Understand what exists before asking questions.

### 2. Ask clarifying questions

- **One question at a time.** Don't overwhelm with a list.
- **Prefer multiple choice** when there are known options. Open-ended when the space is genuinely open.
- Focus on: purpose, constraints, success criteria, what the user cares about most.

### 3. Propose approaches

Present 2-3 approaches with tradeoffs. Lead with your recommendation and explain why. Be honest about downsides.

If only one approach makes sense, say so and explain why alternatives don't work — don't invent fake options.

### 4. Present design

Once you understand what to build, present the design in sections scaled to complexity:

- A few sentences for straightforward sections
- More detail for sections with genuine tradeoffs
- **Get approval after each section** so the user can course-correct early

Cover: what changes, what stays the same, what the user needs to verify, and any decisions deferred to implementation.

### 5. Transition to implementation

Once the user approves the design, proceed to implementation. For migrations, this means entering the relevant migration phase. For other work, start executing.

## When to use this skill

- **Migrations** — before starting, explore the site structure and discuss editability tradeoffs (page builder vs static pages, what to make editable, content restructuring decisions)
- **Adding features** — before adding snippets, visual editing, or configuration to an existing site
- **Restructuring** — before reorganizing content, collections, or config
- **Ambiguous requests** — when the user says "make this work with CC" without specifying scope

## When NOT to use this skill

- Single, well-defined tasks with an obvious implementation ("add `snippet: true` to `_editables`")
- Bug fixes where the problem and solution are clear
- The user explicitly says "just do it" or provides a detailed spec

## Key principles

- **One question at a time** — don't overwhelm
- **Multiple choice preferred** — easier to answer than open-ended when options are known
- **YAGNI** — remove unnecessary complexity from designs
- **Explore alternatives** — always consider whether a different approach would be simpler
- **Be honest** — if something seems overcomplicated, say so. Push back on scope creep.
- **Incremental validation** — present design in sections, get approval before moving on

## Common mistakes

| Excuse                                       | Reality                                                                                |
| -------------------------------------------- | -------------------------------------------------------------------------------------- |
| "This is too simple to need a design"        | Simple tasks are where assumptions cause the most waste. The design can be short.      |
| "I already know what to do"                  | You know what YOU would do. The user may have different priorities or constraints.     |
| "Asking questions slows things down"         | Wrong assumptions slow things down more. One question now saves rework later.          |
| "The user will tell me if something's wrong" | Users often don't know what to flag until they see the wrong result. Validate upfront. |
| "I'll figure it out as I go"                 | That's how you