Spec Ops Pipeline（リード・ワーカー）

Spec Ops Pipeline（リード・ワーカー） は何をしますか？

SKILL_DIR = このファイルが置かれているディレクトリ。

役割境界（譲歩不可）

役割	許可される操作	禁止される操作
リード（あなた）	コードの読み取り/検索、テスト/リンター/ビルドの実行、仕様書、レビュー、実行状態の作成（実行ディレクトリ内）、worktree.sh によるワークツリー管理。ユーザーの明示的な承認後、migrate_to_bare.sh --apply を実行。チェックポイント承認後、sop/* ブランチで承認作業をコミット（ステージングモードではステージ間も）、pr.sh open / pr.sh merge を実行（マージは auto_merge_risk に従う）。auto_cleanup に従う（またはユーザーの同意を得て）マージ済みPRのクリーンアップを実行。	メインチェックアウト または ワーカーワークツリー内のアプリケーションファイルを編集、作成、削除、移動すること（唯一の例外：migrate_to_bare.sh --apply と worktree.sh sync のfast-forward）。手動でのマージ競合解決。APPROVEされなかったタスクのマージ。--admin の使用。ブランチ保護の回避。
ワーカー（サブエージェント）	DoDに合格するまで、ワークツリー内のホワイトリストに登録されたファイルを編集。	ホワイトリスト外のファイルへのアクセス、コミット/プッシュ、ワークツリー外での作業。

「直してしまおう」と思ったら？仕様を書きましょう。

モデル割り当て

プリフライト runtime が役割ごとのモデル（lead = フェーズ1、lead_phase2、worker、worker_light、scout）を提供します。レビュアーは lead モデルで実行されます。役割、デフォルト、オーバーライド、階層については models.md を参照。現在のフェーズのリードモデルでない場合は、ユーザーに切り替え方法を伝えてください（Claude Code では /model、/effort）。single 実行の場合はそのまま続行し、フェーズ1のリードモデルを維持します。

セッションとコンテキスト

• フェーズ1: ステップ0～2をフェーズ1のリードモデルで実行。
• フェーズ2: ステップ3～6を実行。split の場合：新しいセッションでフェーズ2のリードモデルを使用し、Resume から開始。計画、状態、現在のステージの仕様のみを読み込みます（自己完結型）。single の場合：同じセッションで続行。

session_split（環境変数 SOP_SESSION_SPLIT）：auto（デフォルト）= Hリスクタスク、3つ以上のタスク、または staged モードの場合は split、それ以外は single。always → split。never → single。

チェックポイントで表示されます。ユーザーが上書き可能です。

実行状態は 実行ディレクトリ（run.run_dir、<git common dir>/sop-run/）に保存されます。すべてのワークツリーの外部にあり、全ワークツリーで共有され、セッションをまたいで保持されます。セッションのスクラッチパッドは絶対に使用しないでください。

コマンド出力 — すべてのリンター/テスト/ビルド/DoDコマンドは、bash SKILL_DIR/scripts/run_logged.sh <run dir>/logs/<slug>-<step>-<n>.log '<command>' を介して実行してください（exit=<rc> lines=<n> log=<path> と、失敗時の最後の40行を出力）。テールだけでは失敗の原因が説明できない場合にのみ、ログのさらに先を読んでください。テスト出力全体をチャットに含めないでください。

ワークフロー

0. プリフライト

bash SKILL_DIR/scripts/preflight.sh --agent <claude|gemini|codex> --fetch（自身のランタイム用。--fetch は事前にリモートの default_base を更新）1行のJSONを出力します：runtime（worker、session_split に注意）、config（source_worktree、default_base、provision、max_parallel、auto_merge_risk、merge_method、auto_cleanup に注意。レイアウトを参照）、leftovers、run、pr、baseline、base_check、docker_pool。ベアレイアウトの場合、リードのgit/テストコマンドは source_worktree 内で実行します。以下のアクションを実行します。

1. run.has_state: true（実行中）：ユーザーに、再開するか、クリーンアップするか（すべてのタスクがユーザー待ちのPRを持っている場合）、アーカイブして（worktree.sh rundir --archive）最初からやり直すかを尋ねます。
2. leftovers（以前の実行のタスク）：それらについて言及します。
3. config.offer_bare_migration: true：bash SKILL_DIR/scripts/migrate_to_bare.sh（ドライラン）を実行し、ユーザーに ベアリポジトリワークツリーレイアウト への変換を提案します（bare-layout.md に従ってフォーマット）。明示的な yes の場合のみ： migrate_to_bare.sh --apply を実行、preflight.sh を再実行、新しい source_worktree からエージェントドキュメントを再読み込みします。拒否された場合 → 標準レイアウト。
4. pr.ok: false：実行はローカルでのみコミットします。チェックポイントでそのように表示されます。pr.into に注意してください。マージルール：execution-plan.md を参照。
5. base_check.match: false、fetch_error、または error：最初にユーザーとベースについて合意します。
6. docker_pool.error：容量が不明であることをユーザーに伝えます。docker: false の場合 → スキップ。free < config.max_parallel の場合 → 警告（ステップ3で再チェック）。
7. baseline = git status --porcelain=v1 && git diff HEAD | sha256sum の出力。source_worktree ですでに実行済み。state.json のために保持します。

1. 監査（読み取り専用）

• スコープをユーザーと確立します（パス、セキュリティ/パフォーマンス/負債/仕様のギャップ）。
• 静的スキャンを実行します。大規模なスコープの場合は、まず並列の読み取り専用スカウト（scout.md）でスイープし、そのリードを検証します。プロジェクトの既存のリンター/テスト/型チェックコマンドを run_logged.sh（ログは audit-<n>.log）を介して実行し、グランドトゥルースを取得します。ツールをインストールしたり、設定を変更したりしないでください。
• ギャップレポート を作成します：file:line、深刻度、証拠、修正案を含む番号付きの所見。それらをワーカーサイズのタスクにグループ化し、重複しない小さなホワイトリストを作成します。
• 複数のタスクがある場合、実行計画 を execution-plan.md に従って作成します。依存関係なし → independent（すべて並列）。関連あり → staged（依存順のステージ、ステージ内は並列、各ステージは前のステージの統合結果に基づいて構築）。

2. 仕様（チェックポイント）

• 各タスクについて worker-spec-template.md に記入し、そのワーカー階層を選択します（models.md 参照）。リポジトルール をエージェントドキュメント（AGENTS.md、CLAUDE.md、およびホワイトリストが触れるディレクトリ内のもの）から記入します。テスト/リンターコマンド、フラグ、言語ルール。あなたの記憶と worker_notes からリポジトリの落とし穴を追加します。ワーカーはあなたのコンテキストを見ることができません。DoDコマンドは、それらのルールで要求されるように記述します。
• 実行ディレクトリ（ワークツリーではなく）に保存します：gap-report.md、plan.md、spec-<slug>.md、<slug>.wl。
• ステージごとの重複チェック：bash SKILL_DIR/scripts/check_scope.sh --overlap <source_worktree> <slug>.wl...。OVERLAP → 再分割または再ステージング。各 POSSIBLE を手動で確認。
• DoDドライラン：independent またはステージ1のタスクの各DoDコマンドを source_worktree で run_logged.sh を介して実行します（ログは <slug>-dry-<n>.log）。仕様書にそのクラスを記録し、BROKEN なものを修正します（詳細）。ステージ2以降はステップ3で実施。
• 計画批評：2つ以上のタスクがある場合、staged モード、Hリスクタスク、または要求があった場合：読み取り専用の批評家（タスクがHリスクの場合は lead モデルのみ、それ以外は lead_phase2）。plan-critic.md に従って、各所見について判断します。1ラウンド。
• チェックポイントレポートを表示し、承認を待つ（ステップ3の前）。形式は execution-plan.md §3 の通り。承認では明示的に以下をカバーする必要があります：staged モードでのステージ間のローカルコミットとマージ。常に、APPROVE後の自動コミット、プッシュ、PR、およびマージ（Merge列による）。auto_cleanup がある場合の各マージ後のクリーンアップ。Dockerプール行に prune: ask とある場合の worktree.sh pool --prune。§3に文言あり。
• フェーズ境界：承認後、<run dir>/state.json（§7）に phase: 2 と合意された session を書き込み、その後：

  • split の場合：ユーザーに伝えます：

    計画は <run dir> に保存され、承認されました。/clear を実行し、フェーズ2のリード（/model <lead_phase2.model>、/effort <lead_phase2.effort>）に切り替えてから、このスキルを resume で呼び出してください。

    （Codex / Antigravity：lead_phase2 で新しいセッションを開始します。）

  • single の場合：計画が <run dir> に保存され、実行がここで続行されることをユーザーに伝えます。モデルを切り替えずにステップ3に進みます（resume は引き続き機能します）。

Resume（フェーズ2）

resume の場合：entrypoints.md を参照。

クリーンアップ（ユーザーがマージした後）

cleanup の場合：entrypoints.md を参照。

ステップ3～5は ステージごとに1回 実行されます（independent = 単一ステージ）。計画の順序で実行します。state.json を最新に保ちます。タスクのステータスを、派遣時、各レビューラウンド、承認または延期時、および統合時に更新します。

3. ワークツリー + 派遣

1. ステージのワークツリーを作成する前に：bash SKILL_DIR/scripts/worktree.sh pool を実行します。docker: false → スキップ。error → ユーザーに伝え、最初に尋ねます。free < ステージのタスク数の場合、承認でカバーされている場合のみ worktree.sh pool --prune を実行します（すべてのプロジェクトの未使用のComposeネットワークを削除します。それらは再作成されます）。それ以外の場合はユーザーに確認します。
2. 各タスクについて：bash SKILL_DIR/scripts/worktree.sh create <slug> [--base <ref>]（ステージ1：--base を省略。ステージ2以降：--base sop-stage/<n-1>。worktree.sh path <slug> でプレビュー可能）。出力で provisioned を確認します。期待されるエントリがない場合は停止します。ステージ2以降：派遣前に、各タスクのDoDをその新しいワークツリーで run_logged.sh を介してドライランします（パス/フラグの修正のみ。それ以外の場合は確認）。
3. ワークツリーのパスとベースを各仕様書に挿入し、ステージ内のすべてのワーカーを並列で派遣します（dispatch.md に従う）。各ワーカーはその worker_tier（worker / worker_light）のモデル上で実行されます。max_parallel で上限を設定します。

4. ゲート（タスクごと）

1. bash SKILL_DIR/scripts/check_scope.sh <worktree> <whitelist-file> が終了コード0で終了する必要があります。違反がある場合、ワーカーはそれらを元に戻します（レビューラウンドとしてカウント）。
2. すべてのDoDコマンドを自分でワークツリー内で run_logged.sh を介して再実行します（ログは <slug>-gate-r<round>-<n>.log）。すべてが終了コード0で終了する必要があります。

5. レビュー（タスクごと）+ ステージバリア

review-checklist.md に従います。差分は lead モデルでレビューされます（split：読み取り専用のレビュアーサブエージェント。あなたがその所見を検証。single：あなた）。記録されたベースと比較します。番号付きの file:line 所見とともに APPROVE または REQUEST_CHANGES を発行します。ワーカーと最大 3ラウンド ループし、その後ユーザーにエスカレーションします。タスクは独立してループします。light タスクがラウンド1で失敗した場合、worker モデルで再派遣されます（models.md）。

• independent：APPROVE後、コミット、プッシュ、pr.sh でPRを開き、自動マージルール で許可されている場合にマージします。質問はありません（§4a）。
• staged：ステージ内のすべてのタスクがAPPROVEDになったら、それぞれをローカルでコミットし、worktree.sh integrate <n> --base <stage base> sop/<slug>... を実行し、統合ゲート（次のステージの前に、ステージワークツリー内のすべてのDoD）を通過します。競合、統合の失敗、エスカレーション：execution-plan.md を参照。さらにステージが残っている場合、state.json の current_stage を次のステージに設定し、同じセッションで続行します。コンテキストが大きくなった場合のみ（2ステージ実行後、または多くのレビューラウンド後）、新しいセッション（/clear 後、resume）を提案します。ここでは安全です。

6. クローズアウト

1. ステップ0のベースラインコマンドを再実行します。一致する必要があります。一致しない場合は、メインチェックアウトで正確に何が変更されたかを報告します。自分で「修正」しないでください。
2. PR：independent のPRはすでに存在します（§5）。それぞれを merged、open（理由）、またはローカルのみとしてリストします。staged：最後の sop-stage/<n> から pr.sh を使用して単一のPRを開きます（auto_merge_risk に従ってマージ、§6）。
3. マージされたPRのワークツリーとブランチの クリーンアップ、worktree.sh sync、そしてすべてのタスクがクリーンアップされたら worktree.sh rundir --archive を実行します。承認に auto_cleanup がある場合のみ質問なし。それ以外の場合は最初に確認します。--force は絶対に使用しないでください。
4. 最終サマリー：対処された所見、延期されたもの（およびブロックされた依存関係）、ブランチ/PRとその状態、クリーンアップされたものと残っているもの。PRがユーザー待ちの場合は、次のように締めくくります：マージ後、cleanup でこのスキルを呼び出してください。

スクリプトとレイアウト

使用法、終了コード、ワークツリーパス、プロビジョニング、設定オーバーライド：scripts-and-layout.md を参照。