planning

計画

実行可能な計画を作成するか、既存の計画を強化します。計画だけを行う場合、実装に関する変更は加えません。ユーザーが計画と実装の両方を求めている場合は、計画を完了してから、ホストの現在のモードと権限の範囲内で作業を続けます。

• 作成： 計画がまだない場合は、リポジトリの内容に基づいて方針を立て、計画を記述します。
• レビュー： 計画がすでにある場合は、重要な主張を検証し、ファイルにある具体的な不足を解消します。
• インタビュー： ユーザーが厳しく質問するよう求めた場合や、インタビューを依頼した場合は、対話形式で判断事項を検討します。
• 分割： 独立して納品できる成果が複数ある場合は、ネイティブな依存関係リンクを使ってチケットを作成します。

アーキテクチャの契約には codebase-architecture を、コードに関する調査結果には tidy を使用します。

参考資料

ファイル	読むタイミング
references/decision-briefs.md	重要な判断を人間に提示するとき。選択肢の比較、プレビュー、回答の記録に使用します。
references/interrogation-protocol.md	未解決の選択肢について質問を選ぶとき、またはユーザーがインタビューを依頼したとき。
references/doc-grounding.md	ADR、仕様書、ライブラリのドキュメントが方針を制約するとき。
references/handoff-plans.md	別のセッションや担当者が計画を実行するとき。
references/plan-quality-rubric.md	完全性、実現可能性、スコープ、テスト可能性、リスク、前提条件をレビューするとき。
references/questioning-framework.md	レビューで見つかった不足について、焦点を絞った質問が必要なとき。
references/claim-verification.md	計画の主張をコードやドキュメントで確認できるとき。
references/splitting.md	作業を実行可能なチケットに分解するとき。

ワークフロー

1. 依頼された成果と、計画の正式な保存先を特定します。ホストに計画ファイルの保存先がある場合は、それを使用します。引き継ぎ可能な計画はプロジェクト内のパス（既定値は docs/plans/<slug>.md）に保存し、どのコピーを正式なものとするか明記します。
2. この変更を制約するモジュール、テスト、判断事項を調べます。リポジトリで答えがわかる疑問は、自分で解決します。スコープ、動作、または取り消しが難しい操作に大きく影響する未解決の選択肢についてのみ質問します。日常的な前提は草案に記載します。質問する前に選択肢を比較し、どの条件で推奨案が変わるかを明示します。その判断の鍵となる事実を把握しているのが人間だけの場合は、その事実について直接尋ねます（references/decision-briefs.md）。
3. 実際の境界を検証できる、最小の垂直スライスを選びます。拡張する既存コードやプラットフォーム機能を明記します。新しい依存関係や抽象化を導入する場合は、既存の仕組みでは満たせない現行の要件を示す必要があります。
4. 次の契約に沿って計画を記述します。重要な主張をルーブリックに照らして一度レビューし、根拠のある不足を直接修正します。引き継ぎ用の計画では、references/handoff-plans.md に記載された、見知らぬ人が読んでも理解できるかの確認も行います。インタビューモードでは複数の方針を検討できますが、質問数に最低要件はありません。
5. 計画のパス、未解決の判断事項、検証上の制約を回答します。モードで必要な場合は、ホストの承認メカニズムを使用します。計画自体のレビューに対して、別途承認を求めてはいけません。

計画の契約

この変更に必要なセクションのみを含めます。

• 成果： 発生している問題、意図する動作、受け入れ基準。クライアントや会議からの要件には、出典（タイムスタンプ、ドキュメントのバージョン、スクリーンショット）を記載し、「決定済み」「提案」「推定」のいずれかを明記します。
• アプローチ： 選択した変更範囲、影響を受けるファイルやインターフェース、該当する場合は移行の順序。
• 決定事項： 決定の記録。質問、選択内容、決定者と決定日、選択肢ごとの測定済みの根拠、それを覆す条件を記載します。未検証の仮定も記録します。
• 対象外： 隣接する変更がこの範囲に含まれると誤解される可能性がある場合に限り、対象外の内容を記載します。
• 検証： 重要な各受け入れ基準に対応するコマンド、テストシナリオ、または観察結果を記載し、想定される失敗時の動作も含めます。
• ドキュメント： この変更によって誤りになる既存のドキュメント（ドキュメント索引の「Current」エントリーなど、リポジトリが最新状態を保つものとしているドキュメント）を挙げ、同じ PR で更新します。
• 復旧： 移行や取り消せない書き込みに対するロールバックまたは復旧方法を記載します。

引き継ぎ内容は、それだけで完結している必要があります。「話し合ったとおり」ではなく、決定事項を記載します。ユーザーによる修正は、チャットだけでなくファイルにも反映します。チケットはデータベース／バックエンド／フロントエンドのレイヤーではなく、単独でリリース可能な成果ごとに分割します。

レビューの完了

コード、タスク、または運用上の制約によって裏付けられる不足を解消します。自己評価を上げるために推測上の要件を追加してはいけません。スコアは、求められない限り任意です。スコアを使う場合は、未検証の主張に印を付け、すべての項目が 5/5 になるまで繰り返すのではなく、残る不足を説明します。

実質的な編集または新しい根拠があった場合に限り、レビューを繰り返します。未回答のユーザー判断は、該当するステップに記録し、独立して進められる作業は続けます。ユーザーが質問を省略するよう求めた場合は、利用可能な根拠に基づいて草案を作成し、仮定にその旨を明記します。

注意点

• ~/.claude/plans/ にある計画は、他のチェックアウトや CI からは参照できません。永続的な引き継ぎには、プロジェクト内の成果物が必要です。
• 「テストを実行する」というだけの手順では、変更後の動作を確認できません。受け入れシナリオと期待される結果を明記します。
• ネイティブなブロッカー関係を設定せずに変更範囲を公開すると、実行キューは依存関係を把握できません。
• トランスクリプトやドキュメントの要約、または一部の取得は、全体を読んだことにはなりません。全文を読んだソースを記録し、一部しか確認していないのに全体を確認したと報告してはいけません。
• もっともらしいプレースホルダー（デモ用ログイン情報、偽のキー、推測したドメインや役割）は、決定済みの内容に見えたままリリースされます。不足している項目にはそれぞれ印を付け、誰が情報を提供するのかを明記します。期限や予算が記載されていない場合は、「不明」であり、ゼロや無制限ではありません。
• 「完了」は、テスト合格、マージ済み、本番稼働と検証済み、依頼者による承認など、さまざまな状態を意味します。各検証基準では、どの状態を確認するものかを明記します。
• 以前のリビジョン向けに書かれた計画には、移動済みのファイルが記載されている場合があります。重要なパスやインターフェースを現在のチェックアウトで確認します。

メンテナンス専用：evals/evals.json には、このスキルへの変更に対する回帰シナリオが含まれています。ユーザーのタスク中には読み込まれません。