st-execute-task

st-execute-task

重要なルール

1. ステータスの整合性を維持する — 実行ライフサイクル全体を通じて、タスクのステータスを更新してください。
2. 実行内容を記録する — すべての結果と、発生した問題を記録してください。

入力

ユーザーは、数値のプラン ID とタスク 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 を推測してはいけません。

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

3. タスクファイルを検証する

<plan-dir>/tasks/<task-id>--*.md を検索し、次にゼロ埋めした <plan-dir>/tasks/0<task-id>--*.md を検索します。どちらも一致しない場合は、<plan-dir>/tasks/ 内のファイルを一覧表示して停止します。一致したファイルを <task-file> として扱います。

4. タスクのステータスを確認する

<task-file> のフロントマターから status を読み取ります。

• completed、in-progress、または needs-clarification の場合は停止し、再開方法を伝えます（完了済みタスクは execute-blueprint から再実行し、未回答の確認質問がある場合は先に回答してください）。
• pending または failed の場合は実行します。
• フィールドがないか、値が認識できない場合は、慎重に進め、曖昧さがあることを記録します。

5. 依存関係を検証する

scripts/check-task-dependencies.cjs <plan-id> <task-id> を実行します。終了コードが 1 の場合は停止し、未解決の依存関係によってタスクを実行できないことを報告します。依存関係が解決されるまで先に進まないでください。

6. エージェントの選定

<root>/config/hooks/PRE_TASK_ASSIGNMENT.md を読み、このタスクに適したエージェントまたはスキルセットを選定するための指示に従います。

7. ステータスを in-progress に更新する

<task-file> の YAML フロントマターを書き換え、status: "in-progress" に設定します。その他のフロントマターのフィールドはすべて正確に維持してください。

8. タスクを実行する

エージェントをデプロイする前にルートを解決します。解決時にタスクの処理は開始されません。

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	外部プロセスがゼロで終了しました。ネイティブエージェントと同様に、ステータスとエビデンスを確認します。ネイティブにはディスパッチしません。
launched-failure	タスクは失敗しました。ステータスを failed に設定し、<root>/config/hooks/POST_ERROR_DETECTION.md を実行します。ネイティブで再試行してはいけません。
infrastructure-failure	直前の行とまったく同じように処理します。

ハンドオフのルール：

• タスクに対してリゾルバーが返した、不透明な handoff 文字列をそのまま渡します。再構成してはいけません。
• 別のタスクでハンドオフを再利用してはいけません。また、起動後に解決を再実行してはいけません。

手順 9～11 は、このスキルで失敗ステータスとエラーフックを処理する手順です。

ネイティブにディスパッチする場合は、内部の Task ツールを使ってエージェントをデプロイします。エージェントは実装作業を始める前に <root>/config/hooks/PRE_TASK_EXECUTION.md を読み、その指示を実行してから、<task-file> 全体を読み、タスクを実装する必要があります。委任されたワーカーは更新通知を確認しないため、scripts/check-for-updates.cjs を実行してはいけません。

9. ステータスを completed または failed に更新する

エージェントの作業完了後、結果に基づいて <task-file> の YAML フロントマターを書き換えます。

• タスクが正常に実装され、すべての受け入れ基準を満たした場合は、status: "completed" に設定します。
• タスクを完了できなかった場合、受け入れ基準を満たさなかった場合、または回復不能なエラーが発生した場合は、status: "failed" に設定します。

その他のフロントマターのフィールドはすべて、正確にそのまま保持します。

10. 注目すべき出来事を記録する

実行中に重要なこと（行った判断、発生した問題、計画からの逸脱、必要なフォローアップなど）があった場合は、<task-file> の末尾に「Noteworthy Events」セクションを追記します。

## Noteworthy Events
- [YYYY-MM-DD] [Event description with sufficient context for the orchestrator]

11. エラー処理

実行中にエラーが発生した場合は、<root>/config/hooks/POST_ERROR_DETECTION.md を読み、その指示を実行します。エラーを Noteworthy Events に記録し、タスクのステータスがまだ failed でなければ、failed に設定します。

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

失敗モード

• 実行エラー。 タスクが失敗した場合は、<root>/config/hooks/POST_ERROR_DETECTION.md を読み、エラーを Noteworthy Events に記録し、タスクのステータスが failed に設定されていることを確認します。