planning

計画

実装リスクを抑え、再構築にコストがかかる状態を維持できる、最小限の計画を作成します。ユーザーの要件と検証済みの事実が計画の根拠です。参照実装は動作に関する証拠を示すものであり、スコープを変更する独立した根拠ではありません。

手順

1. 具体的な成果、証拠、二値または定量的な成功基準、スコープの境界、停止条件を定義します。依頼で成果物と成功の判断基準がすでに示されている場合は、それらを使用します。そうでない場合は、計画を立てる前に、作業内容だけを示す目標を修正します。
2. 目的と提案された仕組みを分けます。実装方法が変わっても目標は妥当でしょうか。コンポーネントの内部を知らなくても同僚が目的を理解し、検証できるようにします。
3. 相互に依存するフェーズ、復旧の必要性、またはコンテキストの上限を超える作業には、完全な永続的計画を選びます。1回のセッションで完了できる明確な作業にはインラインリストを、スコープと受け入れ基準が明確な作業には直接実装を選びます。ファイル数やツール呼び出し数は判断材料であり、決定基準ではありません。作業を単純だと判断する前に、キャッシュの TTL、無効化、キーの形式など、隠れた判断事項を確認します。
4. 既存のテスト、標準的なコマンド、関連コード、既存のブレインストーミング仕様を確認します。リポジトリの既存のパターンを踏襲します。必要に応じて、重要なアーキテクチャ上のトレードオフを、そのリポジトリの ADR 規約に従って記録します。
5. ファイル、担当者、インターフェース契約、依存関係、具体的なタスク、検証方法、終了条件を定義します。実装とテストをまとめた、実行可能な機能を軸にフェーズを構成します。ばらつきの大きい判断は機械的な作業より前に行い、実行依存関係はフェーズの順序に反映します。
6. 計画をユーザーの要件と照らし合わせて検証します。フェーズの進捗状況と次の手順に食い違いがないようにします。不完全なコードに合わせて受け入れ基準を緩めたり、推測に基づくチェックや仕組みを追加したりしてはいけません。
7. 計画のみを依頼された場合は、計画を提示します。実装がすでに許可されている場合は、そのまま実装を続けます。実行モードによってコスト、リスク、分離性、またはレビューの品質が大きく変わる場合に限り、実行方法を確認します。

永続的な状態

完全な作業計画を作成する場合は、plan-format.mdを読み、呼び出し元の作業ディレクトリではなく、インストール済みスキルのディレクトリを基準にしてinit-plan.shでひな形を作成します。プロジェクトですでに仕様や計画のシステムを使用している場合は、そのシステムの成果物形式を維持します。スキルが担うのは、明確化、内容、承認のゲートであり、表現形式ではありません。それ以外の場合は、未コミットのセッション状態には.plan/task_plan.mdを、正式にコミットする計画にはdocs/plans/を使用します。

既存の計画を上書きする前に確認します。同じ作業はそのまま継続します。別の作業によって未チェックのタスクが置き換えられる場合は、どちらの計画を優先するか確認します。トラッカーの項目も含め、未完了の作業を黙って破棄したり、一括でクローズしたりしてはいけません。--forceは、選択を解決した後に限り使用します。追加の成果物は、依頼された成果物である場合、または主計画では明確に表現できない状態を示す場合に限って追加します。

条件に応じたガイダンス

• 目標が曖昧な場合、目的を装った実装案が示されている場合、または計画の深さを選ぶ場合は、goal-definition.md を読んでください。
• 完全な計画、テンプレート、テストの洗い出し、ソースの参照先、インターフェースの選択、または計画の品質レビューについては、plan-format.md を読んでください。仕様の値は正確に保持し、すべてのタスクで具体的なパスまたはコマンドを明記してください。
• フェーズを分割する場合、担当を割り当てる場合、または何を確認する必要があるかを判断する場合は、task-design.md を読んでください。技術的な詳細を選ぶ前に、既存のユーザーの選択とプロジェクトの制約を尊重してください。結果に大きな違いが生じる場合や権限が不明確な場合はエスカレーションし、通常の実装上の判断は実装者に委ねてください。
• 垂直分割、チェックポイント、参照セマンティクス、フェーズの進め方、または委任実行については、execution-and-methodology.md を読んでください。
• 複数フェーズの作業を開始する場合、または中断後に再開する場合は、復旧、コンテキストの確認、エラー処理について operational-patterns.md を読んでください。
• 既存の計画をさらに詳細化する場合は、plan-deepening.md を読んでください。構成を維持し、対象を絞った調査を追加してください。
• 実行方針を選ぶ場合、引き継ぐ場合、または関連するスキルを統合する場合は、execution-handoff.md を読んでください。

権限と検証

アクティブなハーネスの質問ツールは、スキーマとコンテキストが許す場合に使用してください。それ以外の場合はチャットで質問してください。重要な不明点はまとめて確認し、通常の詳細については安全な前提を置き、質問数を決して捏造しないでください。

各タスクが動詞から始まり、具体的で、独立して検証可能であり、会話の履歴がなくても理解できることを確認してください。タスク間で命名とインターフェースの一貫性を確認してください。各フェーズには、実行可能な機能、明示的な検証、コンテキストを損なわずに復旧できる境界が必要です。プロセス項目では、それが対象とする機能または観測された不具合を明記してください。未解決の質問には、作業を阻む不明点のみを含めてください。計画書があるだけでは、実装の進捗が確立されたことにはなりません。

要件が曖昧な場合は ia-brainstorming を使用してください。新たな信頼境界、認証、決済、外部 API に重大な変更を加える場合は、実装前に該当するセキュリティ脅威モデリングレビューを受けてください。文章には ia-writing を使用してください。実行していないチェックに合格したと主張せず、計画の保存先、重要な決定事項、残っている阻害要因を報告してください。