st-full-workflow

st-full-workflow

重要なルール

ユーザーからの入力を待たずに、3つのステップを順番にすべて実行してください。

入力

ユーザーは作業指示を会話形式で提示します。

運用手順

ステップ 1：計画の作成

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

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

出力されたパスを、以降のすべてのステップで <root> として扱います。

委任された実行ワーカーはこのステップを省略し、更新通知を出力しません。

このスキルのスクリプトパスを使って、scripts/check-for-updates.cjs "<root>" を別コマンドとして実行します。ユーザーの作業ディレクトリを維持します。標準出力に出力される1行の JSON を読み取ります。notice がある場合は、その正確なテキストをユーザー向けの最終応答用に保持します。許可を求めるために一時停止したり、更新を実行したりしないでください。

2. プロジェクトのコンテキストを読み込む

このプロジェクトのディレクトリ規則を確認するため、<root>/config/STRIKETHROO.md を読みます。 続行する前に、<root>/config/hooks/PRE_PLAN.md を読み、その指示を実行します。 <root>/config/templates/PLAN_TEMPLATE.md を読み、計画をそのテンプレートに準拠させます。

また、<root>/config/shared/anti-rationalization.md も読みます。

3. 作業指示を分析する

次の項目を特定します。

• 目的。
• 範囲と明示的な境界。
• 成功基準。
• 依存関係、前提条件、ブロッカー。
• 技術要件と制約。

4. 確認のやり取り

重要なコンテキストが不足している場合は、ユーザーに具体的な質問をします。質問がなくなるまでやり取りを続けます。後方互換性が必要かどうかを明確に確認します。回答を作り上げたり、不足している回答を取り繕ったりしないでください。

ユーザーがブロッキングとなる質問への回答を拒否した場合は、停止し、計画には確認が必要であると報告します。部分的な計画は作成しないでください。

<root>/config/shared/anti-rationalization.md の内容を、次の合理化防止テーブルに適用します。

こんな考えが浮かんだら…	拘束力のあるルール
「答えを妥当に推測できる。」	推測は回答ではありません。質問してください。回答を作り上げてはいけません。
「もう一度聞くのは煩わしい。」	ユーザーが断れる質問は、やり直しが可能です。一方、間違った前提を黙って置くことはできません。質問してください。
「ユーザーがほのめかしているから、確定事項だ。」	ほのめかしは確認ではありません。質問として明示し、明確な回答を得てください。

5. 次の計画 ID を割り当てる

次に利用可能な計画 ID を取得するため、scripts/get-next-plan-id.cjs を実行します。ディレクトリ名に使うゼロ埋め形式（{padded-id}--{slug}）を計算し、計画のフロントマターにはゼロ埋めしていない整数を使用します。

6. 計画を出力する

計画を <root>/plans/{padded-id}--{slug}/plan-{padded-id}--{slug}.md に書き込みます。フロントマターとセクションの両方を <root>/config/templates/PLAN_TEMPLATE.md に準拠させます。時間の見積もり、タスクリスト、コードサンプルは含めないでください。これらはタスク生成のステップで扱います。

計画の概要から <slug> を導きます。小文字の英数字とハイフンのみを使用し、連続するハイフンを1つにまとめ、先頭と末尾のハイフンを取り除きます。

7. 計画後フックを実行する

<root>/config/hooks/POST_PLAN.md を実行します。

8. ステップ 1 の構造化サマリーを出力する

ステップ 1 は、次のブロックちょうどで締めくくります（保持した更新通知がある場合は、ワークフローの最終サマリーの後に続けます）。

---

Plan Summary:
- Plan ID: [numeric-id]
- Plan File: [absolute-path-to-plan-file]

この出力から Plan ID の値を解析し、ステップ 2 に渡します。

ステップ 2：タスクの生成

ステップ 1 の計画 ID を使用します。

1. 計画を解決する

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

スクリプトがゼロ以外の終了コードを返した場合は、標準エラー出力をユーザーに提示し、ワークフローを停止します。 別の ID を推測してはいけません。

2. プロジェクトのコンテキストを読み込む

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

• <root>/config/STRIKETHROO.md — プロジェクトとディレクトリの規約。
• 手順 1 で返されたパスにある計画本文 — 存在すべきタスクの仕様。
• <root>/config/templates/TASK_TEMPLATE.md — すべてのタスクファイルが準拠するスキーマ。
• <root>/config/shared/anti-rationalization.md — 手順 3 で適用します。

3. 計画を分析して分解する

計画全体を読みます。明示的に記載されたすべての具体的な成果物を特定します。 本当に必要な場合に限り、各成果物をアトミックなタスクに分解します。

タスクの最小化（必須）：

• 必要最小限のタスクのみを作成します。網羅的なリストから 20～30% 削減することを目標に、候補ごとに必要性を問い直します。
• すべてのタスクは明示された要件に対応させます。あると望ましいだけのもの、「ベストプラクティス」、または計画に記載のない将来の拡張性をタスクにしてはいけません。
• 各タスクには、重複しない固有の目的を持たせます。
• エラー処理は、その動作を担うタスクに含めます。

次の合理化テーブルに、<root>/config/shared/anti-rationalization.md の内容を適用します。

こんな考えが浮かんだら…	拘束力のあるルール
「タスクをもう 1 つ増やしても問題ない。」	20～30% の最小化目標に違反します。すべてのタスクは明示的に記載された成果物に対応していなければなりません。そうでなければタスクとして作成しません。
「このエッジケースは独立したタスクに値する。」	その動作を担うタスクに含めます。ごく小さな操作を個別の単位に分割してはいけません。
「念のためテストスイートを追加しよう。」	些細な機能を網羅的にテストするのは過剰な作り込みです。テスト方針に従い、意味のあるテストのみを作成します。
「将来の拡張性を考えれば、このタスクは妥当だ。」	YAGNI です。計画に記載されていないものはタスクではありません。

4. 粒度とスキルのルールを適用する

各タスクは次の条件を満たす必要があります。

• 単一目的 — 明確な成果物を 1 つ持つこと。
• アトミック — それ以上意味のある分割ができないこと。
• スキル特化 — 1～2 個の技術スキルを持つエージェントが実行できること。
• 検証可能 — 少なくとも 1 つの具体的で実行可能な検証手順（コマンドと期待される出力、または別の観測可能なシグナル）を含む、明確な受け入れ基準があること。「正しく動作する」といった曖昧な表現で済ませてはいけません。

タスクの技術要件から、スキルをケバブケースで推定します。単一ドメインのタスクには 1 つのスキル、["api-endpoints", "database"] のような相補的なドメインを扱うタスクには 2 つのスキルを指定します。3 つ以上必要な場合は、タスクをさらに分割します。

5. テスト方針：「テストは少数にとどめ、主に統合テストを行う」

次のものにはテストを作成します。

• 独自のビジネスロジックとアルゴリズム。
• 重要なユーザーワークフローとデータ変換。
• コア機能におけるエッジケースとエラー条件。
• コンポーネント間の統合ポイント。
• 複雑な検証ロジックや計算ロジック。

次のものにはテストを作成しません。

• サードパーティのライブラリやフレームワークの機能。
• 独自のロジックを伴わない単純な CRUD。
• 些細なゲッター／セッターや静的設定。
• 誤っていればすぐに問題が明らかになる自明な機能。

関連するテストシナリオは 1 つのタスクにまとめます（「ユーザー認証フローをテストする」とし、ログイン、ログアウト、検証に分けません）。メソッド単位のユニットテストより、統合テストとクリティカルパスのカバレッジを優先します。CRUD 操作ごとにテストタスクを作成してはいけません。

生成するすべてのテストタスクの「Implementation Notes」に、これらのルールを記載します。

6. 依存関係を分析する

タスク B がタスク A の出力または成果物を必要とする場合、A が作成したコードを変更する場合、または A が実装した機能をテストする場合、B は A に依存します。B が A の完了前に開始できない場合はハード依存関係として記録し、A の完了後のほうが単に作業しやすいだけの場合はソフト依存関係として記録します。最終的な依存関係グラフが非循環であることを検証します。

7. 複雑さの分析

候補となる各タスクについて、ファイルを書き込む前に complexity_score（整数の1～10）を割り当てます。スコアを付ける前に references/complexity-rubric.md を読みます。これは、各スコア帯で評価される4つの観点を定めています。そのうえで、次のルールを適用します。

• スコアが8以上 → さらに分解し、そのまま出力しないでください。
• スコアが6～7 → 具体化するか分割し、明確な理由がない限り出力しないでください。
• 受け入れ条件が曖昧 → 実行可能な具体的な検証手順に具体化します。
• 隣接するタスクが些細な内容 → 統合します。

差し戻しルール： 分割、具体化、統合を適用した後、依存関係の分析を再実行し、調整後のタスクを再評価します。この手順は最大3回まで繰り返します。3回実施しても複雑さが解決しない場合は、作業を停止し、障害となっている事項をユーザーに伝えます。

8. タスク ID の割り当て

最初の利用可能なタスク ID を取得するために、scripts/get-next-task-id.cjs <plan-id> を1回実行し、その後はプロセス内で番号を増やして残りの ID を割り当てます。タスクの frontmatter の id フィールドにはゼロ埋めしない整数を使い、ファイル名にはゼロ埋めした形式を使います。slug は短いタスクタイトルから作成します。小文字の英数字とハイフンのみを使い、連続するハイフンは1つにまとめ、先頭と末尾のハイフンは削除します。

9. タスクファイルの出力

各タスクは次の場所に書き込みます。

<root>/plans/<plan-dir-name>/tasks/{padded-id}--{slug}.md

各ファイルは <root>/config/templates/TASK_TEMPLATE.md に準拠する必要があります。complexity_notes は、スコアに正当化の説明が必要な場合にのみ追加します。execution_profile は決して書き込まないでください。これはルーティングヘルパーが書き込みます。

本文のすべてのセクションに、タスク固有の内容を記入します。詳細な実装ガイダンスは、「Implementation Notes」の下にある <details> ブロック内に、推論機能のない LLM でもそのセクションだけをもとにタスクを実行できるように記述します。

10. 検証チェックリスト

タスク生成の完了を宣言する前に、次の項目を確認します。

• 計画で明示的に示されたすべての成果物が、いずれかのタスクで網羅されていること。
• 目的が重複するタスクがないこと。
• 依存関係が非巡回グラフを形成し、孤立した参照や循環参照がないこと。
• グループが計画全体で一貫していること。
• タスクファイルを書き込んだ後、scripts/validate-plan-blueprint.cjs <plan-id> complexityScoresValid を実行します。yes と表示されない限り停止します。no と表示された場合は、scripts/validate-plan-blueprint.cjs <plan-id> invalidComplexityTasks を実行して、欠落しているファイル、整数でない値、または範囲外の値を確認し、修正してから再実行します。

11. タスク実行のルーティング

<root>/config/hooks/TASK_EXECUTION_ROUTING.md を読み、この手順に従います。

1. scripts/route-task-execution.cjs profiles <plan-id> を実行します。no-config または disabled の場合、ルーティングはオフです。以降のルーティング手順をスキップして続行します。invalid-config の場合は停止し、エラーをユーザーに伝えます。ブループリントを生成してはいけません。
2. 計画の tasks/ ディレクトリにある各タスクに、設定済みのプロファイル名を1つだけ割り当てます。この実行で生成したタスクは、すでにコンテキストにある内容をもとに分類します。計画に以前の生成実行で作成されたタスクファイルが含まれている場合は、それらのファイルを読んで分類します。
3. タスク ID とプロファイルの対応関係をすべて含む JSON オブジェクトを、一時ファイルに書き込みます。例：{"1": "routine", "2": "demanding"}。
4. scripts/route-task-execution.cjs apply <plan-id> <mapping-file> を実行します。ターゲットの選択はタスクのディスパッチ時に行われ、生成時には行われません。
5. routed の場合、一時的な対応ファイルを削除して続行します。失敗結果（invalid-assignments、invalid-tasks、routing-failure、infrastructure-failure）の場合は停止し、JSON エラーをユーザーに伝えます。一部のタスクしかルーティングされていない状態で、ブループリントの生成を続けてはいけません。

具体的な実行ターゲットをタスクの frontmatter や本文に手書きで記載してはいけません。

12. POST_TASK_GENERATION_ALL フックの実行

<root>/config/hooks/POST_TASK_GENERATION_ALL.md を読み、Execution Blueprint の構造には <root>/config/templates/BLUEPRINT_TEMPLATE.md を使って、その指示に従います。ルーティングが成功した後、またはルーティングがオフと報告された後にのみフックを実行します。

ステップ3：ブループリントの実行

ステップ1で取得した計画 ID を使用します。

1. 計画を解決する

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

スクリプトが 0 以外のコードで終了した場合は、標準エラー出力をユーザーに提示し、ワークフローを停止します。 別の ID を推測してはいけません。

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

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

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

3. タスクやブループリントがない場合、自動生成する

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

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

• この計画 ID に対して、ステップ 2 のタスク生成手順をすべて実行します。
• planFile、planDir、taskCount、blueprintExists の問い合わせを再実行し、解決済みのパスと件数を更新します。

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

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

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

続けて scripts/capture-base-commit.cjs <plan-id> を 1 回実行し、レビューステージで差分を確認する対象のコミットを記録します。skipped の結果であれば実行を続行します。この場合、レビューステージはスキップされます。停止するのは error の結果が返された場合のみです。

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

以下のファイルを、記載順に読み込みます。

• <root>/config/STRIKETHROO.md
• ステップ 1 で得たパスにある計画ドキュメント。フェーズのグループ分けとタスクの割り当て順序を定義する「Execution Blueprint」セクションも含みます。
• <root>/config/shared/verification-gate.md と <root>/config/shared/anti-rationalization.md。どちらも、以下のフェーズループで適用します。

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

内部のタスクまたは ToDo トラッカーを使って進捗を管理します。「Execution Blueprint」で定義された各フェーズについて、次の手順を実行します。

6a. フェーズ実行前の準備

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

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

6b. タスクの割り当て

依存関係がすべて満たされている、このフェーズでスケジュールされたすべてのタスクを特定します。タスクを割り当てるエージェントを選択する前に、<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 は実行しないでください。委任された作業者は更新通知を受け取りません。

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

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

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

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

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

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

この合理化表に対して、<root>/config/shared/anti-rationalization.md を適用してください。

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

7. 実行後の検証

<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 スキルがインストールされていない場合は、その結果を実行サマリーに記録し、サマリーの作成とアーカイブに進みます。

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

1. 実行サマリーのレビュー結果に、その JSON をそのままコピーします。書式を変更したり、フィールドを省略したりしないでください。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 は参考ラベルであり、指示ではありません。

認定されていないレビューをクリーンと報告してはいけません。

ハードルール：

• レビューは一度だけ実行します。修正を確認するためにゲートを再実行してはいけません。
• 検出にはレビュアーの経路を使います。修正はそれぞれ実装者の経路で割り当て、レビュアーに指摘の修正をさせてはいけません。
• 修正後は、実行完了を宣言する前に POST_EXECUTION.md を最初から最後まで再実行します。それ以前のグリーン結果は、以後適用されません。

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

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

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

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

失敗モード

• ステップ 1 で割り当てられた ID の計画ディレクトリがすでに存在する。 next-plan-id スクリプトを再実行し、一度だけ再試行します。競合が解消しない場合は停止して報告します。
• 実行エラー。 タスクに失敗した場合は、<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 がある場合は、構造化サマリーブロックの後、またはこのスキルがサマリーブロックを出力しない場合は最終回答の後に、その文を正確に追記します。通知の後には何も記載してはいけません。