brainstorming

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

---
name: brainstorming
description: >
  Spec ステージ前の必須ヒアリング起点 skill。曖昧な要件を質問の往復で深掘りし、
  Spec を書ける状態まで解像度を上げる。出力は specs/<spec-name>.brainstorm.md。
  「要件まとめたい」「Spec書きたい」「機能追加したい」「新しい仕事を始めたい」「やりたいことがある」等で起動。
  本ワークフロー (docs/workflow.md) では Spec ステージの前提条件として固定化されている。
  ヒアリングを省略していきなり Spec を書くと後続ステージすべてが手戻りするため、本 skill は起点として必須。
  スコープが単一 Spec として大きすぎると判定した場合は、分割軸 (機能 / Release Phase / データ / 層) を提示して複数 Spec への分割を提案する機能も含む。
  起動直後に既存コードベースを精査 (ディレクトリ構造 / メタ情報 / 関連モジュール / 既存テスト等) し、ユーザーへの質問を絞り込む機能も含む。
---

# Brainstorming Skill

本プロジェクトの開発ワークフロー (`docs/workflow.md`) における起点ステージです。ユーザーの曖昧な要望を質問の往復で深掘りし、次の Spec ステージで仕様を書ける状態まで解像度を上げることが役割です。

**用語**: 「Project Phase」「Workflow Stage (ステージ)」「Release Phase」「Spec」の定義は `docs/glossary.md` を参照してください。本 skill 内では Workflow Stage を「ステージ」、ユーザープロジェクトのリリース段階 (MVP / Phase 2 等) を「Release Phase」と表記します。

## 1. 役割と位置づけ

本 skill はワークフローの最上流に位置します。後続のすべてのステージ (Spec → Spec Review → Isolate → Plan → Implement → Verify → Code Review → ship → Learn) は、本ステージの出力である Brainstorming ノートを起点として進みます。

**設計原則**: ヒアリングを飛ばして Spec ステージに直接進むことは禁止です。曖昧な要件のまま Spec を書くと、Plan / Implement / Code Review すべてが手戻りするため、本 skill を起点として固定化します (`docs/workflow.md` 設計原則 6 参照)。

## 2. 起動トリガー

以下のような自然言語のフレーズで自動的に起動してください。

- 「要件をまとめたい」
- 「Spec を書きたい」
- 「機能を追加したい」
- 「新しい仕事を始めたい」
- 「やりたいことがある」
- 「〜について相談したい」
- 「〜を作りたい」

ユーザーが上記のような着手意図を示した時点で、本 skill を起動し、ヒアリングを開始します。すでに Spec ファイル (`specs/<spec-name>.md`) が存在する場合は本 skill をスキップし、Spec Review ステージに進んでください。

## 3. 禁則事項 (Anti-Pattern)

本 skill 起動中に以下を行ってはいけません。

- ❌ ヒアリングを省略していきなり Spec ファイルを作成する
- ❌ ユーザーの最初の発話だけで Spec の解像度が十分と判断する
- ❌ 質問なしに実装提案を始める
- ❌ ユーザーの承認なしに次の Spec ステージへ自動遷移する
- ❌ Brainstorming ノートを worktree 内に作成する (worktree はまだ存在しない)

特に「これは簡単だから設計不要」という判断は、後続ステージで必ず手戻りを起こすため明確に禁止します。

## 4. ヒアリング手順 (チェックリスト)

以下の順序でユーザーと対話してください。各項目で十分な解像度が得られるまで、追加質問を続けます。

- [ ] **目的の確認**: なぜこの作業をしたいのか、解決したい問題は何か
- [ ] **利用者の特定**: 誰がこの成果物を使うのか (自分のみ / チーム / 外部ユーザー等)
- [ ] **成功条件の明確化**: どうなれば完了と判断できるのか (受け入れ基準)
- [ ] **制約の洗い出し**: 既存システムへの影響、技術的制約、時間的制約
- [ ] **スコープの確定**: 何を含み、何を含まないか
- [ ] **代替案の検討**: 他のアプローチはないか、なぜこのアプローチを選ぶのか
- [ ] **リスクの予測**: 何がうまくいかない可能性があるか
- [ ] **次ステージへの移行確認**: ユーザーが Spec ステージへ進む準備ができたか明示的に承認

各項目を機械的に質問するのではなく、ユーザーの発話から明らかになった項目はスキップし、未解明の項目を優先的に質問してください。

## 5. 質問カテゴリ

ヒアリングの軸として以下のカテゴリを参照してください。

| カテゴリ | 代表的な質問例 |
|---|---|
| 目的 | 「この機能で何を実現したいですか」「現状の何が不便ですか」 |
| 利用者 | 「誰が使いますか」「使う頻度はどれくらいですか」 |
| 成功条件 | 「完成したと判断する基準は何ですか」「動作確認はどう行いますか」 |
| 制約 | 「既存のどの部分に影響しますか」「期日はありますか」「使える技術スタックの制限はありますか」 |
| スコープ | 「今回含めない機能はありますか」「将来的に拡張予定の機能は何ですか」 |
| 代替案 | 「他に思いついたアプローチはありますか」「既存ライブラリで代替できませんか」 |
| リスク | 「何が起きると困りますか」「失敗パターンを想定していますか」 |

## 6. 出力フォーマット

ヒアリングが完了したら、以下のフォーマットで `specs/<spec-name>.brainstorm.md` を作成してください。`<spec-name>` はユーザーと相談して決定したケバブケースの名前 (例: `add-user-login`, `fix-payment-bug`) を使います。

````markdown
---
name: <spec-name>
created: YYYY-MM-DD
status: brainstorming-complete
---

# Brainstorming: <spec-name>

## 目的
<なぜこの作業をするのか、解決する問題>

## 利用者
<誰が使うのか>

## 成功条件 (受け入れ基準)
- <条件 1>
- <条件 2>

## 制約
- <技術的制約>
- <時間的制約>
- <既存システムへの影響>

## スコープ
### 含むもの
- <項目 1>

### 含まないもの (明示的に除外)
- <項目 1>

## 代替案の検討
- <検討した代替案 1 と却下理由>
- <検討した代替案 2 と却下理由>

## リスク
- <想定されるリスク 1 と対策方針>

## 未解決事項
- <Spec ステージで決定する事項>

## ヒアリングログ (任意)
<重要なやり取りの抜粋>
````

ファイル配置先は `specs/<spec-name>.brainstorm.md` です。`specs/` ディレクトリが存在しない場合は新規作成してください。worktree 内ではなく、main ブランチ側に配置します。

## 7. 完了判定基準

以下を **すべて** 満たした時点で本 skill を完了とします。

1. 上記チェックリストの「次ステージへの移行確認」を除く全項目に十分な情報が得られている
2. Brainstorming ノートが上記フォーマットで作成され、`specs/<spec-name>.brainstorm.md` に保存されている
3. ユーザーが Spec ステージへの移行を **明示的に** 承認している (例: 「これで Spec 書いて良いです」「次に進んで」)

ユーザー承認なしに自動で次のステージへ遷移してはいけません。承認を得るための問いかけは「以上の内容で Spec ステージに進めますがよろしいですか」のように明確に行ってください。

## 8. 次ステージへの引き継ぎ

完了判定を満たしたら、以下の引き継ぎを行います。

1. ユーザーに `writing-spec` skill (Phase 3 で実装予定) を起動する旨を伝える
2. 引き継ぎ情報として、作成した Brainstorming ノートのパスを明示する
3. 未解決事項として残した項目を Spec ステージで議論することを伝える

`writing-spec` skill 未実装の Phase 3 着手段階では、引き継ぎは口頭での合意で代替し、Brainstorming ノートのパスをユーザーに提示するに留めます。

## 9. 失敗時の対応

ヒアリング中にユーザーが要