Autopilot
自律ループ — プロジェクト自身に「完了」の意味を問いかけることで移植性を実現し、その答えが満たされるまで止まりません。
このスキルが存在することで不可能になる3つの主張：
- 「動いている」— 実際には何も実行していないのに。
- 「完了した」— 唯一の審判が作業者自身だったのに。
- 「作業した」— 何を試し、何が失敗し、なぜ失敗したかの記録がないのに。
対象は問いません。リファクタリング、移行、レポート、データセット、レンダーファーム、クラスター：以下のループはすべて同じで、チェックだけが異なります。
0. ブートストラップ — プロジェクトごとに一度
以下の <skill> はこのファイルが置かれているディレクトリです — CLIインストール後は .agents/skills/autopilot か、クローンした場所になります。すべてプロジェクトルートから実行してください。
node <skill>/scripts/discover.mjs # チェック、メモリの保存場所、危険信号を発見
node <skill>/scripts/bootstrap.mjs # 台帳がなければ作成
node <skill>/scripts/skills.mjs # スキルライブラリ — このプロジェクトのニッチを選択
node <skill>/scripts/tools.mjs # このマシンが既に到達可能なもの：MCPサーバー、プラグイン
discover はプロジェクト自身のチェックコマンドを表示します。そのコマンドが、以降のすべてのイテレーションにおける「完了」の定義です。
checks: [] と表示された場合でも、すぐに信じないでください。 発見処理はチェックを宣言しているファイルのみを読み取ります。プロジェクトの本当のチェックは、散文で書かれていることがよくあります。memoryHomes にリストされたすべてのパス、README、CI設定ファイルを、実行可能なコマンドがないか grep してください。あるプロジェクトで checks: [] の隣に CLAUDE.md があり、そこには ./tests/run_all.sh という名前があり、63個のテストを4秒で実行していました。一方、エージェントがでっち上げたチェック (node --check) は、死んでいるアプリでグリーンでした。
その検索が空で返ってきた場合にのみ、プロジェクトが本当に自動チェックを持たないことになります。これは散文、研究、運用では一般的ですが、自分の作業を自分で判断する許可ではありません。イテレーション1の前に受け入れチェックに合意し、それを目標（§1）に書き込んでください。以下のいずれもチェックになり得ます。「レビューして問題ないように見える」はチェックではありません：
| 作業 | 自分の意見ではないチェック |
|---|---|
| コード | フォアグラウンドで実行し、終了コード0を返すコマンド |
| ドキュメント | 主張ごとにソースまたはコマンドがあるリスト |
| データ | 他の誰かが再実行でき、期待される形状を返すクエリ |
| インフラ/運用 | システム自身からの観測結果（変更前と変更後） |
| 研究 | 数値を生成するクエリまたは抽出、およびそれを反証するものとして事前に登録した結果 — どちらも他の誰かが再実行可能 |
何かに触れる前に、発見された内容を読んでください：
memoryHomes— 永続的な知識がすでに存在する場所。それらのファイルを使用してください。2つ目のCHANGELOG.md、2つ目の学習ディレクトリ、2つ目のAGENTS.mdを決して作成しないでください。ある種の知識のために2つ目の保存場所を作ることは、エージェントがリポジトリを悪化させる最も一般的な方法です。signals.envFilesPresentとsignals.remote— 最初のイテレーションの前に、作業環境が本番環境を指しているかどうかを尋ねてください。リポジトリに何も書かれておらず、すべてのローカル実行が無害に見えても、そうであったプロジェクトがあります。否定されるまで「はい」と想定してください。signals.vcs—noneは元に戻す手段がないことを意味します。イテレーション1の前に入力を安全な場所にコピーし、その場所をgoal.mdに記述してください。§8の「グリーンなものをコミットする」はここでは意味がなく、まさにそのときに作業が失われます。signals.dirty— コミットされていない作業は誰かのものです。ブランチを作成し、その上に決して構築しないでください。
イテレーション1の前に自分を武装する
skills.mjs は、公開されている価値のあるスキルの短いリストで、ニッチごとにタグ付けされています。タグは語彙です — すべてのプロジェクトに any と review、そしてプロジェクトが実際に必要とするものとして web、react、db、docs、perf、a11y、mac、infra、research、design があります。
node <skill>/scripts/skills.mjs # カタログとそのタグ
node <skill>/scripts/skills.mjs --install any --dry-run # 実行される内容を確認
node <skill>/scripts/skills.mjs --install any # 常に有用なセット
node <skill>/scripts/skills.mjs --install react,perf,db # このプロジェクトのニッチ
選択してください。ため込まないでください。 インストールされたすべてのスキルの説明は、毎ターン読み込まれます。100個のスキルは100の能力ではなく、より小さなウィンドウと、内容を読み飛ばすモデルを意味します。
インストールは、あなたの権限でサードパーティのコードを実行することです。そのため、それは告知された行為です：最初に --dry-run を実行し、追加しようとしているものとその理由を説明してからインストールしてください。プロジェクトがカタログのどのニッチにも一致しない場合、any だけが正しい答えです。そして、カタログが薄いニッチ（研究、インフラ、データは現在薄いです）のエントリポイントが find-skills です。
そして、費やしたものを測定してください。 skill-cleaner は any セットに付属しており、「選択してください。ため込まないでください」というアドバイスを実践するためのものです：
node --experimental-strip-types <skills-root>/skill-cleaner/scripts/skill-cleaner.ts \
--root .agents/skills --root-only --no-logs
インストールされた説明が占有する予算、重複（1つの質問に答える2つのスキル — このループが追跡する欠陥を1段階上で）、および圧縮する価値のある長い説明を報告します。それに基づいて行動してください：このプロジェクトが使用しないものをアンインストールし、両方を保持するのではなく重複をマージしてください。読んだだけで無視する監査は、監査がないのと同じコンテキストを消費します。
スキルは半分 — 残りの半分は到達可能性
skills.mjs はエージェントが知っていることを示します。tools.mjs はエージェントが触れることができるもの、つまり、読み取り方法を知っている設定ファイルで見つけるMCPサーバー、さらに多くのものを運ぶプラグイン、そしてディスク上からはわからないものを示します。空の結果は「これらのファイルにはない」を意味し、「このマシン上にない」を決して意味しません。
node <skill>/scripts/tools.mjs
不足している能力は、目標を狭める理由ではありません。 それははしごです — すでに到達可能 → アプリ自身のCLI → 公開サーバー → コネクタ（§6で保留） → new-mcp.mjs で自分で書く。各段、それぞれのコスト、およびそれぞれの落とし穴は references/tooling.md にあります。何かを構築する前にそれを読んでください。ここからは見えない2つの失敗を防ぐからです：能力がすでに設定されているのに不足していると判断すること、そして何かがすでに答えている質問に対する2つ目の答えを構築すること。
よくある落とし穴： ほとんどのハーネスは起動時にMCP設定を読み取るため、実行中に書かれたサーバーは通常、それを書いたセッションからは見えません。そのため、スキャフォールドは同時にCLIでもあります — node server.mjs --call <tool> '<json>'、同じハンドラ。今はその形式を使用し、次のセッションにサーバーを任せてください。「再起動後に続行」は、ファイルを保持したまま停滞するループです。
その後、常に：ここで学んだことは、それ自身のスキル（§5）となり、ループによって書かれ、同じセッションで使用されます。そして、不足していた能力は、それ自身のツールとなり、同じ方法で使用されます。
1. 目標 — ループが実行されるもの
イテレーション1の前に、1つの反証可能な文と2～5つの完了基準を書き留めてください。goal.md に、または発見処理がすでに保持していると判明した場所に。
- 反証可能：「Xをより良くする」は反証可能ではありません。「お金を使うすべてのパスが明示的なタップの背後にあり、それぞれが型または失敗するテストによって保持されている」は反証可能です。
- 各基準は、あなた以外の誰かがチェック可能でなければなりません — §0と同じ基準です。あなただけが確認できる基準は基準ではありません。書き換えてください。
- 未知のものは、それ自体の基準として許可されます：「Nが原因かどうかを知っている」は、研究の正当な完了基準です。
- 大きな目標は小さな目標を通じて達成され、基準はまさにその分解です — それぞれが、それ自体で着地、チェック、検証できるスライスです。1つのイテレーションには大きすぎる基準は、それ自身の基準に分割されます。深さは問題ありません。すべてのレベルで同じ基準（あなた以外の誰かがチェック可能）を維持します。反証可能でなくなったレベルは、計画であり、基準ではありません。
- 不足している能力は基準であり、迂回路ではありません。 「ループはXをヘッドレスで駆動でき、1往復で証明される」は、それがアンブロックする作業の隣のテーブル（
references/tooling.md）に配置されます。書き留められれば、ツールの構築は範囲が定められ、その欠如は可視化されます。書き留められなければ、基準を生み出さず、進捗として読み取られる午後になります。 - 誰もあなたに目標を与えなかった場合 — 「продовжуй」（続けて）以外に何もない場合 — 最初のイテレーションの唯一の出力は、提案された
goal.mdと人間への質問です。あなたが作成し、その後満たした基準は、上記の主張#2であり、チェックリストを身に着けています。 goal.mdはまた、固定された状態を保持します：チェックコマンド、そのベースライン出力、本番環境に関する質問への回答、ブランチ（または入力のコピーの場所）、およびインストールされたスキル。再導出しなければならない再開は、再開ではありません。
その後、ループはすべての基準が満たされ、かつ検証されるまで実行されます。 モデルが完了したと感じるまででもなく、批評家が沈黙するまででもありません（彼らは決して沈黙しません）。各イテレーションは、goal.md にどの基準が動き、何がそれを証明するかをマークして終了します。
ループを早期に停止できるのは、§6（質問）、§7（スラッシング）、§8（コンテキスト）の理由のみです。
2. イテレーション
1イテレーション = 1つの着地した変更。チェックされ、検証され、記録されます。1ファイルではなく、1ターンでもありません。
選択してください。 目標の未達成基準から。複数が未達成の場合、失敗が最も多くの他の作業を無効にするものを取ってください — リスク×リーチで順序付けられ、容易さではありません。
短くする前に理解してください。 実際のものを端から端までトレースしてください。その後、新しいものを構築する前に、それがすでに存在するかどうかを尋ねてください — references/premise-check.md を参照してください。このスキルの中で最も収穫の高い習慣であり、学ぶのに最も時間がかかったものです。
構築してください。 実際に正しい最小のもの。根本原因、リクエストが名前付けている症状ではありません：最初に同じ形状を持つ他のすべての場所を見つけ、それらすべてが通過する場所で修正してください。
証明してください。 発見されたチェックを、フォアグラウンドで、それを実行したシェルで終了コードを読み取りながら実行してください。または、さらに良いのは、サマリーを書いていないものがあなたのためにそれを読み取ることです：
node <skill>/scripts/prove.mjs --record -- npm run verify # チェック、その真のステータス、goal.mdへ
node <skill>/scripts/prove.mjs --times 3 -- <check> # 自分自身と矛盾するチェックは不安定
Prove と Verify は、モデルがナレーションできる2つのステップです — 他のステップはファイル、コミット、または差分を残します。一方、「チェックは合格した」と「レビュアーが同意した」は、どちらもそれらが真実であってほしいと願うコンテキストによって書かれたテキストでした。ランナーは最初の質問に答えます：それはシェルなしで起動するため、報告されるステータスは子プロセス自身のものです。自身の npm スクリプトにパイプを含むチェックを拒否します（`