plan-two

[IMPORTANT] 開始前に、TaskCreate を使って作業をすべて小さなタスクに分割してください。各ファイルの読み取りもタスクに含めてください。長いファイルによるコンテキストの喪失を防ぐためです。簡単なタスクの場合、AI は必ずユーザーにスキップするかどうかを尋ねてください。

まずコードを理解する — 厳格な必須条件：既存のコードを読むまで、記述、計画、修正を行わないでください。

1. 類似パターンを3つ以上検索し（grep／glob）、file:line 形式で根拠を示す
2. 対象領域の既存ファイルを読み、構造、基底クラス、規約を理解する
3. .code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行する
4. connections または callers_of を使って依存関係を把握し、対象に依存しているものを確認する
5. 複雑なタスク（3ファイル以上）では、調査内容を .ai/workspace/analysis/ に記録する
6. 実装前に分析ファイルを読み直す。記憶だけを頼りに作業しない
7. 既存のパターンが使える場合、新しいパターンを決して作らない。完全に合わせるか、逸脱を文書化する

以下を完了するまで作業不可： - [ ] 対象ファイルを読む - [ ] 3つ以上のパターンを検索する - [ ] グラフをトレースする（graph.db が存在する場合） - [ ] 根拠をもとに前提を検証する

見積もり — 修正版フィボナッチ数列：1（ごく簡単）→ 2（小規模）→ 3（中規模）→ 5（大規模）→ 8（非常に大規模）→ 13（エピック、分割を推奨）→ 21（必ず分割）。計画のフロントマターに story_points と complexity を出力してください。複雑度は自動導出されます：1～2＝低、3～5＝中、8＝高、13以上＝重大。

計画の品質 — 計画の各フェーズには、必ずテスト仕様を含めてください。

1. 各フェーズのファイルに ## Test Specifications セクションを追加し、TC-{FEAT}-{NNN} ID を付与する
2. すべての機能要件を1つ以上の TC に対応づける（または根拠を明記して TBD とする）
3. TC ID は TC-{FEATURE}-{NNN} 形式にする。内容全体を埋め込まず、ID を参照する
4. 新しいワークフローのステップに着手する前に、TaskList を呼び出し、フェーズのファイルを読み直す
5. コンテキスト圧縮時は、まず TaskList を呼び出す。タスクを重複して作成しない
6. 完了とする前に、フェーズごとに TC の充足を確認する（根拠は TBD ではなく file:line で示す）

モード： TDD を優先 → 既存の TC を Evidence: TBD で参照する。実装を優先 → TBD を使い、完了後に /tdd-spec で補完する。

段階的なフェーズ品質 — 計画前に複雑度を評価する。

複雑度の指標： ファイル数が5を超える場合は+2、サービスをまたぐ場合は+3、新しいパターンの場合は+2、DB の移行の場合は+2 スコアが6以上の場合 → 必ずフェーズに分解する。各フェーズの条件：

• 変更するファイルは5つ以下
• 作業時間は3時間以下
• 次のサイクルに従う：計画 → 実装 → レビュー → 修正 → 検証
• フェーズ N が VERIFY に合格するまで、フェーズ N+1 を開始しない

フェーズの成功条件 = すべての TC に合格し、code-reviewer エージェントが承認し、重大な指摘がないこと。

• docs/test-specs/ — モジュール別のテスト仕様（計画にテスト戦略を含めるため、既存の TC を読む）

スキルのバリアント： /plan のバリアント。比較用に、実装アプローチを2つ作成します。

概要

目標： 問題領域を調査し、ユーザーが比較して選択できる、異なる2つのアプローチによる実装計画を作成します。

ワークフロー：

1. 調査 — 問題領域を徹底的に調査する
2. アプローチ A — トレードオフを示しながら、最初の実装アプローチを設計する
3. アプローチ B — トレードオフを示しながら、代替アプローチを設計する
4. 比較 — ユーザーが決定できるよう、並べて比較する

主なルール：

• 計画のみ：実装せず、比較計画の作成だけを行う
• どちらのアプローチも実際に実現可能なものにする。現実的な案と、意図的に弱い案を並べない
• 計画作成後は必ず /plan-review を提案する

懐疑的な姿勢で、批判的思考と段階的思考を適用してください。すべての主張に追跡可能な根拠を付け、確信度をパーセンテージで示してください（Idea は80％超であること）。

planning スキルを有効にしてください。

計画のみ — ユーザーとの協力が必要です

絶対に EnterPlanMode ツールを使用しないでください。すでに計画ワークフロー中です。 絶対にコードの変更を実装または実行しないでください。 ユーザーと協力してください。判断が必要な質問をし、おすすめの選択肢を提示してください。 計画の作成後は、必ず /plan-review を実行して計画を検証してください。 次のステップに進む前に、必ずユーザーに計画の確認を求めてください。

ミッション

planner サブエージェントを使用して、次のタスクに対する詳細な実装計画を2つ作成します。 $ARGUMENTS

ワークフロー

1. 最初に、注入されたコンテキストの ## Naming セクションにある命名パターンに従ってディレクトリを作成します。 プロセス中、すべてのサブエージェントに必ずディレクトリパスを渡してください。
2. planning スキルの「Plan Creation & Organization」ルールに厳密に従ってください。
3. 複数の researcher エージェントを並行して使用してタスクを調査します。各エージェントは異なる側面を調査し、調査は最大5回（ツール呼び出しは最大5回）まで行います。
4. scout エージェントを使用して、タスクの完了に必要なファイルをコードベースから検索します。
5. メインエージェントは、すべての調査結果と scout のレポートファイルパスを収集し、詳細な指示とともに planner サブエージェントに渡して、このタスクの実装計画を作成させます。 出力： 明確なトレードオフを含む実装アプローチを少なくとも2つ提示し、それぞれの長所と短所を説明して、おすすめのアプローチを示します。
6. メインエージェントは planner サブエージェントから実装計画を受け取り、ユーザーに計画の確認を求めます。

計画ファイルの仕様

すべての plan.md は、必ず次の YAML フロントマターで始めてください。

```yaml
---
title: '{Brief title}'
description: '{One sentence for card preview}'
status: pending
priority: P2
story_points: { 1-21 modified fibonacci }
effort: { sum of phases, e.g., 4h }
branch: { current git branch }
tags: [relevant, tags]
created: { YYYY-MM-DD }
---
```

重要なタスク計画上の注意事項（必ず従ってください）

• 作業は必ず細かな todo タスクに分割し、TaskCreate を使用してください。
• 作業の品質を検証し、修正や改善点を特定する最終レビューの todo タスクを必ず追加してください。
• 必須の最終タスク： 計画に関するすべての todo タスクを作成した後、必ず次の3つの最終タスクを追加してください。
  1. タスク：「各フェーズのテスト仕様を作成する」 — すべてのフェーズファイルに、TC-{FEAT}-{NNN} ID を付けた ## Test Specifications を追加します。機能ドキュメントがある場合は /tdd-spec を使用してください。TDD ファーストモードの場合は Evidence: TBD を使用してください。
  2. タスク：「/plan-validate を実行する」 — /plan-validate スキルを起動して、ユーザーに重要な質問をし、計画の前提条件を検証します。
  3. タスク：「/plan-review を実行する」 — /plan-review スキルを起動して、計画の妥当性、正確性、ベストプラクティスへの準拠を自動レビューします。

重要事項

重要： スキルカタログを分析し、プロセス中に必要なスキルを有効化してください。 重要： レポートを作成する際は、簡潔さを優先し、文法的な自然さは二の次にしてください。 重要： 品質を保ちながら、トークン効率を確保してください。 重要： レポートの最後に、未解決の質問があれば列挙してください。

計画作成後の検証

計画の作成後、AskUserQuestion ツールを使用して、次の質問をしてください。「計画を検証するために /plan-review を実行しますか。それとも実装に進みますか？」次の選択肢を提示してください。

• 「/plan-review を実行する（おすすめ）」— /plan-review を実行して計画を検証します
• 「実装に進む」— 検証を省略して実装を開始します

注意 — 計画のみを行うコマンド

絶対に EnterPlanMode ツールを使用しないでください。 絶対に実装を開始しないでください。 計画作成後は、必ず /plan-review で検証してください。 実装を始める前に、必ずユーザーに計画の確認を求めてください。

次のステップ（単独実行：ユーザーへの確認には必ず AskUserQuestion を使用してください。ワークフロー内の場合はスキップしてください。）

必須・重要・必ず対応 — 例外なし： このスキルがワークフロー外で呼び出された場合は、必ず AskUserQuestion を使用して以下の選択肢を提示してください。タスクが「簡単」または「明白」に思えても、スキップしてはいけません。決めるのはユーザーです。

• 「完全なワークフローに進む（推奨）」 — ここから続けるのに最適なワークフローを検出します（計画は作成済みです）。これにより、レビュー、検証、実装、テストの手順を省略せずに済みます。
• 「/plan-review」 — 計画の妥当性とベストプラクティスを自動レビューします
• 「/plan-validate」 — 計画上の決定事項を確認するため、ユーザーに質問します
• 「スキップして手動で続ける」 — ユーザーが決定します

すでにワークフロー内の場合はスキップしてください。手順の順序はワークフローが管理します。

終了時の確認事項

• 重要・必ず対応 作業を始める前に、TaskCreate を使って作業を小さな ToDo タスクに分けてください

• 重要・必ず対応 新しいコードを作成する前に、コードベースで類似パターンを3つ以上検索してください

• 重要・必ず対応 実行に移す根拠となるすべての主張に file:line 形式の証拠を示してください（確信度 >80%）

• 重要・必ず対応 作業の品質を確認する最終レビューの ToDo タスクを追加してください

• 重要・必ず対応 計画のフロントマターに「Test Specifications」セクションと story_points を含めてください

• 重要・必ず対応 変更を加える前に、既存パターンを3つ以上検索し、コードを読んでください。graph.db が存在する場合は、グラフトレースを実行してください。

• 重要・必ず対応 計画のフロントマターに story_points と complexity を含めてください。SP > 8 の場合は分割してください。

• 重要・必ず対応 ## Test Specifications にフェーズごとの TC ID を含めてください。新しいタスクを作成する前に TaskList を呼び出してください。

• 重要・必ず対応 まず複雑さを評価してください。スコアが6以上の場合は分解してください。各フェーズで、計画 → 実装 → レビュー → 修正 → 検証を実施してください。省略してはいけません。