Brainstorm

---
name: brainstorm
description: 要件や設計の選択肢を整理し、実装前の決定事項を明確にする対話スキル。曖昧な要件、複数の設計案、既存パターンからの逸脱を検討するときに使う。十分に明確な小さな依頼では不要な調査や質問を追加しない。ユーザーが /brainstorm と入力したら使う。
argument-hint: "[テーマ]"
---

# Brainstorm — 対話から設計へ

**テーマ**: `$ARGUMENTS`

このスキルは、実装前に目的・制約・決定事項を整理する親向けの入口です。親が要件、スコープ、質問、選択、最終設計を所有します。承認された設計ができるまでコード変更や実装操作へ進みません。

## 1. まず確認すること

- ユーザーが既に示した目的、制約、対象、選択を再質問しない。
- 親が確認済みの対象と、今回まだ不明な事項を分ける。
- コードベースの広域探索、既存パターンの比較、関連箇所の列挙が必要なら、現在のランタイムが提供する標準の探索担当または汎用 Task へ、対象・問い・期待する返却内容を渡す。実行者名を完了条件にせず、小さく既知の単一ファイルの確認は親が行える。
- 探索担当には編集、git変更、記憶追記、レポート保存を要求しない。結果はチャットで受け取り、必要な記録は親が行う。

委任時は、親が実行者用 Skill / reference の実体 path を確認し、対象版、確定事実、所有範囲、制約、完了条件と一緒に渡します。委任された子が必要な資料を Read し、親は委任のために専門手順の全文を先読みしません。親が直接確認する場合だけ、自分が必要な資料を Read します。子はこの親用の進行や委任を再起動しません。

新規コンポーネントを検討するときは、探索で同じレイヤーの既存ファイル、分割単位、ディレクトリ階層、命名慣例を確認する。既存の大多数に沿う案を必ず比較軸にする。

## 2. 質問と判断

質問は、答えによってスコープ、正しさ、安全性、権限、互換性、外部状態が変わる場合にだけ行う。質問する場合は一度に一つ、可能なら選択肢を示す。十分に明確な依頼なら、既知の前提を明記して案の提示へ進む。

親が既存パターンと要件から決められる詳細は、ユーザーへ委ねず親が決めて理由を記録する。ユーザーが留保した決定や、依頼外へ広がる選択だけを具体的な選択肢として返す。

## 3. 案の比較

案が実質的に複数ある場合だけ、2〜3案を比較する。各案に概要、既存パターンへの適合度、必要な逸脱と理由、利点、欠点、影響範囲を示す。新規構造を含む場合は、同一レイヤーの既存件数と採用件数を根拠にする。案が一つで十分なら、選んだ理由と却下した前提を短く示す。

ユーザーが最大スコープを選んだ場合は、最初の目的との差分、段階分割案、実装上の影響を示す。追加範囲が実質的な変更なら、ユーザーの決定を得るまでその拡張を実装へ反映しない。

## 4. 設計の確定

承認された案について、必要な粒度で次を整理する。各項目を一つずつ確認することは必須ではなく、未決定が実質的に残る場合だけ確認する。

1. 目的、非目的、受入条件
2. コンポーネント、インターフェース、所有範囲
3. データ・制御フローと失敗時の扱い
4. 既存パターン、権限、外部依存、検証方法

複数担当を使う設計では、起動権限を親に集約し、各担当の対象・所有ファイル・編集可否・返却事項を明記する。担当同士の再委譲を前提にしない。

## 5. 批判的確認と記録

保存前に、決定事項同士の矛盾、前提の抜け、スコープの膨張、既存コンポーネントへの影響、起動責任・所有境界・循環依存を親が確認する。問題があれば設計へ反映し、解決不能な実質判断だけをユーザーへ戻す。

設計書を残すのは、ユーザーが保存を求めた場合、後続実装が参照する場合、または既存プロジェクト方針で必要な場合に限る。保存する場合は親が指定した親directoryの実在を確認し、その配下の今回未使用のファイルpathへ書き込み、既存ファイルを上書きしない。保存先や日付・RUN_DIRを推測しない。設計書には目的、決定、根拠、非目的、受入条件、未解決事項、参照した資料を含める。

返却時は、採用案、決定済み事項、非目的、必要な検証、残るユーザー判断、実際に保存した場合だけ保存先を示す。実装、commit、push、外部投稿はこのスキルの完了条件に含めない。