executing-plans

プランの実行

概要

プランを読み込み、批判的にレビューし、すべてのタスクを実行して、完了時に報告します。

開始時に宣言: 「プランを実装するため、executing-plans スキルを使用しています。」

複雑な実行では、Aegis Visibility を含め、進行中の作業範囲をプラン、チェックポイント、逸脱または検証の境界に簡潔に結び付けます。完了時には、プランへの準拠状況、根拠、複雑さ、残存リスクを verification-before-completion に渡し、統合レシートを作成します。

サブエージェントが利用可能で、プランに真に独立したタスクがある場合は、subagent-driven-development を優先してください。サブエージェントを利用できなくても、インラインでの実行を妨げることはありません。同じタスクに取り組むエージェントは同じワークスペースを共有し、Git を変更する権限を持つのは引き続きコーディネーターだけです。

プロセス

ステップ 1：プランの読み込みとレビュー

1. プランファイルを読みます
2. プランまたはアクティブなチェックポイントに Execution Readiness View が含まれている場合は、実装前に読み、その意図の固定、スコープの境界、ベースラインの固定、担当者／契約上の制約、互換性の境界、廃止の境界、テスト要件、レビューゲート、逸脱／巻き戻しルール、完了前に必要な根拠と照らしてプランを確認します。
3. 批判的にレビューし、プランについての疑問や懸念を特定します
4. ビューがプラン、ベースライン、または現在のワークツリーの根拠と矛盾する場合は、編集を始めず、プランレビューに戻るか、助言の引き継ぎ情報を更新します。
5. 実装前に TDD Route Guard を実行し、Mode、Decision、Strict authority、厳格モードのシグナル、ライトモードの適格性、Test posture、検証を確認します。厳格ステップには、明示的なユーザー／プロジェクトの要請、または記録された自動判定のいずれかが必要です。プランの承認やリスクラベルだけでは根拠になりません。オフモードで記録がない場合は、TDD を読み込まずに Mode: off / Decision: skipped としてのみ修正できます。自動判定がない、または未対応の場合は、プランレビューに戻ります。厳格モードのシグナルが存在する場合、または小規模／低リスク／単独担当／動作変更なしという根拠が不完全な場合、自動ライトモードの記録は未対応です。Decision: strict が記録され、厳格モードの根拠がある場合に限り、Write failing test、Verify RED、GREEN、REFACTOR と名付けられたステップを実行できます。実行中に strict と推定してはいけません。
6. 懸念がある場合は、開始前に人間のパートナーに伝えます
7. 最初の書き込み前に TaskStartSnapshot を取得します。内容は、ルート、HEAD、ブランチまたはデタッチ状態、上流との差分、ステージ済み／未ステージ／未追跡のパス、進行中の Git 操作、git worktree list --porcelain です。タスク開始前から存在する状態を保持し、それを stash、reset、clean、commit してはいけません。
8. 独立した履歴がルールで求められる場合や、別の目標がそのブランチを所有している場合を除き、現在のブランチを再利用します。正当な理由があれば、安全な場合に現在のワークスペースでブランチを切り替えるか作成できます。ワークツリーを使うには、同時チェックアウト、またはブロックする未コミット状態への対処が必要です。
9. 懸念がなければ、TodoWrite を作成して進めます

ステップ 1.5：長期タスクのチェックポイント設定

プランに複数のタスクがある場合、セッションをまたぐ可能性がある場合、またはアーキテクチャ／契約／ワークフローの変更を含む場合：

1. 次のように宣言します。「チェックポイントを維持し、逸脱を把握するため、long-task-continuation スキルを使用しています。」
2. aegis:long-task-continuation を読み込みます。
3. プランから初期チェックポイントを作成します。
   • 現在の Todo
   • アクティブなタスク
   • 完了済みのタスク
   • 根拠の参照先
   • ブロッカー
   • 次のステップ
4. 各タスクの前に、現在のチェックポイントを再確認します。
5. 各タスクの後に、チェックポイント、根拠の参照先、逸脱チェックを更新します。

検証を受けた計画外の編集を行う前に、保持されている PatchShape、CanonicalOwner、UpwardDrillSignal、結果、根拠の参照先を読みます。編集候補との比較を systematic-debugging に回してから編集し、各方針が収束するかを判断してもらいます。独立した正規オーナーの原因が実証された場合は、通常のプラン経路を進めます。

ステップ 2：タスクを実行する

インターフェースやインタラクションを変更する場合は、影響する編集の前に ui-ux-governance を適用し、関連するユーザー接点で計画に定めた対象範囲のエクスペリエンス基準を確認してください。

各タスクについて：

1. 状態を in_progress にする

2. 各ステップを正確に実行する（計画には細分化されたステップがあります）

3. タスクによって新しいソースコードパスを追加する前に、計画の Change Necessity を言い直すか、計画に引き継がれていない場合は簡潔な内容を作成します。 計画の承認だけでは、新しいヘルパー、小さなガード、新しい分岐、フォールバック、アダプター、または担当者が必要である証明にはなりません。

   Change Necessity:
   - User-visible need:
   - No-change / non-code option:
   - Why code change is necessary:
   - Minimum change boundary:
   - Decision: no-change | docs/config-only | code-change | needs-clarification
   

   判断が code-change でない場合は、編集せずに実行を一時停止し、計画のレビューに戻ってください。判断が code-change の場合は、最小限の境界を編集と検証の対象範囲に引き継いでください。

4. 非自明なソース編集の前に、計画の Pre-Edit Complexity Check を実行するか、簡潔な内容を作成してください。

   共有アーティファクトの分類、負荷の兆候、および over-budget の扱いには using-aegis/references/complexity-governance.md を使用してください。

   Complexity Budget:
   - Artifact class:
   - Target files / artifacts:
   - Current pressure:
   - Projected post-change pressure:
   - Budget result: within-budget | at-risk | over-budget
   - Planned governance:
   
   Pre-Edit Complexity Check:
   - Target edit file:
   - Existing pressure signal:
   - Safer edit boundary:
   - Decision: edit-in-place | extract helper | add owner file | split task | pause for plan update
   
   Pre-Edit Owner-Fit Decision:
   - Edit intent: wiring-only | move-out / extract-first | local-fix-without-new-responsibility | new-responsibility | emergency / compatibility patch
   - Owner fit:
   - Safer edit boundary:
   - Decision: edit-in-place | extract helper | add owner file | split task | pause for plan update
   

   チェック結果が計画のファイル境界と矛盾する場合は、過負荷の担当箇所に黙ってロジックを詰め込まず、実行を一時停止して計画のレビューに戻ってください。予算の判定が over-budget で、タスクがその超過も対象としていない場合は、タスクを依然として不可分であるかのように無理に進めず、実行を停止して計画のレビューに戻ってください。 対象の編集ファイルが予算超過または複数の目的を持つ場合、デフォルトでは new-responsibility をその場に追加してはいけません。新たな責務を追加せず、検証境界が明確である場合に限り、wiring-only、move-out / extract-first、および local-fix-without-new-responsibility は進められます。emergency / compatibility patch には、残存リスクと解消のトリガーが必要です。

5. 指定されたとおりに検証を実行する

6. コーディネーターが Git 変更の担当者です。一連のタスクが計画された検証に合格したら、デフォルトのローカルコミットの前に verification-before-completion を使用し、タスクが所有するパスのみをステージし、HEAD、コミットされたファイルの一覧、および残りのタスク差分を読み返してください。no commit、読み取り専用、変更なし、検証失敗のタスクでは、通常のコミットを作成しません。

7. タスクを完了にする前に TodoCheckpointDraft と DriftCheckDraft を更新してください。 Execution Readiness View が存在する場合、ドリフトチェックでは、アクティブな範囲をビューの意図ロック、スコープ境界、ベースラインロック、互換性境界、解消境界、テスト要件、およびレビューゲートと明示的に照合する必要があります。

8. 状態を completed にする

ステップ 3：開発を完了する

すべてのタスクが完了し、検証された後：

• Aegis がブランチまたはワークツリーを作成した場合、あるいはユーザーが統合処理を求めている場合は、 aegis:finishing-a-development-branch を使用します。
• それ以外の場合は、verification-before-completion を使用し、ローカルタスクのコミットと Task clean / Repository clean を報告します。マージや PR の手順を勝手に作り出さないでください。

停止して助けを求める場合

次の場合は、ただちに実行を停止してください：

• 障害に遭遇した（依存関係の不足、テスト失敗、指示が不明確）
• 作業を開始できないほど計画に重大な不備がある
• 指示を理解できない
• 検証が繰り返し失敗する

推測せず、確認を求めてください。

以前のステップに戻る場合

次の場合は、レビュー（ステップ 1）に戻ってください：

• フィードバックに基づいてパートナーが計画を更新した
• 根本的なアプローチを再考する必要がある

障害を無理に乗り越えないでください。停止して助けを求めてください。

注意事項

• まず計画を批判的にレビューする
• 計画のステップに正確に従う
• 検証を省略しない
• 計画で指示されている場合はスキルを参照する
• 阻まれたら推測せず停止する
• 現在のブランチが main / master だからという理由だけでブランチを作成しない
• タスクの複雑さ、TDD、計画、またはサブエージェントだけを理由にワークツリーを作成しない

統合

必須のワークフロースキル：

• aegis:writing-plans - このスキルが実行する計画を作成します
• aegis:using-git-worktrees - 承認された Git のライフサイクルで並行チェックアウトが必要とされている場合に限ります
• aegis:finishing-a-development-branch - ブランチ／ワークツリーの統合またはクリーンアップが対象となる場合に限ります