オートパイロット

計画・レビュー・実装・検証・PR作成のライフサイクル全体をオーケストレーションし、マルチベンダーレビューの収束を実現します。シンプルな機能については、提案からPRまで完全に自動実行されます。マージは人間による承認のため停止します。

引数

<change-id or description> — 既存のOpenSpec change-idか、引用符で囲まれた機能の説明。

オプションフラグ:

--force — 複雑性ゲートの閾値をバイパス
--val-review — シンプルな機能でもVAL_REVIEWフェーズを強制実行
--no-review — マルチベンダーレビューフェーズ（PLAN_REVIEW、IMPL_REVIEW）をスキップ。反復フェーズは実行

前提条件

OpenSpec CLIがインストール済み（v1.0以上）
マルチベンダー収束のため最低2つのベンダーCLI利用可能（claude、codex、gemini）
コーディネーターの利用を推奨（なければ線形ワークフローに低下）

コーディネーター機能チェック

スキル開始時に、コーディネーター検出スクリプトを実行します：

python3 "<skill-base-dir>/../coordination-bridge/scripts/check_coordinator.py" --json

コーディネーターが利用不可の場合、警告を発行し、順序実行スキル呼び出しにフォールバック：

/plan-feature（説明が提供された場合）
/iterate-on-plan（常時実行 — セルフレビュー）
/parallel-review-plan（CLIのみ — 単一パス、収束ループなし）
/implement-feature
/iterate-on-implementation（常時実行 — セルフレビュー）
/parallel-review-implementation（CLIのみ — 単一パス、収束ループなし）
/validate-feature
PRを手動作成

ステップ

0. 引数の解析とレジューム確認

引数を解析して以下を判定：

openspec/changes/内の既存change-idにマッチするか確認 → その変更を読み込む
それ以外 → PLANフェーズの機能説明として扱う

既存ループ状態を確認：

LOOP_STATE="openspec/changes/<change-id>/loop-state.json"
if [ -f "$LOOP_STATE" ]; then
    # 保存された状態からレジューム — 現在のフェーズを報告し継続を提案
fi

loop-state.jsonが存在しcurrent_phase == "ESCALATE"の場合：

エスカレーション理由とブロッキング検出結果を報告
問題が解決したか確認
yes: previous_phaseのゲートチェックを再評価

1. INITフェーズ

CLIモード検出 — マルチベンダーレビュー利用可能か確認：

# CLIモード: ベンダーCLIがマルチベンダーレビューディスパッチに利用可能
CLI_REVIEW_ENABLED=true
if [[ "$ARGUMENTS" == *"--no-review"* ]]; then
  CLI_REVIEW_ENABLED=false
fi
# ベンダーCLIがインストールされていない場合も無効化（非対話的/クラウド環境）
python3 "<skill-base-dir>/../parallel-infrastructure/scripts/review_dispatcher.py" --check-vendors
if [[ $? -ne 0 ]]; then
  CLI_REVIEW_ENABLED=false
  echo "[autopilot] No vendor CLIs detected — multi-vendor review disabled"
fi

cli_review_enabledをrun_loop()に渡します。Falseの場合、PLAN_ITERATEとIMPL_ITERATEは実行される（セルフレビューは常に有益）が、PLAN_REVIEWとIMPL_REVIEWはスキップ。

複雑性ゲートを実行：

from complexity_gate import assess_complexity
result = assess_complexity(work_packages_path, proposal_path, force=<--force flag>)

result.allowed == Falseの場合：警告を報告して停止（--forceを提案）
result.val_review_enabledの場合：ループ状態に記録
result.warningsの場合：報告するが継続
result.checkpointsの場合：注入されたチェックポイントをログ

INITフェーズアーキタイプを記録（状態のみリゾルバー — D9）。loop-state.jsonが書き込まれた後、シェルアウトしてphase_archetypeをINITに記録し、可観測性が7つのディスパッチフェーズだけでなく13のすべての非終端フェーズをカバーするようにします：

python3 "<skill-base-dir>/scripts/runner.py" record-state-only-archetype \
  --change-id <change-id> --phase INIT

ここでの失敗は致命的ではありません — ヘルパーは警告をログし、コーディネーターに到達不可能な場合phase_archetype = nullを書き込みます。

2. PLANフェーズ

PLANフェーズアーキタイプを記録（状態のみリゾルバー — D9 / VAL_REVIEW G-V-001）。PLANはハーネスAgent(...)ツールではなく/plan-featureスラッシュコマンドでディスパッチされるため、runner.py build-dispatchを通過しません。すべての13の非終端フェーズで可観測性を統一するため、シェルアウト：

python3 "<skill-base-dir>/scripts/runner.py" record-state-only-archetype \
  --change-id <change-id> --phase PLAN

ここでの失敗は致命的ではありません — ヘルパーは警告をログし、コーディネーターに到達不可能な場合phase_archetype = nullを書き込みます。

引数が説明であった場合（既存change-idなし）：

/plan-feature <description>を呼び出し（ティアはコーディネーター利用可能性に基づき自動検出）
提案承認を待ってから続行

引数が既存change-idであった場合：

提案アーティファクトが存在することを確認（proposal.md、design.md、specs/、tasks.md）
PLAN_REVIEWにスキップ

フェーズ別サブエージェントディスパッチプロトコル

次の7つのフェーズ（PLAN_ITERATE、PLAN_REVIEW、IMPLEMENT、IMPL_ITERATE、IMPL_REVIEW、VALIDATE、VAL_REVIEW）はハーネスAgent(...)ツール経由でサブエージェントにディスパッチされます。各ブロックは同じ3段階プロトコルに従います：

runner.py build-dispatchにシェルアウトしてディスパッチkwargsを構築。ランナーはコーディネーターに解決されたアーキタイプを照会し、フェーズごとのプロンプトスキャフォルドを構築し、system_promptをリテラルセパレーター\n\n---\n\nでpromptに折り畳み、実行ごとの解決キャッシュを書き込みます。JSON出力：{prompt, model, system_prompt, isolation, archetype}。
JSON値でハーネスAgent(...)ツールを呼び出す。promptを不透明として扱う — 連結しない、先頭に追加しない、セパレーターで分割しない。 SKILL.mdは決して折り畳まない；折り畳みはbuild_phase_dispatch_kwargs内に存在（単一の真実の源）。
サブエージェントから返される(outcome, handoff_id)を渡してrunner.py apply-outcomeにシェルアウトして結果を適用。これはloop-state.jsonを更新（last_handoff_id、handoff_ids、phase_archetype）し、キャッシュファイルを消費。

フォールバック（D5）：runner.py build-dispatchがarchetype: nullを返す場合（コーディネーター到達不可またはフォールバック）、あるいはハーネスAgent(...)ツールが現在のオーケストレーターセッションで公開されていない場合、ディスパッチブロックはインラインプロース経路（スラッシュコマンド呼び出し）にフォールスルーし、apply-outcomeはphase_archetype = nullを記録。

ディスパッチ呼び出しはオートパイロットスキルディレクトリ相対のパスを使用。<skill-base-dir>をオートパイロットスキルの実際の場所に置き換えます（通常.claude/skills/autopilot/または.agents/skills/autopilot/）。

2.5. PLAN_ITERATEフェーズ（常時実行）

計画アーティファクトのセルフレビューと改善。このフェーズはCLIモード問わず常に実行。

目標：完全性、明確性、実行可能性、スコープ、整合性、テスト可能性、並列化可能性、前提条件の各軸で提案を改善。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase PLAN_ITERATE --change-id <change-id>

JSON出力を解析。prompt、model、isolationをキャプチャ。

これらの値でハーネスAgent(...)ツールを呼び出し、promptを不透明として扱う（連結なし）：
```
result = Agent(prompt=<dispatch.prompt>, model=<dispatch.model>,
               isolation=<dispatch.isolation>)
```
phase_agent._validate_resultのプロトコルに従い、エージェントの最後のメッセージから(outcome, handoff_id)を解析。結果は改善が落ち着いたときは"complete"、それ以外は"failed"。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase PLAN_ITERATE \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：ステップ1がarchetype: nullを返したか、Agent(...)が利用不可の場合、インライン経路を実行：/iterate-on-plan <change-id>を直接呼び出し。スラッシュコマンドが返ってきたら、apply-outcomeを実行してこのフェーズでphase_archetype = nullが記録されるようにします。

完了時：PLAN_REVIEW（CLIモード）またはIMPLEMENT（非CLIモード）に遷移。 失敗時：ESCALATEに遷移。

3. PLAN_REVIEWフェーズ（収束ループ — CLIのみ）

cli_review_enabled=falseの場合はスキップ — IMPLEMENTに直接遷移。

マルチベンダー計画レビューと収束 — ブロッキング検出がない場合の結果は"converged"、ある場合は"not_converged"、max_phase_iterationsに達したら"max_iter"。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase PLAN_REVIEW --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase PLAN_REVIEW \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — 収束ループを直接呼び出し：

from convergence_loop import converge
result = converge(
    change_id=change_id,
    review_type="plan",
    artifacts_dir=change_dir,
    worktree_path=worktree_path,
    agents_yaml_path=agents_yaml_path,
    max_rounds=3,
    min_quorum=2,
    fix_mode="inline",
    fix_callback=apply_plan_fixes_inline,
    memory_callback=write_memory,
)

その後apply-outcomeを実行してphase_archetype = nullを記録。

収束時：検出結果の概要を報告し、IMPLEMENTに遷移。 未収束時：理由を報告（max_rounds、stalled、quorum_lost、disagreement）し、ESCALATEに遷移。

インライン計画修正（PLAN_FIX、サブエージェントディスパッチではない）：ブロッキング検出結果を読み込み、関連計画ファイル（proposal.md、design.md、specs、work-packages.yaml）を直接編集し、openspec validateで再検証。PLAN_FIXは前のPLAN_REVIEWからphase_archetypeを継承 — convergence_loopはこのフィールドを上書きしません。

収束耐久性契約

converge()はコンセンサス合成器を呼び出す前に、ベンダーごとの検出結果とマニフェストを<artifacts_dir>/.review-cache/round-N/に書き込みます。合成がraise（例：consensus_synthesizer.py:59のline_rangeパーサーバグ）の場合、元の例外は呼び出し元に伝播し、永続化された検出結果は事後分析のためディスク上に残ります。これは耐久性であり自動リカバリーではない — 提案はサブプロセスフォールバックを導入しません；リカバリーは別のパーサー修正提案を待ちます。

ConvergenceResult.checkpoint_dir: Path | Noneは最新のラウンドのチェックポイントディレクトリを指します。リカバリー対応の呼び出し元はこのフィールドを読み取り永続化された検出結果を探します；既存の呼び出し元はこれを無視（後方互換性のためデフォルトはNone）。

オペレーター監視ログエントリ（Python logging、レベルERROR、extra={"event": ..., ...}で構造化）：

convergence.synthesis_failed_with_checkpoint — 合成（またはアップストリームFinding.from_dict()）がraise。ペイロードには手動リカバリー用のcheckpoint_dirを含む。
convergence.checkpoint_write_failed — チェックポイント書き込み中のOSError/PermissionError。元の例外は依然伝播。

合成失敗はオートパイロット呼び出し元に引き続き表示されます。この契約の価値は自動リカバリーではなく事後分析と手動リカバリーのための耐久性です — 手動呼び出し手順についてはdocs/parallel-agentic-development.mdセクション8を参照。

4. IMPLEMENTフェーズ

tasks.mdに従い、作業スライスの次を実装。IMPLEMENTフェーズはisolation="worktree"で実行される唯一のフェーズです — サブエージェントコミットは兄弟ワークツリーブランチに着地し、完了時にマージバック。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase IMPLEMENT --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。isolation値はIMPLEMENTで"worktree"。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。結果は成功時は"complete"、回復不可能なエラー時は"failed"（または"escalate"）。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase IMPLEMENT \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — /implement-feature <change-id>を呼び出し（ティアはコーディネーター + work-packages.yamlに基づき自動検出）。実装結果からpackage_authorsを記録。完了後、apply-outcomeを実行してphase_archetype = nullを記録。

4.5. IMPL_ITERATEフェーズ（常時実行）

実装のセルフレビューと改善。このフェーズはCLIモード問わず常に実行。提案、設計、および変更されたすべてのソースファイルを読み込み。バグ、セキュリティ問題、エッジケース、パフォーマンス問題を特定。結果は改善が落ち着いたときは"complete"、それ以外は"failed"。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase IMPL_ITERATE --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase IMPL_ITERATE \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — /iterate-on-implementation <change-id>を呼び出し。その後apply-outcomeを実行してこのフェーズでphase_archetype = nullが記録されるようにします。

完了時：IMPL_REVIEW（CLIモード）またはVALIDATE（非CLIモード）に遷移。 失敗時：ESCALATEに遷移。

5. IMPL_REVIEWフェーズ（収束ループ — CLIのみ）

cli_review_enabled=falseの場合はスキップ — VALIDATEに直接遷移。

マルチベンダー実装レビューとfix_mode="targeted"。結果はブロッキング検出がない場合は"converged"、ある場合は"not_converged"。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase IMPL_REVIEW --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase IMPL_REVIEW \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — fix_mode="targeted"とpost_fix_validatorコールバック（スコープ付きpytest/mypy/openspecチェック用）でコンバージェンスループを呼び出し。その後apply-outcomeを実行してphase_archetype = nullを記録。

対象実装修正（IMPL_FIX、サブエージェントディスパッチではない）：package_authorsからリードベンダーを検索、CliVendorAdapter.dispatch()を使用その特定ベンダーに修正を送信、パッケージのwrite_allowパスにスコープ。IMPL_FIXは前のIMPL_REVIEWからphase_archetypeを継承。

6. VALIDATEフェーズ

検証フェーズを実行（spec、evidence、deploy、smoke、security、e2e）per validate-feature。結果をPhaseRecordに集計。結果はPASS時は"continue"、FAIL時は"escalate"。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase VALIDATE --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase VALIDATE \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — /validate-feature <change-id>を呼び出し（ティアは自動検出）。その後apply-outcomeを実行してphase_archetype = nullを記録。

合格時：val_review_enabledを確認 — true の場合VAL_REVIEWへ、さもなければSUBMIT_PRにスキップ。 不合格時：VAL_FIXに遷移。

7. VAL_REVIEWフェーズ（オプション）

複雑性ゲートまたは--val-reviewフラグで有効化されている場合のみ実行。検証証拠をレビュー — 結果は検証が批評を通過すれば"converged"、さもなければ"not_converged"。

ディスパッチプロトコル（3段階）：

kwargsを構築：

python3 "<skill-base-dir>/scripts/runner.py" build-dispatch \
  --phase VAL_REVIEW --change-id <change-id>

Agent(prompt=<dispatch.prompt>, model=<dispatch.model>, isolation=<dispatch.isolation>)を呼び出し。promptを不透明として扱う。エージェントの最後のメッセージから(outcome, handoff_id)を解析。

結果を適用：

python3 "<skill-base-dir>/scripts/runner.py" apply-outcome \
  --change-id <change-id> --phase VAL_REVIEW \
  --outcome <outcome> --handoff-id <handoff_id>

フォールバック：archetype: nullまたはAgent(...)利用不可の場合、インライン経路を実行 — review_type="implementation"とfix_mode="targeted"でコンバージェンスループを呼び出し、検証証拠にスコープ。その後apply-outcomeを実行してphase_archetype = nullを記録。

8. SUBMIT_PRフェーズ

SUBMIT_PRフェーズアーキタイプを記録（状態のみリゾルバー — D9）。gh pr createを実行する前に、SUBMIT_PRのphase_archetypeを入力し、PR作成フェーズがディスパッチフェーズと一緒に可観測性ダッシュボードに見えるようにします：

python3 "<skill-base-dir>/scripts/runner.py" record-state-only-archetype \
  --change-id <change-id> --phase SUBMIT_PR

ここでの失敗は致命的ではありません（phase_archetype = nullを書き込み継続）。

完全な証拠跡を含むプルリクエストを作成：

gh pr create --title "feat(<change-id>): <summary from proposal>" --body "$(cat <<'EOF'
## Summary
[From proposal.md]

## Evidence Trail
- Plan reviews: X rounds, Y vendors, Z blocking findings resolved
- Implementation: N packages (strategy per package)
- Impl reviews: X rounds, Y vendors, Z blocking findings resolved
- Validation: passed/failed (test counts)
- Validation review: skipped | X rounds
- Total convergence rounds: N
- Total duration: Xm Ys

## Convergence Report
See loop-state.json for full state history.

Generated by /autopilot — awaiting human approval for merge.
EOF
)"

9. DONEフェーズ

最終戦略メモリを書き込み、以下を要約：

すべてのフェーズにおける総ラウンド数
ベンダー効果（ベンダーごとに提起された検出結果、確認された検出結果、作成された修正）
収束パターン（fast/slow/stalled）
パッケージごとに使用された実装戦略

最終ハンドオフドキュメントを書き込み。

停止 — /cleanup-feature <change-id>経由で人間によるマージ承認を待機。

進捗報告

各状態遷移時に報告：

[autopilot] Phase: PLAN_ITERATE → PLAN_REVIEW (self-review complete, 3 findings fixed)
[autopilot] Phase: PLAN_REVIEW → IMPLEMENT (converged in 2 rounds)
[autopilot] Finding trend: [8, 2, 0]
[autopilot] Vendor participation: claude ✓, codex ✓, gemini ✗
[autopilot] CLI review: enabled | disabled (--no-review or no vendor CLIs)

フェーズ別アーキタイプ解決

各非終端フェーズは、サブエージェントがディスパッチする前にアーキタイプ（例：architect、implementer、reviewer、analyst、runner）を解決します。解決されたア

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

autopilot

SKILL.md 本文

オートパイロット

引数

前提条件

コーディネーター機能チェック

ステップ

0. 引数の解析とレジューム確認

1. INITフェーズ

2. PLANフェーズ

フェーズ別サブエージェントディスパッチプロトコル

2.5. PLAN_ITERATEフェーズ（常時実行）

3. PLAN_REVIEWフェーズ（収束ループ — CLIのみ）

収束耐久性契約

4. IMPLEMENTフェーズ

4.5. IMPL_ITERATEフェーズ（常時実行）

5. IMPL_REVIEWフェーズ（収束ループ — CLIのみ）

6. VALIDATEフェーズ

7. VAL_REVIEWフェーズ（オプション）

8. SUBMIT_PRフェーズ

9. DONEフェーズ

進捗報告

フェーズ別アーキタイプ解決

詳細情報