st-execute-blueprint

st-execute-blueprint

入力

ユーザーは計画 ID を会話形式で指定します。

実行手順

1. strikethroo のルートを特定する

ユーザーの作業ディレクトリから scripts/find-strikethroo-root.cjs を実行します。終了コードが 0 以外の場合は停止し、ユーザーに npx strikethroo init を実行するよう依頼します。

そのスクリプトが出力したパスを、以降のすべての手順で <root> として扱います。

委任された実行ワーカーはこの手順を省略し、更新通知を出しません。

このスキルのスクリプトパスを使い、ユーザーの作業ディレクトリを維持したまま、別個のコマンドとして scripts/check-for-updates.cjs "<root>" を実行します。標準出力に出力される 1 行の JSON を読み取ります。notice が含まれている場合は、その正確な文面をユーザー向けの最終回答用に保持します。許可を求めて処理を中断したり、更新を実行したりしてはいけません。

2. 計画を解決する

計画ファイルの絶対パスを得るため、scripts/validate-plan-blueprint.cjs <plan-id> planFile を実行します。別のフィールド名を指定すると、そのフィールドが出力されます。

スクリプトの終了コードが 0 以外の場合は停止し、ユーザーに計画 ID の確認を依頼します。別の ID を推測してはいけません。

<plan-dir> として扱う出力パスを得るため、scripts/validate-plan-blueprint.cjs <plan-id> planDir を実行します。

3. タスクとブループリントの存在を検証する

scripts/validate-plan-blueprint.cjs <plan-id> taskCount と scripts/validate-plan-blueprint.cjs <plan-id> blueprintExists を実行します。

4. タスクまたはブループリントがない場合は自動生成する

taskCount が 0、または blueprintExists が no の場合：

ユーザーに次のように通知します。「タスクまたは実行ブループリントが見つかりません。タスクを自動生成します...」

• この計画 ID に対して st-generate-tasks スキルに従います。実行ブループリントを書き込むための POST_TASK_GENERATION_ALL.md の実行を含め、操作手順をすべて実行します。
• 解決済みのパスと件数を更新するため、planFile、planDir、taskCount、blueprintExists の各クエリを再実行します。

計画にタスクがない、またはブループリントがない状態が続く場合は停止し、失敗を報告します。

5. 必要に応じてフィーチャーブランチを作成する

フェーズの実行前に、scripts/create-feature-branch.cjs <plan-id> を 1 回実行します。スキップされても失敗ではありません。現在のブランチで続行し、手作業でブランチを作成してはいけません。未コミットまたは未追跡の変更が許可されるのは、リポジトリルートの .ai/strikethroo サブツリー内だけです。エラー結果の場合は実行を停止して報告します。

続いて、レビューゲートが差分の比較に使うコミットを記録するため、scripts/capture-base-commit.cjs <plan-id> を 1 回実行します。skipped の場合は実行を続行し、レビューゲートがスキップされることを意味します。停止するのは error の場合だけです。

6. プロジェクトのコンテキストと実行ブループリントを読み込む

次のファイルを順番に読み込みます。

• <root>/config/STRIKETHROO.md
• 手順 2 で取得したパスにある計画ドキュメント。フェーズのグループ分けとタスクのディスパッチ順序を定義する「実行ブループリント」セクションも含みます。
• <root>/config/shared/verification-gate.md と <root>/config/shared/anti-rationalization.md。どちらも以下のフェーズループで適用します。

7. フェーズを順番に実行する

進捗の監視には、内部のタスクまたは TODO トラッカーを使用します。「実行ブループリント」で定義されている各フェーズについて、次の手順を実行します。

7a. フェーズ実行前の確認

scripts/check-phase-readiness.cjs <plan-id> <phase-number> を実行します。スクリプトの終了コードが 0 以外の場合は、そのフェーズを停止し、続行する前に阻害要因を報告します。

フェーズを開始する前に、<root>/config/hooks/PRE_PHASE.md を読み、その指示を実行します。

7b. タスクの割り当て

このフェーズで予定されており、依存関係がすべて満たされているタスクをすべて特定します。タスクを割り当てる前に、<root>/config/hooks/PRE_TASK_ASSIGNMENT.md を読み、その指示に従ってエージェントを選択してください。

選択した各タスクの実行ルートを、まずすべて解決します。選択したタスクごとにリゾルバーを1つ起動し、単一の並列ツール操作で同時に実行してください。

scripts/dispatch-task-execution.cjs resolve <task-file> <current-harness> <workspace> <plan-id> <task-id>

リゾルバーは外部プロセスを起動しません。すべてのルート結果を解釈した後、外部実行とサブエージェントをすべて、単一の並列ツール操作でまとめて実行します。外部実行には以下を使用します。

scripts/dispatch-task-execution.cjs execute <handoff> <task-file> <current-harness> <workspace> <plan-id> <task-id>

<current-harness> は、このスキルを実行している、サポート対象のハーネスの正確な識別子です。<workspace> は、プロジェクトの作業ディレクトリです。

1行の JSON 結果を解釈し、その kind に対して以下のとおり正確に1回だけ対応してください。

kind	必須の対応
native-default	実行設定についての文章を付けずに、ネイティブでタスクを割り当てます。
native-override	返された model を正確に指定して、ネイティブでタスクを割り当てます。reasoningEffort プロパティが含まれている場合に限り、返された reasoningEffort も指定します。
external-override	返された handoff を指定して execute コマンドを実行し、その結果をこの表に照らして確認します。
fallback	何も起動されていません。返された reason と detail を目に見える形で記録し、実行設定についての文章を付けずにネイティブでタスクを割り当てます。
launched-success	外部プロセスは終了コード 0 で終了しました。ネイティブエージェントの場合と同様に、ステータスと証拠を確認します。ネイティブでタスクを割り当てないでください。
launched-failure	タスクは失敗です。ステータスを failed に設定し、<root>/config/hooks/POST_ERROR_DETECTION.md を実行してください。ネイティブで再試行してはいけません。
infrastructure-failure	直前の行と同じように処理します。

引き継ぎに関するルール：

• そのタスクについてリゾルバーが返した、不透明な handoff 文字列をそのまま渡してください。再構築してはいけません。
• 別のタスクに handoff を使い回してはいけません。また、起動開始後に解決を再実行してはいけません。

残りのネイティブサブエージェントをすべて同時に起動してください。各サブエージェントは、実装作業に着手する前に <root>/config/hooks/PRE_TASK_EXECUTION.md を読み、指示を実行してからタスクを実行し、ステータスを更新する必要があります。委任されたワーカーは更新通知を確認しないため、scripts/check-for-updates.cjs を実行してはいけません。

7c. フェーズ完了の検証

フェーズ内のすべてのタスクのステータスが completed であることを確認し、その成果物を収集します。サブエージェントの成功報告を証拠として受け入れてはいけません。フェーズを完了とする前に、<root>/config/shared/verification-gate.md のエビデンスゲートを適用してください。

7d. フェーズ後の実行処理

<root>/config/hooks/POST_PHASE.md を読み、その指示を実行してください。このフックが成功するまで、次のフェーズに進んではいけません。

プランの Execution Blueprint セクションで、フェーズのステータスを completed に更新してください。

すべてのフェーズが完了するまで、次のフェーズについても繰り返してください。

以下の合理化テーブルに対して、<root>/config/shared/anti-rationalization.md を適用してください。

こう考えていることに気づいたら…	拘束力のあるルール
「サブエージェントが成功を報告したのだから、タスクは完了だ」	報告は主張であり、証拠ではありません。フェーズを完了とする前に、検証ゲートを適用してください。
「テストはおそらく通るだろう」	「おそらく」は危険信号です。証明に使えるコマンドを実行し、その出力と終了コードを確認してから、結果を述べてください。
「次のフェーズの後で検証しよう」	POST_PHASE.md が検証済みの証拠に基づいて成功するまでは、フェーズは完了ではありません。今すぐ検証し、未検証のフェーズのまま先へ進んではいけません。

8. 実行後の検証

<root>/config/hooks/POST_EXECUTION.md を読み、その指示を実行してください。検証に失敗した場合は、実行を停止してください。デバッグのため、プランは plans/ に残しておきます。

実行完了を宣言する前に、プランの Success Criteria と Self Validation の手順に対して、<root>/config/shared/verification-gate.md のエビデンスゲートを適用してください。

コードレビューチェックを実行する

POST_EXECUTION.md で問題なしと報告された後、st-code-review スキルに従い、同梱の仕組みを実行します。

code-review.cjs <plan-id> <current-harness>

st-code-review スキルの同階層にある scripts ディレクトリから code-review.cjs を解決し、このスキルを実行している正確な対応ハーネス識別子を渡します。st-code-review スキルがインストールされていない場合は、その結果を実行サマリーに記録し、サマリーの作成とアーカイブに進みます。

標準出力に出力される 1 行の JSON は、次の順序で処理します。

1. 実行サマリーのレビュー結果に、そのまま転記します。書式を変更したり、フィールドを省略したりしないでください。codeReview をターミナルの Code Review エントリーにそのまま転記します。
2. トップレベルの action に従います。halt の場合は停止し、トップレベルの detail を報告して、レビュー結果を含むターミナル Execution Summary を出力します。continue の場合は、実行サマリーの作成とアーカイブに進みます。
3. verdict.kind が review-recorded の場合に限り、<plan-dir>/review/review.xml と <plan-dir>/review/findings.json を読み、対応する指摘を決定します。severity と confidence は参考ラベルであり、指示ではありません。

未認定のレビューを問題なしと報告してはいけません。

厳守事項：

• レビューは 1 回だけ実行します。修正を確認するためにチェックを再実行してはいけません。
• 検出にはレビュアーのルートを使用します。各修正は実装者のルートに振り分け、レビュアーが指摘を修正してはいけません。
• 修正後は、実行完了を宣言する前に POST_EXECUTION.md を最初から最後まで再実行します。それ以前の問題なしという結果は無効になります。

9. 実行サマリーを追記する

計画ドキュメントに実行サマリーのセクションを追記し、<root>/config/templates/EXECUTION_SUMMARY_TEMPLATE.md のすべてのフィールドを埋めます。結果の codeReview フィールドを使用した Code Review エントリーを含めます。結果が生成されなかった場合は、理由を添えて Failed と記載します。Noteworthy Events には、レビューゲートの JSON 行を必ずそのまま記録し、そのうえで、対応した指摘と無視した指摘、およびその理由を記載します。

10. 計画をアーカイブする

完了した計画ディレクトリを <root>/plans/<plan-folder> から <root>/archive/<plan-folder> に移動し、フォルダー構造全体を維持します。移動に失敗した場合はエラーを記録しますが、実行全体を失敗扱いにしてはいけません。

失敗時の処理

• 実行エラー。 タスクが失敗した場合は、<root>/config/hooks/POST_ERROR_DETECTION.md を読み、Noteworthy Events にエラーを記録してフェーズを停止し、続行する前にユーザーの指示を求めます。

実行サマリー

次のブロックで、正確に締めくくります（保持された更新通知がある場合は、その後に別途続けます）。

---
Execution Summary:
- Plan ID: [numeric-id]
- Status: [Archived or Halted]
- Location: [absolute path to current plan directory]
- Code Review: [codeReview from the review result, or Failed with the reason no result was produced]
---

レビューゲートが実行を停止した場合も、このブロックを出力します。実際のステータスと場所を使用し、停止後にアーカイブしたと主張してはいけません。codeReview は、ハーネス、モデル情報、却下理由を省略せずに転記します。指摘に対応しても、レビューを再実行しないため、Address を Pass に変更してはいけません。レビュー前に実行が停止した場合は、Failed と「Review was not run」、および実行を妨げた理由を報告します。

このサマリーは後続の自動化で使用されるため、形式を正確に保ってください。

保持された更新 notice がある場合は、構造化されたサマリーブロックの後、またはこのスキルがサマリーブロックを出力しない場合は最終回答の後に、その一文をそのまま追加します。通知の後には何も続けてはいけません。