---
name: brainstorming-design
description: コードを書く前に使用。質問を通じてアイデアを設計に洗練する。
---

# Brainstorming and Design

## 📋 実行前チェック(必須)

### このスキルを使うべきか?
- [ ] 新機能の設計を開始する?
- [ ] アーキテクチャを決定する?
- [ ] 技術選定を行う?
- [ ] 要件が曖昧で整理が必要?

### 前提条件
- [ ] プロジェクトの既存コード構造を確認したか?
- [ ] 技術スタックを把握しているか?
- [ ] 既存の規約を確認したか?

### 禁止事項の確認
- [ ] 設計なしでいきなりコードを書こうとしていないか?
- [ ] 複数の質問を同時にしようとしていないか?
- [ ] 代替案なしで1案だけ提示しようとしていないか?
- [ ] 「将来必要になるかも」で過剰設計しようとしていないか?
- [ ] 承認を得ずに設計を進めようとしていないか?

---

## トリガー

- 新機能の設計開始前
- アーキテクチャ決定時
- 技術選定時
- 要件が曖昧な時

---

## 🚨 鉄則

**コードを書く前に、何を作るのかを明確にする。**

---

## プロセス

### 1. コンテキスト把握

まずプロジェクトを調査:
- 既存コード構造
- 技術スタック
- 規約

### 2. 質問(1つずつ)

```
✅ 「認証方式はどちらですか?
   A) JWT  B) セッション  C) OAuth」

❌ 「認証方式は? DBは? UIは?」(複数同時は禁止)
```

### 3. 代替案の提示

決定前に2-3案を提示:

```
## 案A: モノリス
- 利点: シンプル、デプロイ容易
- 欠点: スケーラビリティ限界

## 案B: マイクロサービス  
- 利点: スケーラブル
- 欠点: 複雑、運用コスト高

推奨: 案A(MVP段階のため)
```

### 4. 段階的検証

設計を小さなセクションに分けて、各セクションで承認を得る。

### 5. 文書化

承認された設計を `docs/plans/YYYY-MM-DD-<topic>.md` に保存。

---

## YAGNI

```
「将来必要になるかも」→ 今は実装しない
今必要な最小限のみ設計する。
```

---

## スキップする場合

- バグ修正(原因が明確)
- 明確な仕様がある
- 既存パターンに従う追加

---

## 🚫 禁止事項まとめ

- 設計なしでコードを書き始める
- 複数の質問を同時にする
- 代替案なしで1案だけ提示
- 「将来必要になるかも」で過剰設計
- 承認を得ずに設計を進める