cursor-brainstorm

name	cursor-brainstorm
description	実装前にアイデアを設計へ落とし込む対話型ブレインストーミング。要件が曖昧・アーキテクチャ選択が必要・ユーザーとの対話で設計を固めたい場合に使う。「どうすればいい？」「設計を相談したい」「アーキテクチャどうしよう」「どう実装する？」「アイデアを整理したい」といった要望にも対応する。ユーザーが /cursor-brainstorm と入力したら必ずこのスキルを使う。
argument-hint	[テーマ]

Cursor 実行時の注意

• 広域探索は Task で explorer に委譲する（Claude の Agent ツール語彙は使わない）
• 設計承認まで実装しない。対話ゲートはメイン Agent が持つ
• モデル名はハードコードしない（Cursor UI の運用既定に従う）

ブレインストーミング

テーマ: $ARGUMENTS

アイデアを完全な設計へ落とし込むための対話的プロセスです。このスキル本体（= メインエージェント）がオーケストレーターとなり、必要に応じて explorer 等のsubagentを Task ツールで起動します。子 subagent からの Task 起動は Cursor では制限されるため、起動責任はスキル本体に集約されます。 設計が承認されるまで、コードを書いたり実装アクションを取ってはいけません。

---

ステップ 1: コンテキストの把握

プロジェクトのファイル・ドキュメント・最近のコミットを確認してコンテキストを把握してください。

コードベース探索（ファイル構造の把握、既存パターンの列挙、関連コンポーネントの特定、同一レイヤーの全件列挙など）は必ず explorer エージェントに委譲してください。メインエージェント が Glob / Grep / 複数ファイル Read / Bash の rg/grep/find/fd/ls による広域探索を直接呼ぶことは禁止です（詳細は AGENTS.md (shared SSOT) の「コードベース探索の委譲」を参照）。

• スキル本体（メインエージェント）が Task subagentで explorer を1〜3体起動し、調査対象と期待する出力を具体的に指示する
• 単一ファイルのピンポイント確認（パスが既知で対象1ファイルのみ）のみ直接 Read してよい
• ユーザーが既に提示したドキュメント（例: docs/brainstorm/ の設計書）は直接 Read してよい
• git status / git log / git diff などの VCS 軽量確認は直接呼んでよい

新規コンポーネント（外部サービス連携、新規ドメイン、新しい種別のモジュール等）を提案する場合、explorer に以下を明示的に指示してください:

• 同一レイヤー（同じ親ディレクトリ）の既存コンポーネントを全件列挙
• ファイル分割単位（単一ファイルか複数ファイル分割か）
• ディレクトリ階層（平置きかサブディレクトリを切るか）
• 命名プレフィックス/サフィックスの慣例

これらを把握した上で設計案を組み立てること。既存の圧倒的多数が単一ファイル構成なら新規も単一ファイル構成を基本案にする。

---

ステップ 2: 質問による要件の深掘り

以下のルールに従ってユーザーに質問します：

• 1メッセージに1質問のみ（複数質問で圧倒しない）
• できるだけ選択肢形式（A/B/C など）で聞く
• 「シンプルなタスク」でも必ず確認する（小さいプロジェクトでの思い込みが最も工数を無駄にする）

典型的な確認事項（必要に応じて）：

• スコープと目標
• 技術的制約・既存インフラとの整合性
• 優先度（スピード vs 品質 vs 柔軟性）
• テスト方針

十分な情報が集まったら次のステップへ進んでください。

---

ステップ 3: アプローチの提案

2〜3つのアプローチをトレードオフ付きで提案してください。

新規コンポーネントの構造（ファイル分割、ディレクトリ階層）を含む設計の場合、各アプローチに「既存パターン適合度」を必ず記載してください:

• 同一レイヤーの既存コンポーネント N 件中 M 件が採用している構成か
• 逸脱する場合、何がどう異なるか（ファイル数、ディレクトリ階層、命名）
• 逸脱の理由（将来拡張性のみを理由にするのは不十分。具体的な必要性を述べる）

## アプローチ A: [名前]
- 概要: ...
- 既存パターン適合度: [既存 N 件のうち M 件と同一構成 / 新構造で逸脱]
- 逸脱する場合の差分と理由: ...
- メリット: ...
- デメリット: ...

## アプローチ B: [名前]
...

既存パターンに合わせる案は必ず選択肢として提示してください（それが却下される場合でも、比較軸として必要）。

ユーザーの選択またはカスタマイズを受け取ってください。

スコープ膨張の早期警告（ステップ3選択直後）: ユーザーが「最も大きいアプローチ」または「全機能込み」を選択した場合、ステップ4に進む前に以下を提示する:

• 最初の目標から何がどう広がったか（差分を箇条書きで列挙）
• 段階分割案（MVP 先行＋後付け拡張）と工数見積もり差
• 「このまま全込みで進む」「段階分割する」のどちらを選ぶか確認する

ユーザーが「全込みで進む」を選択した場合はそのまま進んでよい。この警告はスキップせずに必ず提示すること。

---

ステップ 4: 設計の詳細化

承認されたアプローチを元に設計を詳細化します。 各セクションをユーザーに確認しながら進めてください（一度に全部出さず、セクションごとに確認する）：

1. アーキテクチャ概要
2. コンポーネント・インターフェース設計
3. データフロー
4. テスト戦略

マルチエージェント構成・マルチコンポーネント協調を設計する場合は、ここで「誰が誰を起動するか」「誰がどのリソースを所有するか」を明示してください。オーケストレーター（スキル・親エージェント）にsubagent起動の所有権を集約するのが原則で、subagent同士を相互に起動させる構成は依存関係が複雑化するため避けてください。

---

ステップ 4.5: 自己批判レビュー（ドキュメント保存前）

ステップ4で十分な情報が集まったと判断した直後、ユーザーに聞かれるのを待たず自発的に以下の観点で決定事項全体を批判レビューし、懸念を提示してください。

観点:

1. 決定事項同士の矛盾（個別には合意できても組み合わせると片方が死ぬケース）
2. スコープの膨らみ（最初の目標からどれだけ広がったか）
3. 前提の抜け（暗黙に仮定していることが明示されていないか）
4. 隣接タスク・既存コンポーネントへの影響範囲
5. 実装時の詰まりポイント予測（起動責任・命名衝突・循環依存など）
6. マルチエージェント/マルチコンポーネント設計の場合、起動責任・所有権が一貫しているか

懸念を提示 → ユーザーと再合意 → 設計ドキュメント保存、の順で進めてください。懸念が無い場合も「この観点で見直したが問題なし」と明示してから次に進みます。

---

ステップ 5: 設計ドキュメントの保存

設計をドキュメントとして保存してください。 docs/brainstorm/ ディレクトリがなければ作成してください。

保存先: docs/brainstorm/YYYY-MM-DD-<topic>.md（YYYY-MM-DD は今日の日付）

# [テーマ] 設計ドキュメント

_作成: YYYY-MM-DD_

## 目標

[タスクの概要]

## 採用アプローチ: [名前]

### アーキテクチャ

...

### コンポーネント設計

...

### テスト戦略

...

## 保留事項・リスク

...

---

ステップ 6: 次のステップの提示

設計ドキュメントを保存しました: docs/brainstorm/YYYY-MM-DD-<topic>.md

次のステップとして `/cursor-writing-plan` で実装プランを作成できます。