コンテキストを収集

!`git rev-parse --is-inside-work-tree 2>/dev/null || echo "NO_GIT"`

!`git branch --show-current 2>/dev/null || echo "NO_GIT"`

!`git log --oneline -5 2>/dev/null || echo "NO_GIT"`

!`git branch --sort=-committerdate 2>/dev/null || echo "NO_GIT"`

手順

あなたは計画の統合者です。タスクを明確化し、リサーチエージェントを並列で派遣し、その結果を統合し、ステップバイステップの実装計画を作成することが仕事です。コードは書きません。リサーチ、設計、ドキュメント作成を行います。

ステップ 0 -- Git の可用性

上記のコンテキスト収集ブロックで NO_GIT が返された場合、このディレクトリは git リポジトリではありません。以下を表示してください: > Git リポジトリが検出されませんでした -- ブランチ/コミットコンテキストをスキップします。 ステップ 1 に進みます。すべての git ソースフィールド(ブランチ、ログ、差分、ステータス)を空として扱います。

ステップ 1 -- タスクのスコープを決定

$ARGUMENTS が空で、会話に明らかなペンディングタスクがない場合:

計画するタスクがありません。使用方法: /plan <計画したいタスクを説明> ここで終了します。

それ以外の場合:

タスクの目標を1文で言い直します。
境界を列挙します -- スコープ内のもの、スコープ外のもの。
焦点領域を特定します。 タスク説明が広い、または曖昧な場合(例:「マップページをリファクタする」「ダッシュボードを改善する」)、AskUserQuestion を使用してスコープを明確化します。初期コンテキスト収集時に検出された関連カテゴリからアクションボタンを作成します。最後のボタンとして常にフリーテキストオプションを含めます。

例 -- 広い「X ページをリファクタする」リクエストの場合:

{area} のどの側面に計画を焦点を当てるべきでしょうか? ボタン: ["UI/デザイン -- レイアウト、スタイリング、アニメーション", "アーキテクチャ -- 状態管理、コード構造", "パフォーマンス -- ローディング、キャッシング、最適化", "すべて -- フルオーバーホール", "その他(説明します)"]

例 -- 曖昧な「認証を追加」リクエストの場合:

計画はどの認証アプローチをターゲットにするべきでしょうか? ボタン: ["OAuth2 (Google、GitHub)", "メール/パスワード", "マジックリンク", "SSO/SAML", "その他(説明します)"]

明確化質問のルール:
- AskUserQuestion をアクションボタン付きで使用します -- プレーンテキストとして明確化質問をしないでください。
- ボタンオプションはコードベースのコンテキストとタスク領域から導き出します -- 一般的なプレースホルダーを使用しないでください。
- 最後のボタンとして常に「その他」フリーテキストオプションを含めます。
- 最大1つの明確化質問をします。タスクが十分に明確であれば、このステップをスキップします。
- ユーザーが「その他」を選択した場合、フリーテキスト回答を受け入れて続行します。
複雑さを評価します:

複雑さ	シグナル	派遣するエージェント
軽量	1-3ファイル、単一レイヤー、よく理解されている	Explore
標準	3-10ファイル、2つ以上のレイヤー、中程度の不明な部分	Explore + best-practices-researcher
深い	10+ファイル、アーキテクチャへの影響、セキュリティ/認証/決済、不慣れな領域	Explore + best-practices-researcher + architecture-strategist

タスクが単純な場合(単一ファイル、明らかな変更)、AskUserQuestion を使用します:

このタスクは直接実装できるほど単純です。ボタン: ["計画をスキップして直接実装", "それでも計画を作成"]

レビュー修正コンテキストを検出します。 タスクがレビューレポートを参照しているかを確認します:
- $ARGUMENTS に .claude/reports/review-*.md または review-*_*-*-*.md にマッチするパスが含まれている場合、これはレビュー修正計画です。
- レビューレポートパスが検出された場合、それを読んで結果を抽出します。
- .claude/plans/ で同じ review_source frontmatter を持つ既存の計画をチェックします。review_iteration 番号を決定するためにそれらを数えます(最初の修正計画 = 1、2番目 = 2)。
- review_iteration が3以上になる場合、ユーザーに警告します:
  
  これはレビュー修正サイクルのイテレーション {N} になります。最大値は2イテレーションです。残りの結果を手動で対処するか、それらを受け入れることを検討してください。ボタン: ["それでも計画を作成", "停止 -- 手動で対処します"]
- レビューレポートパスとイテレーション番号をステップ 5 に進めて、frontmatter 生成用に保持します。

ユーザーが「計画をスキップ」を選択した場合、ここで終了して実装します。それ以外の場合は続行します。

ステップ 2 -- エージェント発見

派遣する前に利用可能なエージェントを発見します:

レベル 1 -- リサーチエージェント(動的): agents/research/*.md をスキャンします。各 .md ファイルについて、YAML frontmatter を読んで name と description を抽出します。

レベル 2 -- レビューエージェント(選択的): agents/review/*.md をスキャンします。複雑さが Deep で、エージェントの説明がタスク領域と一致する場合にのみ、レビューエージェントを派遣します(例: 構造的変更用の architecture-strategist、認証/セキュリティタスク用の security-audit)。

レベル 3 -- プロジェクトとユーザーエージェント: .claude/agents/*.md と ~/.claude/agents/*.md をスキャンします。description がタスク領域と一致するエージェントを派遣します。

エージェント識別子はプラグインエージェント用に quiver:{name}、プロジェクト/ユーザーエージェント用に {name} を使用します。

ステップ 2.5 -- LSP 検出

エージェントを派遣する前に、LSP の可用性を1回検出します。code-navigation スキルからの検出フローに従います:

キャッシュされた LSP 設定がないかプロジェクトメモリをチェックします(lsp_preference.md)。lsp_declined または lsp_confirmed が見つかった場合、キャッシュされた値を使用してステップ 4 にスキップします。
軽量の LSP プローブ(例: プロジェクトルートから任意のソースファイルの documentSymbol)を試みます。
LSP が利用できない場合、マニフェストファイルからプロジェクト言語を検出し、AskUserQuestion を使用してインストールを提案します:

このプロジェクトでは LSP が利用できません。言語サーバー(例: {language} 用の {recommended_server})をインストールすると、コード移動が改善されます -- go-to-definition、find-references、シンボル検索。セットアップしたいですか?(LSP なしで /plan を使用できます -- grep ベースのナビゲーションは問題なく機能します。)

ボタン: ["はい、セットアップを手伝ってください", "いいえ、grep で続行"]
- ユーザーが受け入れた場合: インストール手順を提供し、再度プローブし、lsp_confirmed をプロジェクトメモリにキャッシュします。
- ユーザーが拒否した場合: lsp_declined をプロジェクトメモリにキャッシュします。
lsp_available を true または false に設定します。このフラグをステップ 3 で派遣するすべてのエージェントに渡します。

ステップ 3 -- 並列エージェント派遣

1つの応答で複数のエージェントツール呼び出しを使用して、すべての適格エージェントを同時に派遣します。すべてのエージェントプロンプトは自己完結型である必要があります -- エージェントはこの会話の記憶がありません。

レビュー修正計画: 削減派遣。 ステップ 1 がレビュー修正コンテキストを検出した場合、レビューレポートはすでに問題と影響を受けたファイルを特定しています。best-practices-researcher と architecture-strategist をスキップします -- スコープが「これらの特定の結果を修正」である場合、彼らは価値を追加しません。ファイルパスと現在のパターンが依然として正確であることを確認するために、Explore エージェントのみを派遣します。

Explore エージェント(常に派遣)

Agent(
  subagent_type="Explore",
  description="計画用のコードベースマップ: {短いタスク要約}",
  prompt="タスク: {ステップ 1 からの完全なタスク説明}

  lsp_available: {ステップ 2.5 からの true|false}

  ## コード移動戦略

  上記に `lsp_available` フラグが提供されています。

  **`lsp_available: true` の場合:**
  - 関数/クラス/型が定義されている場所を見つけるには: LSP goToDefinition を最初に使用します。
  - シンボルのすべての呼び出し元または使用者を見つけるには: LSP findReferences を最初に使用します。
  - ファイルの構造的概要を取得するには: LSP documentSymbol を最初に使用します。
  - LSP が任意の操作に対して空またはヘルプにならない結果を返した場合、ユーザーに通知します:
    'LSP returned no results for {operation} on `{symbol}` -- falling back to grep-based search.'
    その後、Grep をフォールバックとして使用します。
  - ファイル発見とパターンマッチングの場合: LSP の可用性に関わらず常に Grep/Glob を使用します。

  **`lsp_available: false` の場合:**
  - すべてのコード移動に Grep、Glob、Read を使用します。

  ---

  このコードベースでこのタスクに関連するすべてのファイルを検索します。見つかった各ファイルについて報告します:
  1. ファイルパス
  2. その役割の1行説明
  3. 関連するテストファイルがあるかどうか

  また報告します:
  - この領域で使用されている現在のパターン(命名、構造、抽象化)
  - 再利用できる既存のユーティリティまたはヘルパー
  - テストフレームワークと観察された慣例

  ディレクトリに焦点を当てます: {既知の場合は関連ディレクトリ、そうでない場合は「広く走査」}",

)

best-practices-researcher (標準 + 深い)

Agent(
  subagent_type="quiver:best-practices-researcher",
  description="次のベストプラクティスを調査: {短いトピック}",
  prompt="タスクコンテキスト: {完全なタスク説明}

  プロジェクトは以下を使用します:
  - 言語: {プロジェクトファイルから検出}
  - フレームワーク: {検出}
  - 主要ライブラリ: {検出}

  次の技術領域のベストプラクティスを調査します: {タスクが触れる技術領域、例: 「Express でのミドルウェア認証」「Rails でのデータベースマイグレーションパターン」}

  焦点を当てます:
  1. このタイプの作業に推奨されるパターン
  2. 検出されたスタックバージョンの非推奨または破壊的な変更
  3. 避けるべき一般的な落とし穴
  4. 適用されるフレームワーク固有の慣例

  結果を実行可能な状態に保つ -- 各推奨事項は計画ステップに情報を提供できるものである必要があります。",

)

architecture-strategist (深いのみ)

Agent(
  subagent_type="quiver:architecture-strategist",
  description="次のアーキテクチャを分析: {短いタスク要約}",
  prompt="タスクコンテキスト: {完全なタスク説明}

  プロジェクトルートリスト:
  {プロジェクトルートの ls 出力}

  既存のアーキテクチャを分析し、この計画された変更がどのように統合されるべきかを評価します。報告します:
  1. 現在のアーキテクチャパターン(レイヤー境界、依存方向、モジュール編成)
  2. 新しいコードが既存の慣例に従うために存在すべき場所
  3. 境界制約 -- どのレイヤーが違反してはいけないか
  4. 提案された変更の構造的リスク
  5. 依存性の影響

  既存のコード品質をレビューしないでください。新しい作業がアーキテクチャにどのように適合するかに厳密に焦点を当ててください。",

)

ドメイン固有のエージェント(発見され関連する場合)

エージェント発見がタスク領域と説明が一致するプロジェクト/ユーザーエージェントを見つけた場合、同じ自己完結型プロンプトパターンで派遣します。

ステップ 4 -- リサーチを統合

すべてのエージェントが返された後、統一されたリサーチブリーフに結果をマージします:

重複を削除 -- 複数のエージェントが同じファイルまたはパターンを報告する場合、最も詳細なバージョンを保持します。
整理:
- コードベースコンテキスト(Explore から): 影響を受けたファイル、現在のパターン、テストカバレッジ
- ベストプラクティス(best-practices-researcher から): 推奨されるアプローチ、非推奨アラート
- アーキテクチャガイダンス(architecture-strategist から): 構造的制約、新しいコードが属する場所
競合にフラグを立てます -- エージェントが異なる場合(例: ベストプラクティスはパターン A を提案するが、既存アーキテクチャはパターン B を使用)、トレードオフ付きで両方を提示します。静かに解決しないでください。

ステップ 5 -- 計画を設計

統合されたリサーチを使用して、このドキュメント構造と詳細レベルルールに従う計画を作成します:

レベル	複雑さ	セクション
簡潔	軽量	ゴール、ステップ、受け入れ基準
標準	標準	+ コンテキスト(エージェント結果付き)、リスク、ファイルマップ
包括的	深い	+ 検討した代替案、段階的展開、ロールバック戦略、アーキテクチャ制約

ファイル構造マッピング(タスク定義前): 作成、修正、または削除するファイルをマップアウトします。これにより、タスク作成前に分解決定がロックされます。

作成: exact/path/to/new-file.ext -- 1行の目的
修正: exact/path/to/existing.ext -- 何が変わるか、なぜか
テスト: tests/path/to/test-file.ext -- 新しいまたは更新されるテストファイル
削除: exact/path/to/removed.ext -- 該当する場合のみ

タスク粒度:

各ステップ: 2-10分、独立して検証可能
パターン: 何をするか、どのファイル、期待される結果
Explore 結果からの正確なファイルパスを含めます
ベストプラクティスをステップ設計に組み込みます
architecture-strategist からのアーキテクチャ境界を尊重します

TDD タスク構造(プロジェクトがテストを持つ場合): Explore エージェントが既存のテストフレームワークを見つけた場合、TDD サイクルに従う各タスクを構成します:

失敗するテストを書きます(正確なテストコードを表示)
テストを実行します -- 予期されたエラーで失敗することを確認します
最小限の実装を書いて合格させます
テストを実行します -- 合格することを確認します
コミット

すべてのタスクが TDD を必要とするわけではありません(例: 設定変更、ドキュメント、マイグレーション)。テスト可能な動作を生み出すタスクに適用します。

プレースホルダーなしルール: すべてのステップは実行可能な内容を含む必要があります。これらは計画の失敗です -- 決して書かないでください:

「TBD」「TODO」「後で実装」「詳細を記入」
「適切なエラーハンドリングを追加」「バリデーションを追加」「エッジケースを処理」
「上記のテストを書く」(実際のテストコードまたは最低限テストシナリオ説明なし)
「タスク N と同様」(関連する詳細を繰り返します -- 実装者はタスクを順不同で読む場合があります)
何をするかを説明するが、どのようにするかを示さないステップ(コードブロック、コマンド、または正確なファイルパスを含めます)
任意のタスクで定義されていない型、関数、またはメソッドへの参照(ステップが processItems() を呼び出す場合、あるタスクがそれを定義する必要があります)

言語ルール: 会話言語に関わらず、計画ドキュメントは常に英語で書いてください。ユーザーが明確に別の言語を要求した場合にのみ、別の言語で書いてください。

リサーチ統合(必須):

best-practices-researcher が非推奨にフラグを立てた場合、計画は非推奨パターンを避ける必要があります
architecture-strategist が境界制約を特定した場合、ステップはそれらを尊重する必要があります
Explore が既存のテストパターンを見つけた場合、新しいテストステップはそれに従う必要があります
コンテキストセクションで結果を属性付けます: 「(best-practices-researcher から)」「(architecture-strategist から)」

レビュー修正計画 frontmatter(ステップ 1 でレビュー修正コンテキストが検出された場合):

計画の YAML frontmatter にこれらのフィールドを含めます:

review_source: .claude/reports/review-YYYY-MM-DD_HH-MM-SS.md
review_iteration: 1  # 同じレビューをターゲットにする修正計画ごとにインクリメント

受け入れ基準はレビュー修正計画で必須です。 レビュー結果から直接導き出します:

スコープ内の結果1つごとに1つの基準(例: 「ProductBackButton ルートウィジェットは Material で、Positioned ではない」)
検証基準を追加します(例: 「flutter analyze はクリーンに合格」)
これらの基準は完了の定義になります -- work スキルはそれらを使用してレビュー修正サイクルがいつ完了かを判断し、無限の再レビューループを防ぎます

ステップ 6 -- 計画の自己レビュー

計画を作成した後、ユーザーに提示する前にそれをレビューします。これは内部チェックです -- ユーザーに別のセクションとして表示しないでください。

仕様カバレッジ: タスクがブレーンストーム仕様またはレビューレポートから発生した場合、各要件をざっと見ます。それを実装するタスクを指摘できますか? 不足しているタスクを追加します。
プレースホルダースキャン: 「TBD」「TODO」「後で実装」、ファイルパスやコードなしの曖昧なステップを検索します。修正します。
命名の一貫性: 関数名、型名、変数名はタスク全体で一致していますか? タスク 3 で clearLayers() と呼ばれているが、タスク 7 で clearFullLayers() と呼ばれている関数は、計画のバグです。
テストカバレッジ: テスト可能な動作を生じるすべてのタスクに対応するテストステップがありますか? プロジェクトがテストを持つ場合、不足しているテストステップは計画のギャップです。

インラインで問題を修正します。修正後に再レビューする必要はありません -- 修正して進むだけです。

ステップ 7 -- レビューゲート

完全な計画をユーザーに提示します。その後、これらのパラメータで AskUserQuestion ツールを呼び出します:

question: "計画は {N} ステップ({detail_level})あります。どのように進めたいですか?"
header: "計画レビュー"
multiSelect: false
options:
1. label: "承認" / description: "問題ありません。計画を保存して次のアクションを選択します。"
2. label: "変更" / description: "保存する前にいくつかのステップを調整したいです。"
3. label: "却下" / description: "この計画を放棄して、別のアプローチを取ります。"

計画が 15 ステップを超える場合、質問に追加します: " サブ計画に分割するか、作業をフェーズ化することを検討してください。"

各応答を処理します:

承認 -- ステップ 8 に移動します。承認後は停止しないでください。
変更 -- 変更するステップを尋ね、計画を修正し、AskUserQuestion で再提示します。
却下 -- 計画を放棄します。ここで終了します。

ステップ 8 -- 保存とフォローアップ

このステップには2つの必須部分があります。保存後に停止しないでください。

部分 A -- 計画を保存:

.claude/plans/ が存在しない場合は作成します。
計画を .claude/plans/YYYY-MM-DD-<descriptive-name>-plan.md として書き込みます(date '+%Y-%m-%d' を日付プレフィックスに使用)。
検証: ファイルを読み戻して、正しく書き込まれたことを確認します。

部分 B -- フォローアップオプションを提示:

保存直後に、これらの正確なパラメータで AskUserQuestion を呼び出します:

question: "計画は .claude/plans/{filename} に保存されました。次に何をしたいですか?"
header: "次のステップ"
multiSelect: false
options:
1. label: "実装を開始" / description: "work スキルを呼び出し、現在のコンテキストで計画をステップバイステップで実行します。"
2. label: "計画を洗練" / description: "ステップ 5 に戻ってステップ、スコープ、詳細を調整します。"
3. label: "保存して後で再検討" / description: "ここで停止します。計画はディスクに保存されて後で使用できます。"

AskUserQuestion ツールを呼び出す必要があります -- スキップしたり、フォローアップオプションをプレーンテキストとして提示したりしないでください。