pythia-autopilot

オートパイロットでの作業

開始時に宣言：「pythia-autopilot を使用します。書き込みのたびではなく、範囲を限定したリースについて一度だけ確認します。」

フェーズ： 確認 → 実行 — 開発者が承認する委任は一度だけです。その後は制限の範囲内で作業し、すべての書き込みについて報告します。

同じ承認を20回求めれば、開発者は読まずにクリックするようになります。承認ゲートは形だけのものになってしまいます。オートパイロットリースなら、誠実な手続きを一度行うだけで済みます。開発者は接続先、ステートメントのグループ、期間、書き込み予算が記されたカードを読み、一度だけ承認します。有効期間中は、apply と deploy によって対象となるステートメントが確認なしで適用されます。それでも、すべての書き込みはスナップショットが作成され、ジャーナルに記録され、検証されます。

鉄則

THE LEASE IS THE DEVELOPER'S. ITS LIMITS ARE NOT YOURS TO STRETCH.

リースの対象にならないもの

• 保護された接続（connections.json の "protected": true または "env": "prod"）— 無条件で拒否されます。
• 破壊的なステートメント — DROP、TRUNCATE、ALTER ... DROP、名前変更、SET UNUSED、REVOKE、WHERE のない UPDATE／DELETE — カードに「破壊的なステートメントを含む」と記載されていない場合。
• カードに記載されていないグループ、lint エラーがあるファイル、GRANT ... TO PUBLIC、ANY 権限または付与オプション、1,000行を超えるデータを変更する DML — これらはまず開発者に提示されます。
• 一時停止条件に該当した後のすべての操作：ほかのオブジェクトが INVALID になった場合、または書き込みが5回連続で失敗した場合。一時停止条件は、期間切れ、予算超過、autopilot off の実行後にも該当します。

ワークフロー

1. まず仕様を固めます（pythia-spec）。自律実行によってなくなるのは書き込みごとの確認であり、仕様に関する確認ではありません。リース開始前に、未決の判断事項を一度にまとめてすべて確認します。
2. タスクを満たす最も狭い範囲を提案します：開発用接続を使います。デフォルトではグループを plsql_source,comments とし、テーブルがタスクに含まれる場合に限って structural を追加します。依頼された場合に限って data_dml を追加し、破壊的な操作は開発者が明示した場合に限ります。期間と書き込み数は作業に合わせて設定します。
3. 申請します — pythia autopilot request --groups ... --hours ... --note "<the task>" を実行すると、カードと8桁の16進数トークンが表示されます。利用できる最初の承認方法を使って確認します。Claude Code では AskUserQuestion を使い、pythia approve --card <token> をそのまま提示します。Codex では pythia_approve ツールから始めます。開発者自身のターミナルを使ってもかまいません。autopilot on を実行するのは開発者であり、あなたではありません。
4. 通常のスキルを使って作業します — 変更の前には引き続き pythia-impact を実行します。その後、対象となるステートメントは pythia apply <file>／pythia deploy <files> で直接適用します。結果をすべて確認します。
   • 終了コード 0 — 適用済みです。続行します。
   • 独自オブジェクトのコンパイルエラーによる終了コード 3 — リースの範囲内で修正を進めます。
   • ほかのオブジェクトが新たに INVALID になったことによる終了コード 3 — リースは自動的に一時停止します。そこで止めて開発者に伝えます。続行するために新しいリースを申請してはいけません。
5. 対象外の場合 — プレビューに理由が表示されます（! autopilot: not covered — ...）。自分が原因の問題（lint エラー）を修正するか、そのステートメントについて通常の承認方法で確認を求めます。破壊的操作のチェックを回避するために、ステートメントの形を変えてはいけません。
6. 完了します：pythia autopilot report を実行します。各書き込みの判定と取り消しコマンドをすべて伝えます（破損したものを先にします）。続いて pythia autopilot off を実行します。リースはいつでも取り消せます。取り消しによって権限の範囲が狭まるだけです。

pythia autopilot status を実行すると、いつでもリースの状態を確認できます。セッション開始時の状態行にも表示されます。

注意すべき兆候 — こんな考えが浮かんだら中断してください

考え	実際のところ
「すべてのグループと破壊的操作を許可してもらえば、邪魔されずに済む」	条件に合う範囲で最も狭いスコープにしてください。破壊的なステートメントで中断されるのは、そのためです。
「リースで許可されているから、影響の確認は省こう」	リースによって不要になるのは承認であり、手順ではありません。まず影響を確認してください。
「一時停止された。新しいリースを申請して続けよう」	一時停止は、人が確認するためにあります。結果を提示し、判断はその人に委ねてください。
「Lint エラーだけど、開発者も気にしないだろう」	オートパイロットでそのまま適用することはできません。修正するか、その操作だけ承認を求めてください。
「自分でオートパイロットを有効にしよう」	CLI はコンソールなしでは受け付けません。有効にするのは開発者です。
「レポートには成功したものだけを載せればいい」	すべての書き込みを、失敗したものから先に、それぞれ元に戻す方法とともに記載してください。
「本番環境だけど、開発者が問題ないと言っていた」	保護された接続にリースが適用されることはありません。そこでの書き込みには、毎回承認が必要です。

このスキルを使用しない場合

• 開発者が変更を1つずつ確認したい場合 → 通常の pythia-apply フローを使用してください。開発者が求めていないリースを申請してはいけません。
• 変更が1つだけの場合 → リースよりも、1回の承認を得るほうが簡単です。