Brainstorming

Brainstorming

💡 Recommended Agent: brainstorm-agent (Requirements Explorer)

• CLI: Input /agent and select brainstorm-agent
• VS Code: Use @workspace #brainstorm-agent in Chat

When to Use

Use this skill at the start of any request/change when:

• Requirements are ambiguous or incomplete
• The change touches security, auth/authz, data flow, CI/CD, or supply chain
• There are multiple plausible implementation approaches
• You need a rationale trail (auditability)

💡 方向完全不明確？ 先用 /research 探索技術地圖，再回來 brainstorm。

Workflow

Pre-Phase — Domain Research（條件觸發）

觸發條件（滿足任一即觸發）：

• 使用者未指定技術棧
• 無現有 codebase（greenfield 專案）
• 想法屬於領域/概念層級（如「我想做 AI 客服平台」「我想做財務分析工具」）

派遣 research subagent，指令範本：

"Search GitHub for [domain] popular libraries, architectures, and community trends (2024–2025). Report top 3 approaches with complexity, maturity, and trade-offs, with citations."

將研究結果整理為解法地圖（2-3 條路線 + 社群成熟度），作為 Phase 1 提問與 Phase 2 選項比較的依據。

Phase 0 — Intake & Risk Classification

• Clarify goals/non-goals and acceptance criteria
• Classify risk: Low / Med / High
• Determine if this is brownfield (existing system)
• Select exactly one execution mode from WORKFLOW.md: Simple, Standard, or High-Risk. Use its entry, escalation, artifact, and verification contract without defining another path here.

Phase 1 — Clarify

• In each new brainstorming round, ask at least 5 targeted questions before options/recommendation unless the user explicitly says assumptions are acceptable
• If the user cannot answer immediately, list assumptions separately and label what remains unknown

Phase 2 — Explore Options

• Produce 2–3 options
• For each: complexity (L/M/H), risks, dependencies, rollback strategy

Phase 3 — Decide & Record

• Recommend one option and justify
• Produce a Decision Log entry (append-only)

Phase 4 — Required Lifecycle Artifacts

• Simple does not require a Change Package; retain the confirmed summary inline or in an existing project plan when useful.
• For Standard when a canonical package trigger applies, or for High-Risk, use shell to create changes/<YYYY-MM-DD>-<slug>/ first.
• Then write the required stub files (do NOT use edit on non-existent files):
  • 01-brainstorm.md
  • 02-decision-log.md
  • 03-spec.md (draft)
• If shell is unavailable, output file contents in response for manual creation

Must-Ask Questions

Apply to every project regardless of domain:

In a normal kickoff, cover at least five of these categories before recommending a path or solution. If the user explicitly allows assumptions, say that you are switching to assumption-driven brainstorming.

Conditional Follow-up Questions

Trigger these based on the user's answers:

Risk Classification

Output Template

• Risk Classification (Low/Med/High)
• Execution Mode (Simple / Standard / High-Risk) with canonical evidence
• Questions Asked (at least 5 unless the user explicitly allowed assumptions)
• Assumptions & Constraints
• Options (2–3)
• Recommendation
• Decision Log
• Required Lifecycle Artifacts (inline/existing plan for Simple; package stubs when required)

Brainstorm Summary Format

Use this structure in 01-brainstorm.md:

## Brainstorm Summary

**Problem**: [one sentence]
**Risk Level**: Low / Med / High
**Execution Mode**: Simple / Standard / High-Risk
**Chosen Approach**: [option name and one-line reason]
**Discovery Questions Covered**: [at least five categories, or note that the user explicitly allowed assumptions]
**Open Questions**: [anything still unresolved]
**Assumptions**: [what we're assuming to be true]
**Non-goals**: [explicitly out of scope]

Output Mapping (when a Change Package is required)

Write results into:

• changes/<YYYY-MM-DD>-<slug>/01-brainstorm.md
• changes/<YYYY-MM-DD>-<slug>/02-decision-log.md
• Draft/Update changes/<...>/03-spec.md (minimum scope + verification)

Directory creation: Always create the target directory with shell (mkdir -p / New-Item -ItemType Directory -Force) before writing files. The edit tool CANNOT create new files — use shell or create tool instead. If shell is unavailable, output file contents in response for manual creation.

Common Rationalizations

在腦力激盪過程中，AI 可能以下列藉口跳過關鍵步驟。以下為常見合理化說詞與反制說明：

Verification

在輸出 brainstorm 產出物前，逐項確認（Gate = 交付前閘門；Verification = 自我完成確認）：

• 若 mode 要求 Change Package，Test-Path changes/<slug>/01-brainstorm.md 回傳 True；Simple 則記錄 N/A — Change Package is not required for this Simple task.
• Risk Classification 已完成，等級為 Low / Med / High 三者之一，且已依 WORKFLOW.md 選擇唯一的 Simple / Standard / High-Risk mode
• 至少 5 個 Must-Ask 問題類別已覆蓋，或使用者已明確允許 assumption-driven 模式（不得靜默跳過）
• 至少 2 個選項已比較（complexity / risks / rollback strategy），並有明確推薦理由
• 若 mode 要求 Change Package，Decision Log 條目已寫入 02-decision-log.md；Simple 則將決策理由保留在 inline summary 或 existing plan
• Open Questions 欄位已填寫（若有未解問題），不得略去
• 所有 Assumptions 均已明確標記（不得以隱性假設替代明確說明）