autopilot

Autopilot

Autopilot は、指示されたアイデアを、各段階でユーザーの承認を求めることなく、1 回の対話で言葉から動作するプロジェクトへと形にします。必要なルールはすべて phases/ と prompts/ にあり、ほかのスキルをインストールする必要はありません。

**順序こそがプロダクトです。**コードを書くのは最後から 2 番目のフェーズです。それより前のすべてのフェーズでは、何を作るかを決め、それ以降のフェーズでは、正しいものが作られたことを証明します。

ブリーフは契約であり、設計ではありません。 ひそかに消えてよいものはありません。ユーザーの言葉は、何よりも先に番号付きのマニフェストとなり、すべてのフェーズはそれを基準に進みます。安易なバイブコーディングで問題になるのは、3 回目の書き直しあたりで要件が存在しなくなることです。また、ブリーフはシルエットです。ハッピーパスだけを記述し、その内側には踏み込まないため、空の状態、失敗、制限を明らかにすることは正当な作業です。どこまで掘り下げるかは、ユーザーの深度ダイヤルで決まります。ブリーフから逸脱する深度は決して許されません。

このスキルの読み方

このファイルはオーケストレーターです。順序、ゲート、決して失われないルールを定めています。各フェーズのルールはそれぞれのファイルにあり、そのフェーズが始まるときに読み、それより前には読まないでください。一度に 1 つのファイルだけを読み、先のファイルには目を通さないでください。早い段階で開いたファイルは、実行中に更新されない唯一のコンテキストに残り続けます。

フェーズ	読むもの	生成するもの
0 事前確認	phases/0-modes.md、phases/0-preflight.md、続いて 0-memory.md、0-instruments.md	モードの告知、リポジトリの設定、ダッシュボードを開く、完了した実行後の carried.md
1 マニフェスト	phases/1-manifest.md	<дата>-brief.md、manifest.md
2 ブリーフィング	phases/2-briefing.md（実行する場合は 2-adversarial.md も）	回答をマニフェストに記録
3 仕様	phases/3-spec.md	既存コード内の notes.md、spec.md、interfaces.md 内の境界
4 計画	phases/4-plan.md	tickets/NN-*.md、計画のコミット
5 構築	phases/5-subagents.md	コード、チケットごとに 1 つのコミット
6 レビュー	phases/6-review.md — 最初のポイントレビュー、およびブランチ全体のレビュー	レビュー済みコード
8 最終	phases/8-final.md、起動前に phases/9-memory.md	ブラインド受け入れ、メモリ、進捗ファイル、レポート
—	phases/0-resume.md — 再開時は事前確認の代わりに使用
—	phases/5-repair.md — チケットの結果がクリーンな DONE 以外の場合に使用
—	phases/9-memory.md — フェーズ 5 でも、チケットで保持する価値のあることが見つかった場合に使用
—	phases/rationalizations.md — ゲートに失敗したとき、何かを正当化しそうになったとき、レポート前に 1 回

コンパクション後は、フェーズではなく状態を読み直してください。 state.js（dir と skillDir を保持）、manifest.md、interfaces.md、実行に carried.md がある場合はそれも、そして現在のフェーズのファイルです。それ以外は何も読みません。

ユーザーに見える言葉

ここでのフェーズ名は英語で、ユーザーに見せることはありません。チャット、ダッシュボード、レポートでは、各ステージにつきロシア語の単語をちょうど 1 つ使います。

ステージ ID	ユーザー向け
preflight · manifest · briefing · spec	Подготовка · Требования · Брифинг · Спецификация
plan · build · review · final	План · Разработка · Код-ревью · Приёмка

「Сборка」は実行全体を指すため、5 番目のステージは「Разработка」です。**作業単位は「таск」**です。「задача」はユーザーが提示したものを指します。

フライト

Phase 0（phases/0-modes.md）で一度だけ決める2つのダイヤル：モード — full、semi（デフォルト）、interview、manual；深度 — strict、normal（デフォルト）、deep。

フェーズ	full	semi	interview	manual
1 マニフェスト	自動	自動	自動	自動
2 ブリーフィング	自己ブリーフィング	ブリーフで未確定の箇所のみ	敵対的レビューの後、すべての分岐	同じ
3 仕様	自動	自動	自動	表示 → «ок» を待つ
4 計画	自動、通知	自動、中断可能	自動、中断可能	議論 → «ок» を待つ
5 ビルド · 6 レビュー	自動	自動	自動	自動
8 最終	レポート + Assumptions	レポート	レポート	レポート

interview と manual の違いは、仕様のゲートと計画のゲートという2つのセルだけです。

マニフェストのゲートはすべてのモードで実行されます — ビルドをユーザー自身の言葉と照合して確認し、ユーザーの時間は取りません。

ゲート	実行後	合格条件
G1	ブリーフィング	すべての要件にステータスがあり、理由の記録なしに open のものがない
G2	仕様	open がゼロ — さらに、ブリーフと仕様だけを渡された独立した読者が、漏れを何も見つけない
G3	計画	すべての in-spec 要件がチケットに含まれ、すべてのチケットが要件に対応している — ap.py check-plan
G4	最終	仕様を見せず、クリーンなクローンから、ブリーフに照らしてブラインド受け入れテストを実施

G2 と G4 は、フライトの両端で行う1つの確認です。あなたの言い換えを取り除き、ユーザーの言葉に照らして評価します。その間は、すべてを仕様に照らして評価します。仕様は実行担当者に渡された契約だからです。ゲートに不合格だった場合、そのフェーズをやり直します。

計画は修正できますが、ブリーフは修正できません。 ビルドによって計画が誤っていたと判明した場合は、仕様を修正し、コードが示した内容を D## 行に記録します（phases/5-repair.md） — 要件を取り下げたり、アイデアを紛れ込ませたりするために使ってはなりません。

シークレット

すべてのフェーズに適用されます。各フェーズで繰り返し説明することはありません。

• 決して値を尋ねません。 どのプロバイダーを使うか、アカウントがあるかどうかは質問してもよいですが、キー、トークン、パスワード、接続文字列は決して尋ねません。
• 取り込む時点で、何かに書き込む前に必ずマスキングします — phases/1-manifest.md のゲートです。「そのまま」とは、常に「マスキング後の内容をそのまま」という意味です。
• 名前で参照します — STRIPE_SECRET_KEY。値はユーザー自身が .env に入力します。最初のコミット前に .env を無視対象にし、レポートには未入力の名前を記載します。
• シークレットの漏えいは停止条件です：ただちに平易な言葉で報告し、ローテーションするよう助言します — まず ap.py ask stop を実行し、ダッシュボードにも表示します。

このスキルが管理するファイル

.autopilot/
├── <YYYY-MM-DD>-<slug>--wip/   one run; the suffix comes off when it lands
│   ├── <YYYY-MM-DD>-brief.md   the user's words, redacted; later changes appended
│   ├── manifest.md             requirements and their status
│   ├── reference.md            what it should be like — the user's comparables only
│   ├── spec.md                 the specification
│   ├── interfaces.md           the boundaries, the project rules, what finished tickets built
│   ├── notes.md                exploration notes, in an existing codebase
│   ├── carried.md              what the last run left, read at preflight — after a landed run only
│   ├── memory-proposal.md      what to add to the user's own memory file, if it is theirs
│   └── tickets/NN-<slug>.md
├── README.md        how to read this folder, and the register of runs
├── PROGRESS.md       where the work stands between runs — read by the next run and by plain sessions
├── state.js         the run state — written only by ap.py
├── ap.py            one call per event: state, dashboard, server
├── dashboard.html   the human view; carries a snapshot of the state
└── index.html       → dashboard.html

AGENTS.md (+ CLAUDE.md → AGENTS.md)    the project memory — or the user's own file, left untouched
docs/architecture.md, docs/adr/        at T2+: how it is built, and why
CONTEXT.md                             at T2+: the project's words — or the user's own, only added to

.autopilot/ はコミットします — これは、何を約束し、何を届けたかを記録するユーザーの記録です。メモリファイルは、次に開く人が確認する時点でのプロジェクトの状態を示します。docs/adr/ は、その状態に至った理由を示します。CONTEXT.md は、プロジェクトの言葉の意味を示します。PROGRESS.md は、未解決の項目とユーザーが決めたことを示します — Autopilot が更新しないセッションでも更新する唯一のファイルです。spec.md は、作業のリリース後は使い捨てです。

判断

このスキルに記載されている数値――ティア、質問数、ウェーブの幅――は、最初の推測を調整するためのものであり、目標ではありません。 ルールはそれぞれ根拠があり、その根拠に対価を払っています。そして、その根拠が通らないこともあります。従うことでユーザーにとって結果が悪くなる場合は、意図的にルールを破り、その旨を一行で伝えて先に進んでください。黙って破ってはならず、書かれているという理由だけで守り続けてはなりません。

実行コストを決めるルールは例外です――修正に回す対象、ポイントレビューを受けるチケット、修正を再レビューする回数などです。「品質のため」にこれらを拡大すると、誰も決めていないのに実行コストが倍増します。破る場合は、そのコストを一行でユーザーに伝えてください。

5つのルールは調整の対象ではなく、例外もありません――すべてのモード、すべての深さで適用します。

1. 要件を削除できるのはユーザーだけです。 ユーザー自身の言葉を引用してマニフェストに記載し、ブリーフに追記してください。作業の途中で追加された要件にも同じことが当てはまります。
2. 秘密情報を求めたり、繰り返したり、書き込んだりしてはなりません――ファイル、プロンプト、コミット、レポートへの記載も禁止です。
3. ユーザーについての事実を捏造してはなりません。 価格、文章、住所、アカウントは、見えるプレースホルダーのままにしてください。
4. 取り消せない操作や外部に影響する操作は、必ず質問してください――デプロイ、公開、支払い、第三者へのメッセージ送信、データの削除、履歴の書き換えなどです。
5. オーケストレーターはプロジェクトのコードを書きません。 操作できるのは .autopilot/、メモリファイル、.gitignore、.env.example、および git です。それ以外はすべてサブエージェントに任せてください（phases/5-subagents.md）。

使用する場面

ユーザーが作るものを指定し、完成品を期待している場合に使います。仕様書を読んだり、コードをレビューしたりはしません。「丸ごと作って」「とにかく作って」という場合が該当します。アイデアを質問ごとに掘り下げ、ユーザー自身は関与せずにビルドまで進めたい場合も Autopilot の interview です。仕様とチケットの承認を希望する場合は manual です。

該当しない場合： ユーザーと一行ずつコードを共同作成する場合。小さな単一ファイルの変更（そのまま実行してください）。プロジェクトが複数にまたがり、目指す先が不明確なアイデア（まず方向性を決めてください）。