plan-work

作業の計画

不確実性の高い作業や大規模な作業を、形式だけを増やすことなく、実行可能な方針にまとめます。

workflow-language.md、document-conventions.md、planning-templates.mdを使用してください。

呼び出しと出力

ユーザーが明示的に依頼した場合、または作業に重大な曖昧さ、調整、横断的な範囲、不可逆性、リスクがある場合に、このスキルを使用してください。新しい作業、複数ステップの作業、または複雑な作業というだけでは、Plan は必要ありません。

明示的に呼び出された場合は、依頼された出力に従ってください。ファイルに書き込まないようユーザーが指定した場合は、計画を立ててチャットで返してください。それ以外の場合は、一時的な Plan を保存するのが既定です。計画プロセスと Plan ファイルの作成は、それぞれ別の判断です。

実装を開始しないでください。

プロセス

1. リポジトリ内の指示、現在のドキュメント、関連コード、既存の Plan または Roadmap を確認します。
2. 設計を大きく左右する未解決の疑問だけを調査します。リポジトリ内の情報と一次情報から調査を始めます。
3. リポジトリから答えを得られない、意思決定を妨げる質問だけをします。関連する質問をまとめ、トレードオフとともに推奨案を示します。
4. 方針にオーナーの承認が必要な場合は、簡潔な Design Brief を提示します。方針がすでに明確な場合は、重複する確認手順を省略します。
5. 依頼された計画成果物を作成します。保存する Plan は plans/<outcome>.md を使用します。複数の Plan に優先順位付けや進捗管理が必要な場合にのみ Roadmap を作成します。
6. 一貫性、実行可能性、範囲、検証、ドキュメントのライフサイクルを確認してから提出します。

ドメイン用語、状態、関係、不変条件、データフロー、アクセスパターンが重要な設計要素である、または不明確である場合は、ロジックを組み立てる前に明示的にモデル化します。重要な用語、関係、不変条件は、現在のコードやドキュメントを参照しながら、具体的なシナリオを1つか2つ使って検証します。リポジトリの用語集を基準とし、設計上の判断を解決する場合にのみ、簡潔なコールスタック、コンポーネントツリー、またはデータフロー図を追加します。正式な用語やドキュメントを暗黙に変更しないでください。将来の変更は、承認されたドラフトまたは Phase を明記した Doc Delta に記録し、オーナーの判断が必要な点を明示します。

未解決の重要な設計判断によって内容が変わる下流の Task を、先走って作成しないでください。ここでいう重要な設計判断とは、想定される回答の違いによって、データやスキーマのモデル、所有権、契約、移行、検証が大きく変わるものです。

検証設計でモジュールのモックや大規模なエンドツーエンドのインフラストラクチャを新たに追加する場合は、依存関係、保守コスト、実行コストを説明し、オーナーが決定すべき事項として明示してください。専門スタックの指針よりも、リポジトリの規約を優先します。

成果物の所有権

• Roadmap は、Plan へのリンク、候補、Plan 間の制約をまとめる簡潔なものです。全体向けでも対象を限定したものでもよく、順序は Loose、Strict、Mixed のいずれかで明示します。実装の成果と阻害要因となる質問を示せるようになるまでは、Candidate を大まかなままにしておき、その後 Plan に昇格させます。
• Plan は、任意の Milestone、Phase、Task、受け入れ基準、検証、レビューの配置、Doc Delta を管理します。
• Phase は実装とレビューの範囲です。各 Phase には、その全範囲を対象とした、前提知識を持ち越さない独立したレビューを含めます。
• 中間レビューのチェックポイントは、影響の大きい Task または Task グループの後にのみ追加します。影響の小さい Task は Phase レビューまで待つことができます。
• Target-State Doc には、現在の永続的な事実を記載します。計画中に修正するのは、その修正内容がすでに事実である場合に限ります。
• 新たに永続的なドキュメントを大規模に提案する場合は、Draft Target-State Doc を使用します。
• 既存の正式なドキュメントに対する将来の変更は、各項目に Phase を明記したうえで、Plan の Doc Delta に記載します。
• ADR は、意外性があり、トレードオフが大きく、元に戻すことが難しい判断に限って使用します。

Plan を作成する前に、単独でも有用な現在のドキュメント、または実質的なドラフトドキュメントだけを作成または更新します。既存ドキュメントの将来の変更は Plan が管理するため、Doc Delta は Plan の一部として作成し、Plan 作成の前提条件にはしません。

計画の品質

実行に必要なコンテキストのみを残します。以下を確認してください。

• 決定事項、ドキュメント、Plan のタスク、受け入れ基準が互いに矛盾していないこと。
• Phase の境界が一貫しており、レビュー可能であること。
• 検証によって、主張する成果を証明できること。
• レビューチェックポイントがタスク数ではなくリスクを反映していること。
• Doc Delta の各項目に明示的な Phase が設定されていること。
• 未解決の決定事項が明らかになっており、後続のタスクが重要な決定への回答を前提としていないこと。
• 該当する場合、重要なドメインおよびデータモデルに関する決定が明示されていること。
• ワークフローファイルを恒久的な製品ドキュメントとして扱っていないこと。

明確な問題はその場で修正してください。ファイルが指定または作成された場合はファイルパスを返し、あわせて簡潔な概要と、引き続き必要なオーナーの決定事項を記載してください。