autopilot

name

autopilot

description

引数で渡された「監視条件」を満たす対象 (Linear チケット / GitHub PR・Issue / Sentry エラー / Slack メッセージ / CI・デプロイ状態 / 任意の MCP・シェルコマンドで観測できる状態 など何でも) を継続監視し、検出するたびに専用サブエージェントを起動して指定アクションまで自動で進める、セッション常駐のオートパイロット。監視条件もアクションも自然言語で自由指定でき (例: 自分にアサインされた Linear チケットを実装 / あるリポジトリに新規 PR が来たらレビュー / Sentry に新規エラーが出たら調査して報告 など)、ポーリングは ScheduleWakeup で自己ペース、各タスクはサブエージェントに丸投げしてメイン context を圧迫しない。「autopilot で〜を監視して」「〜が来たら自動で対応して」「/autopilot <監視内容>」「オートパイロット回して」などで発火する。マージ・本番反映等の不可逆操作は行わず、その手前で停止して報告する。

autopilot

引数 <監視する内容> で指定した監視条件を満たす対象を継続監視し、検出ごとに専用サブエージェントへ丸投げして指定アクションを 不可逆操作の手前まで 自動で進める、セッション常駐のオートパイロット Skill。

監視対象は限定しない。 ポーリングで観測できるものなら何でもよい:

• Linear チケット (アサイン / サブチケット追加 / ラベル付与 / state 変化)
• GitHub PR・Issue (新規作成 / レビュー依頼 / CI 失敗 / コメント)
• Sentry の新規エラー・再発
• Slack の特定メッセージ・メンション
• CI / デプロイの状態変化
• 任意の MCP ツール・シェルコマンドで観測できる状態

/autopilot <監視する内容>

<監視する内容> は 自然言語で自由に書ける。トリガー (何を監視し、何を「新規検出」とみなすか) と、必要なら アクション (検出したら何をするか) を含む。例:

/autopilot 自分にアサインされた Linear の Todo チケットを実装して
/autopilot henry-web に新規 PR が来たらレビューしてコメントして
/autopilot Sentry の production に新規エラーが出たら原因調査して Linear チケット化して
/autopilot EMRK-1234 にサブチケットが追加されたら、それを実装して

引数が空のときはデフォルトの監視対象を持たない。 必ずユーザーに「何を監視するか」を質問し、回答を <監視する内容> として受け取ってからループを開始する (監視対象の入力なしに勝手に走り出さない)。

中核原則

この Skill は 制御 (監視とディスパッチ) だけ を担う。実装・調査の重い context は持たない。

1. メインは context を太らせない。 拾ったタスクの実体 (調査・実装・検証・PR・CI 対応など) は、すべて タスク専用サブエージェント の中で完結させる。メインはサブエージェントの結果サマリだけを受け取る。
2. 検出 1 件 = サブエージェント 1 体。 新しく条件を満たす対象を検出したら、必ず新しい Agent を起動する。既存サブエージェントの使い回しはしない。
3. 隔離は必要なときだけ。 コード変更を伴うアクション (実装・修正) のサブエージェントは isolation: "worktree" + run_in_background: true で起動し、並行してもブランチ・作業ツリーが衝突しないようにする (ワクさんの worktree ベース開発に揃える)。調査・レビュー・通知のみでファイルを書き換えないアクションでは worktree 隔離は不要 (run_in_background: true だけでよい)。アクションの性質に応じて選ぶ。
4. 不可逆操作はしない。 マージ・リリース・本番反映・外部への破壊的変更はサブエージェントにさせない。その手前 (例: コード実装なら「マージ可能状態」、調査なら「報告まで」) で停止し、最終操作はユーザーの承認を待つ。
5. セッション内ループ。 ポーリングは ScheduleWakeup で自己ペース。セッションを閉じたら止まる (クラウド常駐が要るなら /schedule 系を別途検討)。
6. 状態はファイルに永続化。 各対象の処理状態は ~/.claude/autopilot/<slug>.json に書き出す (下記「状態ファイル」)。台帳をメモリだけに持たず、ScheduleWakeup 再入時もセッション再開時もファイルから復元する。

ワークフロー

フェーズ 0: 監視仕様の解釈 (起動直後に 1 回)

引数が空なら、解析の前にまずユーザーへ「何を監視するか」を質問する (AskUserQuestion 等を使う。デフォルトの監視対象は持たない)。回答を <監視する内容> とみなしてから先へ進む。

引数 <監視する内容> を解析し、監視仕様 (watch spec) を組み立てる:

• トリガー / 対象ソース — 何を、どの手段で観測するか。ソースに応じて取得手段を選ぶ:
  • Linear → mcp__claude_ai_Linear__list_issues / get_issue (assignee・state・親チケットの children・label で絞る。"自分" は list_users で特定)
  • GitHub → gh CLI / gh api (PR・Issue 一覧、レビュー状態、gh pr checks)
  • Sentry → sentry-cli スキル
  • Slack → Slack 検索ツール (メンション・キーワード・チャンネル)
  • その他 → 任意の MCP ツール / シェルコマンドの出力をポーリング
• 検出単位と一意キー — 何を 1 タスクとみなすか。各対象の 安定した一意キー (Linear チケット ID、GitHub PR 番号、Sentry issue ID、Slack message ts 等) を決め、これを台帳キーにする。
• 新規判定 — 一意キーが状態ファイルの台帳に無いものを「新規」とみなす。
• アクション — 検出時にサブエージェントへ実行させる内容。
  • 引数にアクションの明示があればそれを使う。
  • 明示が無く、対象が コード実装タスク (チケット実装等) なら「デフォルト実装アクション」(下記) を使う。
  • 明示が無く、対象が実装以外 (調査・レビュー・通知など) でアクションが曖昧なら、勝手に実装に倒さずユーザーにアクションを確認する。

仕様が致命的に曖昧なとき (対象 team やリポジトリが複数あり得る等) だけ最小限ユーザーに確認する。自明な点は確認で止まらず仮定を記録して進む。確定した監視仕様 (トリガー / 一意キー / アクション) を 1〜2 行でユーザーに提示してからループを開始する。

状態ファイルを開く。 監視仕様から短い <slug> を決め (例: assigned-linear-todo、henry-web-new-pr、sentry-prod-errors)、~/.claude/autopilot/<slug>.json を状態ファイルとする (下記「状態ファイル」)。

• 既存ファイルがあれば読み込み、台帳を復元する。ScheduleWakeup 再入時もセッション再開時もここから状態を引き継ぐ。
• セッション再開で in_flight を復元した場合は自動再開しない。 セッションを閉じるとバックグラウンドのサブエージェントは死ぬため、ファイルに残った in_flight は実体が無い「孤児」の可能性が高い。これらを 勝手に再ディスパッチせず、まず一覧をユーザーに提示して指示を仰ぐ:
  • 各 in_flight 対象について実状態 (PR の有無・中途 commit・CI 状況・チケット化の有無など、アクションに応じた成果物) を調べて添える。
  • ユーザーに「続行 (再ディスパッチ) / 破棄 (状態をリセット) / 完了扱い」のいずれかを選んでもらう。
  • 確認が取れた in_flight だけを処理し、未確認のものは触らない。新規対象 (まだ台帳に無いもの) の監視・ディスパッチは確認を待たず通常どおり進めてよい。
• ファイルがなければ新規作成し、確定した監視仕様を書き込む。
• パスをユーザーに 1 行で伝える (例: 状態ファイル: ~/.claude/autopilot/assigned-linear-todo.json)。

フェーズ 1: ポーリング

• 監視仕様のトリガー / 対象ソースに従って観測し、条件を満たす候補を取得する。
• 各候補の一意キーを台帳と突き合わせ、まだディスパッチしていない新規だけ を抽出する。
• 新規が 0 件なら何もせず フェーズ 4 へ (スリープして次ラウンド)。

フェーズ 2: ディスパッチ

新規検出ごとに、Agent ツールで 専用サブエージェント を起動する:

• subagent_type: "claude" (Skill / Bash / Edit など全ツールを使えるもの)
• run_in_background: true
• isolation: "worktree" — コード変更を伴うアクションのときのみ (調査・レビュー・通知だけなら付けない)
• description: "autopilot: <一意キー>"
• prompt: 監視仕様の アクション を埋め込んだプロンプト (下記テンプレート)

起動したらその一意キーを状態ファイルに in_flight として 即座に書き込み (二重起動防止のため起動と同時に永続化する)、次へ。メインはサブエージェントの完了を 待たずに 次へ進む (完了は通知で受ける)。

デフォルト実装アクション (コード実装タスクのとき)

アクション未指定で対象がコード実装タスクの場合、サブエージェントに渡すアクションはこれ:

1. dev-task スキルで <対象チケット> を実装する
   (Linear からチケット本文・受け入れ条件を取得 → 計画 → 実装 → 型/ビルド/テスト/lint → レビュー → commit)。
2. dev-workflow:create-pr スキルで PR を作成する (PR タイトルは日本語、Linear チケットとリンク)。
3. CI を監視: `gh pr checks <PR>` で確認し、失敗は原因特定して修正・push、green になるまで対応。
   レビューコメントが付いたら対応して push (review-pr のセルフレビューも活用可)。
4. ゴール = マージ可能状態: CI green かつレビュー対応済みかつ base へコンフリクトなし。**マージは絶対にしない。**

サブエージェントへ渡すプロンプトテンプレート

あなたは autopilot が検出した次の対象を担当します。

【対象】
<一意キー と、対象の概要 (チケット要約 / PR タイトル / エラー内容 など)>

【実行するアクション】
<監視仕様のアクション (デフォルト実装アクション or 引数で指定されたもの) をここに展開>

【共通ルール】
- 破壊的・不可逆操作 (マージ / リリース / 本番反映 / 外部への破壊的変更) はしない。該当ゴールに達したら停止する。
- コード変更を伴う場合、このワークツリーはあなた専用の隔離環境。
- 判断に迷う設計上の岐路・受け入れ条件の重大な欠落に当たったら、勝手に進めず状況を結果に明記して停止する。

最終メッセージは「あなたの戻り値」です。人間向けの装飾は不要。以下を簡潔な構造で返してください:
- key: <一意キー>
- status: done | ready_to_merge | blocked | failed
- artifact: <PR URL / 作成したチケット / 報告先 など、なければ「なし」>
- summary: 何をしたか 1〜3 行
- blockers: 停止した場合の理由・必要な判断 (なければ空)

CI や外部待ちが発生してもサブエージェントはバックグラウンドで進む。メイン側はそのままポーリングループを継続してよい。

フェーズ 3: 完了の集約・報告

• サブエージェント完了の通知を受けたら、結果サマリだけをメインに取り込み、状態ファイルの該当対象を done / ready_to_merge / blocked / failed に更新する (artifact・summary・updatedAt も書く)。
• ユーザーへ 1 件につき 1 回、簡潔に 報告する (例: EMRK-123: マージ可能 ✅ PR #456 / PR #789: レビュー投稿済み ✅ / Sentry ABC: 調査完了→ EMRK-200 起票 ✅)。
• ready_to_merge 等の不可逆操作直前のものは その操作をせず、最終操作は別途ユーザー指示を待つ。

フェーズ 4: 次ラウンドの予約 / 停止

• ScheduleWakeup を呼び、prompt に 元の起動コマンド全文 (/autopilot <監視する内容>) を渡して次ラウンドへ再入する。監視仕様を毎回引き継ぐためにこれが重要。delaySeconds は状況に応じて自己判断:
  • in-flight が多い / CI 待ちが活発 → 短め (数分。キャッシュ維持のため 270s 以内が無駄がない)
  • 新規が暫く来ていない・全部 idle → 長め (20〜30 分 = 1200〜1800s)
  • 監視対象がイベント駆動 (サブチケット追加待ち・Sentry 新規エラー待ち等) で変化が遅いなら、その変化頻度に合わせる
• 次のいずれかでループを 停止 し、ScheduleWakeup を呼ばない:
  • ユーザーが「止めて」と指示した
  • 同種のエラーで連続して失敗している (無限リトライしない。状況を報告して指示を仰ぐ)

状態ファイル

各対象の処理状態は ~/.claude/autopilot/<slug>.json に永続化する。<slug> は監視仕様から導く安定したキー (同じ監視内容なら毎回同じファイルに着地させる)。ディレクトリがなければ mkdir -p ~/.claude/autopilot で作る。

スキーマ:

{
  "slug": "assigned-linear-todo",
  "watchSpec": {
    "raw": "自分にアサインされた Linear の Todo チケットを実装して",
    "source": "linear",
    "trigger": "assignee = self, state = Todo",
    "keyField": "Linear issue identifier (例: EMRK-123)",
    "action": "default-implement (dev-task → PR → CI → ready_to_merge)"
  },
  "startedAt": "2026-06-09T12:00:00Z",
  "updatedAt": "2026-06-09T12:34:00Z",
  "items": {
    "EMRK-123": {
      "status": "ready_to_merge",
      "artifact": "https://github.com/.../pull/456",
      "summary": "○○ を実装、CI green",
      "blockers": "",
      "dispatchedAt": "2026-06-09T12:05:00Z",
      "updatedAt": "2026-06-09T12:30:00Z"
    }
  }
}

• items のキーは対象の 一意キー (チケット ID / PR 番号 / Sentry issue ID / Slack ts など監視仕様で決めたもの)。
• status の取りうる値: in_flight / done / ready_to_merge / blocked / failed。
• 書き込みは 状態が変わるたび (ディスパッチ時・完了通知時)。読み書きはメイン (制御ループ) のみが行い、サブエージェントは触らない (戻り値サマリ経由でメインが反映)。
• タイムスタンプは date -u +%Y-%m-%dT%H:%M:%SZ で採る。
• このファイルがあるおかげで、/autopilot <同じ監視内容> を別セッションで再実行しても処理済みの対象を二重起動しない。

安全装置

• 二重起動防止。 状態ファイルで in_flight / 完了を管理し、ディスパッチと同時に永続化することで、同一対象に複数サブエージェントを立てない (セッションを跨いでも)。
• 不可逆操作はしない。 マージ・リリース・本番反映等はゴール手前で停止し承認を待つ。
• エラーで無限ループしない。 リトライは有限回。行き詰まったら停止してユーザーへ報告。
• メイン context 保護。 タスクの実装ログ・diff・大きな出力をメインに引き込まない。サブエージェントの構造化サマリだけを保持する。

起動例

/autopilot                                          # 引数なし → 「何を監視するか」を質問される (デフォルト挙動なし)
/autopilot 自分にアサインされた Linear の bug ラベルチケットを実装して
/autopilot EMRK-1234 にサブチケットが追加されたら実装して
/autopilot henry-web に自分宛てレビュー依頼が来たらレビューしてコメント投稿して
/autopilot Sentry の production に新規エラーが出たら原因調査して Linear チケット化して報告