---
name: brainstorming
description: "アイデアや要件を対話的に設計書（PBI INPUT PACKAGE）へ昇華する。Use when: 「こういう機能を作りたい」「どう実装すればいい？」「要件を整理したい」「設計を考えたい」「ブレスト」「アイデア出し」「what if」「どういうアプローチがある？」「PBI INPUT PACKAGEを作りたい」「技術調査の方向性を決めたい」。実装計画の作成にはai-dev-workflowを使用。"
---

# Brainstorming

アイデアや曖昧な要件を、対話的なドリルダウンで設計書（PBI INPUT PACKAGE）に昇華する。

## Iron Law

`NO CODE WITHOUT APPROVED DESIGN FIRST`

設計が承認されるまで、一切のコード実装を禁止する。「シンプルだから」「急いでいるから」は理由にならない。

## Common Rationalizations

| こう思ったら | 現実 |
|---|---|
| 「シンプルだから設計不要」 | シンプルなタスクほど設計が速い。省略する理由にならない |
| 「前に似たことをやったから分かる」 | コードベースは変化する。今の状態を調査しろ |
| 「ユーザーが急いでいるから質問を省略」 | 曖昧なまま進めると手戻りの方が遅い |

**核心原則**: コードを書く前に、ユーザーが本当に何を求めているかを確認する。

## Philosophy

- **1質問ずつ**: 一度に複数の質問をしない。ユーザーの回答を受けてから次の質問を決める
- **YAGNI**: 「将来必要になるかも」は削る。今必要な最小構成を設計する
- **代替案を提示**: 最初のアイデアに飛びつかない。2-3のアプローチをトレードオフ付きで提示する
- **既存パターン優先**: コードベースの既存実装を調査し、一般論ではなくプロジェクト固有のパターンに従う
- **インクリメンタル承認**: 各ステップでユーザーの承認を得てから次に進む

---

## 8ステップ プロセス

### Step 1: プロジェクトコンテキスト探索

ユーザーのアイデアを聞いた後、まずコードベースを調査する。

```text
調査対象:
□ 関連する既存コード（Grep/Globで検索）
□ 類似機能の実装パターン
□ アーキテクチャの制約
□ 関連するテストパターン
```

**出力**: 関連コードと制約の要約をユーザーに報告する。

### Step 2: 明確化質問（1つずつ）

ユーザーの意図を正確に把握するため、**1つずつ**質問する。

質問の優先順位:
1. **Why**: なぜこの機能が必要か？（ユーザーの課題・目的）
2. **Who**: 誰が使うか？（エンドユーザー、管理者、API利用者）
3. **What**: 具体的に何ができるようになるか？（受入基準）
4. **Scope**: 何をやらないか？（明示的な除外範囲）
5. **Constraints**: 技術的制約、期限、依存関係は？

**ルール**:
- 回答から次の質問を導出する（スクリプト的に全質問を投げない）
- 3-5問で十分な理解が得られたら次のステップへ進む
- ユーザーが「もう十分」と言ったら即座に次へ

### Step 3: アプローチ提案

2-3のアプローチを提示する。各アプローチには:

```markdown
### アプローチ A: {名前}

**概要**: 1-2文で説明
**トレードオフ**:
- メリット
- デメリット・リスク
**変更範囲**: {影響するファイル数・領域}
**工数目安**: 小 / 中 / 大
```

**ルール**:
- 最もシンプルなアプローチを最初に提示する
- 各アプローチの「やらないこと」を明確にする
- ユーザーが選びやすいよう推奨を示す（ただし押し付けない）

### Step 4: ユーザー承認チェックポイント

ユーザーにアプローチを選んでもらう。

```text
「アプローチ A/B/C のどれで進めますか？
また、変更・追加したい点があれば教えてください。」
```

### Step 5: 設計書ドラフト作成

選ばれたアプローチを基に、`pbi-input.md`形式の設計書を作成する。

```markdown
# PBI INPUT PACKAGE: {タイトル}

> 生成日: YYYY-MM-DD
> 生成方法: brainstormingスキル

## Context / Why
{なぜやるか。ユーザーの課題・目的}

## What（Scope）

### In scope
{やること。具体的な機能・振る舞い}

### Out of scope
{やらないこと。明示的な除外範囲}

## 受入基準
- [ ] {基準1}
- [ ] {基準2}
- [ ] {基準3}

## Notes from Refinement
{議論で決まったこと。ブレスト中の意思決定を記録}

## Estimation Evidence

### Risks
{リスク}

### Unknowns
{不明点}

### Assumptions
{前提条件}
```

### Step 6: Specレビュー（自動セルフチェック）

設計書を以下の観点で自動チェックする:

```text
チェック項目:
□ Context / Why が具体的か（「便利だから」ではなく課題ベース）
□ 受入基準が検証可能か（テストで確認できる粒度）
□ Out of scope が明確か（曖昧な境界がないか）
□ 既存アーキテクチャとの整合性
□ YAGNIに反する要素がないか（過剰な設計）
□ セキュリティ観点の漏れ（認証・認可、入力バリデーション）
```

**結果**: PASS / WARN（改善提案付き）/ FAIL（修正必須）

### Step 7: 修正サイクル

Step 6でWARN/FAILが出た場合:
1. 指摘事項をユーザーに報告
2. 修正案を提示
3. ユーザー承認を得て修正
4. 再度Step 6を実行

### Step 8: 完了と遷移

設計書がPASSしたら:

1. `docs/working/TASK-XXXX/pbi-input.md` に保存（チケット番号が分かる場合）
2. 次のステップを案内:

```text
設計書の作成が完了しました。

次のステップ:
1. `/ai-dev-workflow TASK-XXXX plan` — 実装計画を生成
2. 設計書の内容を手動で調整（必要に応じて）
3. チームメンバーと共有してフィードバックを得る
```

---

## 重要ルール

- **第1原則を遵守**: ファイル生成前にユーザー確認を取る
- **1質問ずつ**: 複数の質問を同時にしない
- **既存コード最優先**: コードベースを調査してから設計する
- **過度に複雑にしない**: ユーザーが求めている以上の設計をしない
- **対話を楽しむ**: 機械的な質問ではなく、ユーザーのアイデアを一緒に育てる姿勢

## 関連スキル

- **ai-dev-workflow**: brainstorming完了後、実装計画の生成に使用
- **skill-creator**: 新しいスキルの設計にbrainstormingを適用可能