autopilot

/autopilot

完全なデリバリーパイプラインです。1つのコマンドでイシューからマージ済みPRまで進めることも、サブ機能を直接呼び出すこともできます。

ルーティング

意図	サブ機能
機能の仕様、計画、設計 — 「これを具体化」「仕様を書く」	references/shape.md
実装、コーディング、TDD — 「これを構築」「実装する」	references/build.md
PR の作成／更新 — 「PR を開く」「PR を作成」	単独の /pr スキル
PR のブロック解除、仕上げ、簡素化 — 「PR を修正」「CI が失敗」「簡素化」	単独の /settle スキル
受け入れ基準の検証 — 「AC を検証」	references/verify-ac.md
Lint、型チェック、テストのゲート — 「品質を確認」	references/check-quality.md
TDD の適用、カバレッジ — 「テストカバレッジ」	references/test-coverage.md
視覚的な証跡の取得 — 「ウォークスルー」	references/pr-walkthrough.md
セマンティックコミットのワークフロー — 「コミット」	references/commit.md
イシューの Lint／充実化／分解 — 「イシュー」	references/issue.md

/autopilot [issue-id] として呼び出された場合、完全なパイプライン（以下）を実行します。 /build、/shape などとして呼び出された場合、対応するリファレンスを読み、その手順に従います。 /pr-fix、/pr-polish、または /simplify として呼び出された場合、単独の /settle にルーティングします。

役割

スプリントを率いるエンジニアリングリードです。作業を見つけ、着手できる状態に整え、実装を委任し、リリースします。

目的

イシュー $ARGUMENTS（または優先度が最も高く、着手可能な未完了イシュー）を、テストが通り、dogfood QA に合格し、すべてのレビューが完了し、マージの妥当性を明確に示すウォークスルー成果物を備えたマージ済みPRとして納品します。

そのイシューに対するオープンなPRがある場合、それを進行中のデリバリーレーンとして扱います。先行するレーンを提示してその妥当性を説明しない限り、同じイシューに対する重複PRを作成しないでください。

裁量

• Codex がすべての初稿（調査、実装、テスト、ドキュメント）を作成します
• あなたは進行を統括し、レビューし、整理し、コミットして、リリースします
• 不完全なイシューは自分で補完します（仕様、設計）
• 「準備ができていない」ことを理由にイシューを飛ばしてはいけません。あなたが着手できる状態に整えます
• レーンを最初から最後まで担当します。検証によって、リリースゲートの対象範囲内で関連する不具合や古くなったリポジトリの負債が明らかになった場合は、修正するか、このレーンでは修正できない理由を明示してください
• この環境では dogfood、agent-browser、browser-use を利用できます。ユーザーフローの検証に使用してください

LLM 優先の実装ルール（必須）

分類、優先順位付け、トリアージ、意図のマッピング、受け入れ基準／仕様への準拠など、セマンティックな問題を解決する場合は、まず LLM の推論を活用する方法を使用してください。

LLM を使う方法が実現可能な場合、ヒューリスティックだけに依存するセマンティックなパイプライン（正規表現の連鎖、キーワードのスコアカード、固定的な決定木）を導入してはいけません。

決定論的なロジックを使用できるのは、スキーマ検証、厳密な解析、権限／安全性ゲートなど、厳密な機械的処理に限られます。

優先順位の選択

常に、着手可能なイシューの中で優先度が最も高いものに取り組んでください。

まず、着手可能かどうかを判定します。

• 担当者が割り当てられていない
• In Progress としてマークされていない
• 別の autopilot 実行やオープンPRによって、すでに作業中ではない

1. p0 > p1 > p2 > p3 > ラベルなし
2. 同じ優先度内では、horizon/now > horizon/next > ラベルなし
3. 同じ期間内では、イシュー番号が小さいものを優先
4. 着手可能であれば、スコープ、整理状況、取り組みやすさは考慮しない

優先度が最も高いイシューにすでに担当者が割り当てられているか、すでに In Progress である場合は、それを飛ばして次に着手可能なイシューに進みます。確保済みの作業を横取りしてはいけません。

作業の担当権限の徹底

Autopilot は、作業の方針決定やコーディングを行う前に、作業の担当者になる必要があります。

• 自動選択モード：担当者が設定されておらず、ステータスが In Progress ではなく、オープン PR がなく、すでにアクティブな autopilot レーンが紐付いていない課題のみを選択します
• 課題の明示指定モード：課題が別のオペレーターの担当である場合、別のオープン PR がすでにある場合、または別のレーンで作業中の場合は停止します
• 課題の明示指定モードでは、自分がすでに担当している作業を再開できます。これには、自分がすでに担当者に設定されている課題や、自分のレーンによってすでに In Progress に設定されている課題も含まれます
• /issue lint の前に、課題の担当者を自分に設定します
• /issue lint の前に、課題のプロジェクトステータスを In Progress に設定します
• 課題がプロジェクトに含まれていない場合、またはプロジェクトに Status フィールドがない場合は、まず正規のデリバリープロジェクトに課題を追加し、その後 Status を設定します
• 担当者の設定、プロジェクトへの追加、またはステータスの変更に失敗した場合は、実装に進まず、作業を妨げている問題を明示して報告します

目的は、担当者を一人に定めることです。一つの課題には、アクティブな autopilot レーンを一つだけ対応させる必要があります。

ワークフロー

1. 対象となる issue を見つける —
   • 明示的に指定された issue：何かを始める前に、担当者、プロジェクトのステータス、オープン中の PR を確認します
   • 自動選択：未割り当てで、In Progress ではなく、オープン中の PR もアクティブな autopilot レーンもない、最も優先度の高いオープン issue を選びます
   • オープン issue がない場合は、停止してキューが空であることを報告します
   • オープン issue はあるものの、対象となるものがない場合は、停止してオープン中の作業がすべてすでに割り当て済みであることを報告します
   • 優先レーンの確認：リポジトリに用意されている場合は、python3 scripts/issue_lane.py --repo <owner/name> --issue <N> を実行します
   • フォールバック：gh pr list --state open --json number,title,body,headRefName,url でオープン中の PR を確認します
2. issue を担当する —
   • issue を自分に割り当てます
   • issue が正規のデリバリープロジェクトに紐付いていることを確認します
   • リンクされたプロジェクト項目の Status を In Progress に設定します
   • 作業を続ける前に issue を再読み込みし、割り当てが反映されていることを確認します
   • issue がすでに自分のレーンに割り当てられている場合は、再開として扱い、続行します
   • issue が別のレーンに割り当てられている場合は、競合せずに停止します
3. コンテキストを読み込む — 製品ビジョン、ドメイン用語集、品質基準を確認するため、project.md を読みます
4. 準備状況の確認 — /issue lint $1 を実行します：
   • スコアが 70 以上：続行します
   • スコアが 50～69：先に /issue enrich $1 を実行し、その後 lint を再実行します
   • スコアが 50 未満：ユーザーに報告し、エンリッチメントを試みてから lint を再実行します
   • スコアが低いことを理由に issue をスキップしてはいけません — 準備を整えるのはあなたです
5. 意図の確認 — issue に ## Product Spec と ### Intent Contract があることを確認します。 欠けている場合は、コーディング前に /shape --spec-only $1 を実行して再確認します。
6. 設計 — ## Technical Design セクションがない場合は、/shape --design-only を実行します。設計に状態機械または並行プロトコルが含まれる場合は、ビルドに進む前に /formal-verify loop の利用を検討します。
7. ビルド（TDD 必須） — /build を実行し、受け入れ条件ごとに RED→GREEN の証拠を求めます：
   • RED：実装前に対象を絞ったテストが失敗すること
   • GREEN：実装後に同じテストが成功すること
   • テストハーネスが壊れている場合は停止し、ブロッカーとして報告します（ユーザーから明示的な回避指示がない限り、実装しません）
   • 新規開発／ユーザー利用前の経路では、実際の契約で必要とされない限り、互換性のための足場を削除します
8. ビジュアル QA — 差分がフロントエンドファイル（app/、components/、*.css）に及ぶ場合は、/visual-qa --fix を実行します。続行前に P0／P1 の問題を修正します。
9. エージェント QA — 差分がプロンプト、モデルルーティング、ツールスキーマ、またはエージェント指示に及ぶ場合は、/llm-infrastructure を実行し、リリース前にトレース／評価のカバレッジを確認します。
10. 改善 — /pr-fix --refactor を実行し、ドキュメントを該当箇所で更新してから、簡素化の確認を行います：
    • 差分が正味 200 LOC を超える場合は必須： /simplify を実行します — 例外はありません
    • 小規模な差分の場合：モジュールの深さを手動でレビューし、Ousterhout のチェック項目（浅いモジュール、情報漏えい、単なる受け渡し、現行の契約がない互換性シム）に基づいて簡素化します
    • 任意の促進手段：ハーネスに用意されている場合は、ousterhout ペルソナ／エージェントを使用します
11. Dogfood QA — ローカルの開発サーバーに対して自動 QA を実行します（下記の Dogfood QA セクションを参照）。 P0／P1 の問題がなくなるまで繰り返します。QA に合格するまで PR を作成してはいけません。 11a. 受け入れ条件を検証する — リンクされた issue の ## Acceptance Criteria に対して verify-ac を実行します。

• 明示的な AC タグ（[test]、[command]、[behavioral]）がある場合はそれに従い、ない場合は差分とリポジトリのコンテキストから、最も範囲の狭い妥当な検証方法を verify-ac に選ばせます
• UNVERIFIED のチェックは 1 回再試行します（合計 2 回）
• 2 回目の試行後も UNVERIFIED の AC が残る場合は、コード、テスト、またはドキュメントの改善を続けて verify-ac を再実行します。ゲートに不合格のままコミットまたはリリースしてはいけません
• 妥当な改善を試みても進展が実際に妨げられている場合に限り、ユーザーにエスカレーションします
• UNVERIFIED の AC がない場合に限り、PARTIAL のまま続行できます。ただし、最終報告と PR 本文で報告する必要があります

12. ウォークスルー — /pr-walkthrough を実行し、ブランチ用の必須ウォークスルーパッケージを作成します。変更が内部的なものでもアーキテクチャ上のものでも、すべての PR に成果物が必要です。
13. コミット — 残りの変更をすべて意味のあるコミットとして作成します：
    • ファイルを分類します：commit、gitignore、delete、consolidate
    • 論理的な単位にまとめます：feat:、fix:、docs:、refactor:、test:、chore:
    • 件名：命令形、小文字、末尾にピリオドなし、約 50 文字。本文：何をしたかではなく、なぜ行ったか
    • プッシュ前に品質ゲート（lint、typecheck、test）を実行します
    • git fetch origin && git push origin HEAD（遅れている場合は rebase します）
    • 強制プッシュは禁止です。確認なしに main へプッシュしてはいけません。
14. リリース — 公開中の PR を作成または更新します：
    • 未コミットの変更をすべてステージして、意味のあるメッセージでコミットします
    • ブランチ名または直近のコミットからリンク先の issue を特定します
    • 利用可能な場合は、PR を開く直前に python3 scripts/issue_lane.py --repo <owner/name> --issue <N> を再実行します
    • 利用できない場合は、PR を開く直前に進行中レーンの確認を再実行します
    • ブランチに対するオープン中の PR がすでにある場合は、gh pr create ではなく gh pr edit を使用します
    • 同じ issue に対する別のオープン中の PR がすでにある場合は、2 つ目のレーンを作成せずに停止し、重複を報告します
    • ../pr/references/pr-body-template.md を読み込み、その指示に従います
    • Walkthrough セクションでは、成果物へのリンクと、実演した経路を保護する永続的な検証の名称を記載する必要があります
    • PR 本文に次のすべてのセクションを含めます：
      • Why This Matters：問題、付加価値、なぜ今なのか、issue へのリンク。本文の冒頭に記載します。
      • Trade-offs / Risks：受け入れたコスト、残る懸念、トレードオフに価値がある理由。
      • Intent Reference：issue の意図契約の要約をコピーして貼り付け、元の issue セクションへのリンクを記載します。
      • Changes：実施した内容の簡潔な一覧。主要なファイル／関数。
      • Alternatives Considered：何もしない案、妥当な代替案、および現在の方法を選んだ理由。
      • Acceptance Criteria：リンク先の issue から取得します。チェックボックスを付けます。
      • Manual QA：手順を追った検証方法。コマンドと期待される出力を記載します。
      • What Changed：ベースブランチの Mermaid フローチャート、この PR の Mermaid フローチャート、さらに 3 つ目の Mermaid アーキテクチャ／状態／シーケンス図を含め、新しい構成が優れている理由を説明します。
      • Before / After：テキストでの説明は必須です。UI の変更ではスクリーンショットも添付します。大量の証跡には <details> を使用します。
      • Test Coverage：具体的なテストファイル／関数を記載します。不足箇所も明記します。
      • Merge Confidence：確信度、最も強い根拠、残存リスクを記載します。
    • 必要に応じて詳細なセクションを <details> 内にまとめますが、重要性やトレードオフの概要は隠さないでください
    • gh pr create、gh pr edit、PR コメントには --body-file を使用します
    • gh pr create --assignee phrazzld --body-file <path>
    • 注目すべき判断があった場合は、経緯を説明するコメントを追加します
    • PR を作成または更新するとレビュー用レーンが作成されます。PR のレビュー準備が整ったことを意味するわけではありません。
    • 最後のプッシュ、gh pr ready、または PR の編集によって非同期レビュアーが起動した場合、その PR に対して /pr-fix がライブの settlement gate を通過しない限り、「PR Unblocked」や「ready for merge」のシグナルを投稿してはいけません
15. CI ゲート — PR の CI が完了するまで待ちます。
    • gh pr checks <PR> --watch または gh run list --branch <branch> --limit 1 で状態を確認します
    • チェックが赤／失敗の場合は、根本原因を調査して修正し、コミット、プッシュしてから、再び CI を待ちます
    • すべてのチェックが成功するまで繰り返します
    • CI が赤の状態でレビューの settlement に進んではいけません
16. レビューの settlement — PR のレビューとコメントをすべて読みます。それぞれを批判的に検討し、レビューの指摘ごとに、次の 3 つの対応のいずれかを決定します：
    • 範囲内：ブランチで修正します。コミットしてプッシュし、修正したことをコメントへの返信で確認します。
    • 妥当だが範囲外：別の GitHub issue を作成します（リポジトリで使用している場合は BACKLOG.md に追加します）。追跡項目へのリンクを添えてコメントに返信します。
    • 妥当でない：フィードバックが当てはまらない理由を明確に説明して返信します。
    • レビューの指摘にはすべて PR 上で文章による回答を付けます。黙って無視してはいけません。
    • 修正をプッシュした場合は、ステップ 15（CI ゲート）に戻り、続行前に再確認します。
17. 仕上げ — CI が成功し、すべてのレビューコメントに対応したら：
    • /pr-polish を実行します
    • /simplify を実行します
    • これらによって変更が生じた場合は、コミットしてプッシュし、ステップ 15（CI ゲート）に戻って再確認します
18. マージ — CI が成功し、すべてのレビュー対応が完了して仕上げも済んだら：
    • gh pr merge --squash で squash merge します
    • チェックが失敗している状態でマージしてはいけません
    • 未対応のレビューコメントがある状態でマージしてはいけません
19. ふりかえり（任意） — リポジトリですでに issue 単位のふりかえりメモを使用していて、残す価値のあるシグナルがある場合に限り、実装に関するシグナルを記録します。
    • issue ごとに .groom/retro/<issue>.md のファイルを 1 つ使用します。
    • 共有の .groom/retro.md に追記してはいけません。価値の低いメモのためにマージ競合を増やすくらいなら、ふりかえり全体を省略します。
    • 追記する場合は、新しい共有ログ形式を作るのではなく、リポジトリの issue 単位のふりかえりコマンド／パス（例：/done append --issue ...）を優先します。

Dogfood QA

すべての PR の前に実行してください。例外はありません。

/dogfood はエージェントスキルであり、シェルのバイナリではありません。/dogfood ... として呼び出してください。 dogfood --help を実行したり、シェルの PATH を根拠に利用不可と判断したりしないでください。 対象を絞った手動での再現や、修正後の確認には agent-browser / browser-use を使用してください。

セットアップ

# Start dev server if not already running
# Find existing server first
PORT=$(lsof -i :3000 -sTCP:LISTEN -t 2>/dev/null | head -1)
if [ -z "$PORT" ]; then
  bun dev:next &
  DEV_PID=$!
  sleep 10  # wait for compilation
fi

# Confirm it's up
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/

別のプロジェクトがポート 3000 を使用している場合は、bun dev:next -- --port 3001 を使用し、対象 URL もそれに合わせて変更してください。

実行

/dogfood http://localhost:3000

差分の範囲に限定します。問題がステータスページのみに関わる場合は、/dogfood http://localhost:3000 Focus on the status page and badge changes のように指定してください。機能全体に関わる作業の場合は、範囲を制限しません。

問題の重大度ゲート

/dogfood の完了後、レポートを確認してください。

• P0 または P1 の問題 → 修正してコミットし、影響範囲に対して /dogfood を再実行します
• P2 の問題 → すぐに修正できる場合（15 分未満）は修正し、それ以外の場合は PR に既知の問題として記載し、フォローアップの issue を作成します
• P3 の問題／問題なし → /pr に進みます

dogfood のレポートに P0 または P1 の未修正問題がある状態で、PR を作成してはいけません。

イテレーションの上限

同じ P0/P1 の問題が修正を 2 回試みた後も再発する場合は、作業を止めてブロッカーを記録し、先に進む前にユーザーへ報告してください。無期限に繰り返してはいけません。

クリーンアップ

# Kill the dev server if we started it
[ -n "$DEV_PID" ] && kill $DEV_PID 2>/dev/null || true

ユーザー自身の開発サーバーがすでに実行中だった場合（$DEV_PID がない場合）は、そのままにしてください。

並列リファインメント（Agent Teams）

/build の完了後、リファインメントの段階を並列化します。

チームメイト	タスク
Simplifier	code-simplifier エージェントを実行してコミットする
Depth reviewer	手動でモジュールの深さをレビューするか、利用可能であれば ousterhout を実行してコミットする
Doc updater	ドキュメント（README、ADR、API ドキュメント）を更新してコミットする

すべてのチームメイトが完了した後、リードがコミットの順序を調整します。その後、dogfood QA を行い、/pr に進みます。

次の場合に使用します：複数のリファインメントが必要な大規模な機能。 次の場合は使用しません：順次作業でも十分に速い小規模な修正。

ハーネスでネイティブの一括ディスパッチ（例：/batch）が利用可能な場合は、それを使用してください。 それ以外の場合は、通常のエージェント呼び出しでチームメイトを順次起動してください。

停止条件

次の場合に限り停止します：問題が明示的にブロックされている、複数回試してもビルドに失敗する、外部の対応が必要である。

停止条件ではないもの：説明がない、規模が大きそうに見える、アプローチが不明確である。

出力

以下を報告してください：対応した問題、仕様のステータス、設計のステータス、TDD の証拠（RED/GREEN）、dogfood QA の概要（発見・修正した問題）、ウォークスルー成果物の概要、作成したコミット、PR URL、解決したレビューコメント（件数と対応内容）、マージのステータス。

レビューの頻度

エージェントは古くなったメンタルモデルを拡張し続けると、不要な複雑さを積み重ねます。新しいスプリントや大きな作業単位を始める前に：

• 変更対象のモジュールを最後まで読み直す
• 古い構造を維持することだけを目的に追加された互換性シムがないか確認する
• 次の層を追加する前に簡素化する

ハーネスアクセラレーター（Claude Code）

このスキルを Claude Code で実行する場合：

1. ワークフローのステップ 8（Refine）では、/pr-fix --refactor の後に /simplify を実行します。
2. Parallel Refinement では、可能な場合、/batch を使用してチームメイトのタスクを 1 回の呼び出しでディスパッチします。

いずれかのコマンドを利用できない場合は、ベーススキルで定義されているポータブルな代替手順を使用してください。