brainstorm

name	brainstorm
description	壁打ち用スキル。指示された内容の実現方法を、リポジトリのソースコードの観察・外部の最新OSS実装や実践事例の調査を踏まえて検討し、実装案や実現可能性を提示する。ユーザーが「これってできる？」「どうやって実装する？」「こういう機能を入れたい」「設計を相談したい」「壁打ちしたい」といった探索的・検討段階の相談をしたときに使うこと。spec作成（/dev）の前段階での利用を想定している。
allowed-tools	Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch, AskUserQuestion

壁打ちスキル

ユーザーのアイデアや課題について、コードベースの実態と外部知見を組み合わせて実装案を検討するスキル。spec-driven development（/dev）の前段階、つまり「何をどう作るか」を固める探索フェーズで使う。

基本方針

• ユーザーの相談内容を深く理解し、的確な案を返すことが最優先
• 案の数は内容次第。明らかにベストな方法があれば1案でいい。トレードオフがあれば複数案を比較する
• 「とりあえず3案出す」のような形式主義は不要。質で勝負する
• ユーザーが判断できる材料（根拠、トレードオフ、リスク）を提供する

進め方

Step 1: 相談内容の把握

ユーザーの発言から以下を読み取る：

• 何を実現したいか（目的・ゴール）
• どの程度固まっているか（漠然としたアイデア？ある程度方針がある？）
• 判断に必要な情報は何か（実現可能性？性能？設計の妥当性？）

曖昧な場合は、AskUserQuestionで最小限の確認をする。ただし質問攻めにはしない。まず手を動かして調べ、調査結果をもとに具体的な選択肢を提示するほうが建設的。

Step 2: コードベースの観察

相談内容に関連するコードを徹底的に調べる。Agent（Explore）を活用して並列に調査すると効率的。

調べるべきこと：

• 既存の実装パターン: 同種の処理がすでにどう実装されているか
• アーキテクチャ: コードの構造、依存関係、レイヤー分け
• 使用ライブラリ・フレームワーク: 既存の技術スタックとの整合性
• テストパターン: 既存テストの書き方、カバレッジ方針
• 設定・インフラ: CI/CD、デプロイ、環境設定

単にファイルを列挙するのではなく、「この設計判断にはこういう意図がある」「ここがボトルネックになりそう」といった洞察を得ることが目的。

Step 3: 外部知見の調査

必要に応じてWebSearch/WebFetchで外部情報を収集する。以下のような場合に特に有用：

• 使ったことのないライブラリ・APIの仕様確認
• 同様の課題に対する一般的なアプローチの把握
• 最新のOSS実装での解決事例
• パフォーマンス特性やセキュリティ上の注意点

調査は目的を持って行う。「とりあえず検索する」のではなく、コードベース観察で得た仮説を検証する、あるいは不足している知識を補うために使う。

調査時の注意:

• 公式ドキュメント・GitHubリポジトリを優先する
• ブログ記事やStack Overflowは参考程度に。情報の鮮度に注意
• 調査結果のURLは案の提示時に出典として含める

Step 4: 案の組み立てと提示

調査結果を統合して実装案を組み立てる。

案の構成要素

各案には以下を含める（必要に応じて取捨選択）：

• 概要: 何をどうするか、1-2文で
• アプローチの詳細: 具体的な実装方針。既存コードのどこにどう手を入れるか
• 根拠: なぜこのアプローチを推すのか。コードベースの実態や外部事例に基づく理由
• トレードオフ: メリット・デメリット。特に「やらないことで何を失うか」も
• リスク・懸念: 実装時にハマりそうな点、依存関係の問題、性能への影響
• 工数感: 大・中・小程度のざっくりした粒度で。時間の見積もりはしない
• 参考: 調査で見つけた有用なリソースへのリンク

案の出し方

• 1案で十分な場合: 明確にベストな選択肢がある場合は、その案を推薦理由とともに提示する。無理に代替案をひねり出さない
• 複数案を比較する場合: 各案のトレードオフが異なる場合に有効。比較表を使って判断材料を整理する
• 実現困難な場合: 正直に「難しい」と伝える。なぜ難しいのか、代替として何ができるかを説明する

出力フォーマット

形式は内容に合わせて柔軟に。ただし以下の構造を基本とする：

## 検討結果

### 前提の整理
[コードベース観察と外部調査から得た、案の前提となる事実]

### 案1: [案の名前]
[概要、アプローチ、根拠、トレードオフなど]

### 案2: [案の名前]（複数案がある場合）
[同上]

### 比較（複数案がある場合）
| 観点 | 案1 | 案2 |
|------|-----|-----|
| ... | ... | ... |

### 推奨
[どの案を推すか、あるいはユーザーの判断が必要な点]

Step 5: 不明点の深掘り

案を提示した後、あるいは案を組み立てる過程で、不明点や曖昧な点が見えてくる。これらを放置せず、AskUserQuestionを使って構造的に深掘りする。

深掘りが必要な場面

• 案の提示時に前提が不確かな場合: 「AとBどちらの方針で進めたいか」をユーザーに確認してから案を絞る
• 案を提示した後にユーザーが迷っている場合: 判断の軸を明確にするための追加質問をする
• 技術的な選択肢が複数あり、ユーザーの優先度次第で最適解が変わる場合: 何を重視するか（性能？保守性？開発速度？）を確認する
• ユーザーの発言に暗黙の前提や制約が含まれていそうな場合: 推測で進めず確認する

深掘りの進め方

1. コードベース観察や外部調査で判明した事実をもとに、具体的な選択肢付きの質問を組み立てる
2. AskUserQuestionで質問する。各選択肢にはpros/consを含め、ユーザーが判断しやすいようにする
3. 回答を受けて案を更新・絞り込む
4. まだ不明点があれば繰り返す

質問は1回あたり2〜4個程度に絞る。「調べれば分かること」は質問せず自分で調べる。ユーザーに聞くのは、ユーザーしか持っていない情報（ビジネス要件、優先度、運用上の制約など）に限る。

深掘り後のアクション

深掘りの結果、方針が明確になったら：

• 案を更新して再提示する
• 方針が十分に固まったら、「/dev でspec作成に進められるよ」と伝える

やらないこと

• specファイルの作成（それは /dev の役割）
• 実装の着手（壁打ちフェーズでは検討のみ）
• 形式的な質問の繰り返し（調査で分かることは調査で済ませる）
• 過度に保守的な判断（「やめたほうがいい」より「こうすればできる」を探す）