Back to Details

autopilot

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Autopilot

Autopilot

Autopilot flies a dictated idea from words to a working project in one dialogue, without making the user approve each stage. Every rule it needs lives in 
phases/
and 
prompts/
; no other skill has to be installed.
The order is the product. Code is written in the second-to-last phase. Everything before it decides what to build; everything after it proves the right thing got built.
The brief is the contract, not the design. Nothing may quietly vanish: the user's words become a numbered manifest before anything else, and every phase is gated on it — what breaks naive vibecoding is a requirement that stopped existing around the third rewrite. And the brief is a silhouette: it describes the happy path and nothing underneath, so working out the empty states, failures and limits is legitimate work. How far to take it is the user's depth dial; depth that detaches from the brief is never allowed.
Autopilot 在一次对话中把用户口述的构想从文字推进为可运行的项目，无需用户逐阶段批准。它所需的全部规则都位于 
phases/
和 
prompts/
中；无需安装其他 skill。
顺序就是产品本身。 代码在倒数第二个阶段编写。此前的一切决定要构建什么；此后的一切则证明正确的东西确实被构建出来。
简报是契约，而不是设计。 任何内容都不得悄然消失：在处理其他所有事项之前，用户的原话会先变成一份编号清单，而且每个阶段都以此为门禁——让朴素 vibecoding 失效的，正是某项需求在大约第三次重写时悄然不复存在。而简报是一幅轮廓：它只描述理想路径，而不描述其下的一切，因此，梳理空状态、失败情形和限制属于正当工作。推进到何种程度由用户的 depth 调节；绝不允许出现脱离简报的 depth。

Reading this skill

阅读此 skill

This file is the orchestrator: order, gates, the rules that never lose. Each phase's rules are in its own file, read when that phase starts and not before — one file at a time, never ahead: a file opened early stays in the one context that is never refreshed for the rest of the run.
PhaseReadProduces
0 Preflight
phases/0-modes.md
, 
phases/0-preflight.md
, then 
0-memory.md
, 
phases/runtime.md
, 
0-instruments.md
mode announced, repo configured, dashboard open
1 Manifest
phases/1-manifest.md
<дата>-brief.md
, 
manifest.md
2 Briefing
phases/2-briefing.md
(+ 
2-adversarial.md
when it runs)		answers recorded into the manifest
3 Spec
phases/3-spec.md
notes.md
in existing code, 
spec.md
, the boundaries in 
interfaces.md
4 Plan
phases/4-plan.md
tickets/NN-*.md
, the plan commit
5 Build
phases/5-subagents.md
code, one commit per ticket
6 Review
phases/6-review.md
— at the first point review, and for the whole-branch review		reviewed code
8 Final
phases/8-final.md
, and 
phases/9-memory.md
before spawning		blind acceptance, memory, report
—
phases/0-resume.md
— instead of preflight, when resuming
—
phases/5-repair.md
— when a ticket comes back anything but a clean 
DONE
—
phases/9-memory.md
— also in Phase 5, when a ticket discovered something worth keeping
—
phases/rationalizations.md
— on a failed gate, on catching yourself excusing something, once before the report
After a compaction, re-read the state, not the phases: 
state.js
(it holds 
dir
and 
skillDir
), 
manifest.md
, 
interfaces.md
, and the file of the phase you are in. Nothing else.
本文件是编排器：包含执行顺序、门禁，以及绝不丢失的规则。每个阶段的规则都存放在各自的文件中，仅在该阶段开始时读取，不得提前读取——每次只读一个文件，绝不超前：过早打开的文件会留在某个上下文中，而该上下文在本次运行余下过程中都不会刷新。
阶段读取产出
0 Preflight
phases/0-modes.md
、
phases/0-preflight.md
，然后是 
0-memory.md
、
phases/runtime.md
、
0-instruments.md
宣布模式、配置仓库、打开仪表板
1 Manifest
phases/1-manifest.md
<дата>-brief.md
、
manifest.md
2 Briefing
phases/2-briefing.md
（运行时进入对抗式审查时，再读取 
phases/2-adversarial.md
）		将答案记录到清单中
3 Spec
phases/3-spec.md
在现有代码库中生成 
notes.md
、
spec.md
，以及 
interfaces.md
中的边界
4 Plan
phases/4-plan.md
tickets/NN-*.md
、计划 commit
5 Build
phases/5-subagents.md
代码，每个任务单一个 commit
6 Review
phases/6-review.md
——在首次评审节点及整分支评审时		已评审的代码
8 Final
phases/8-final.md
，派生 Subagent 前还要读取 
phases/9-memory.md
盲验收、memory、报告
—
phases/0-resume.md
——恢复运行时代替预检
—
phases/5-repair.md
——当任务单返回的结果不是明确的 
DONE
时
—
phases/9-memory.md
——也用于阶段 5，即任务单发现了值得保留的内容时
—
phases/rationalizations.md
——门禁失败、发现自己为某事辩解时，以及报告生成前一次
上下文压缩后，重新读取状态，而不是阶段文件： 
state.js
（其中保存 
dir
和 
skillDir
）、
manifest.md
、
interfaces.md
，以及当前阶段对应的文件。仅读取这些内容。

The words the user sees

用户看到的文字

Phase names here are English and never shown. In the chat, on the dashboard and in the report there is exactly one Russian word per stage:
Stage idПользователю
preflight
· 
manifest
· 
briefing
· 
spec
Подготовка · Требования · Брифинг · Спецификация
plan
· 
build
· 
review
· 
final
План · Разработка · Код-ревью · Приёмка
«Сборка» — весь прогон, поэтому пятый этап — «Разработка». Единица работы — «таск»: «задача» — это то, что поставил пользователь.
这里的阶段名称是英文，永远不会展示给用户。在聊天、仪表板和报告中，每个阶段恰好使用一个俄语词：
阶段 ID用户端
preflight
· 
manifest
· 
briefing
· 
spec
Подготовка（准备） · Требования（需求） · Брифинг（简报） · Спецификация（规格）
plan
· 
build
· 
review
· 
final
План（计划） · Разработка（开发） · Код-ревью（代码评审） · Приёмка（验收）
“Сборка”（构建）表示整次运行，因此第五阶段是**“Разработка”（开发）**。工作单元是“таск”（任务单）：用户亲自布置的才叫“задача”（任务）。

The flight

整个流程

Two dials, decided once in Phase 0 (
phases/0-modes.md
): the mode — 
full
, 
semi
(default), 
interview
, 
manual
; the depth — 
strict
, normal (default), 
deep
.
Phasefullsemiinterviewmanual
1 Manifestautoautoautoauto
2 Briefingself-briefingonly what the brief leaves openthe adversarial pass, then every forkthe same
3 Specautoautoautoshow → wait for «ок»
4 Planauto, notifyauto, stoppableauto, stoppablediscuss → wait for «ок»
5 Build · 6 Reviewautoautoautoauto
8 Finalreport + Assumptionsreportreportreport
interview
and 
manual
differ in exactly two cells — the spec gate and the plan gate.
The manifest gates run in every mode — they check the build against the user's own words, and cost the user no time:
GateAfterPasses when
G1Briefingevery requirement has a status; none 
open
without a recorded reason
G2Speczero 
open
— and an independent reader given only the brief and the spec finds nothing missing
G3Planevery 
in-spec
requirement is in a ticket and every ticket traces to one — 
ap.py check-plan
G4Finalblind acceptance against the brief, spec withheld, from a clean clone
G2 and G4 are one check at the two ends of the flight: they measure against the user's words with your paraphrase taken away. Between them everything measures against the spec, because that is the contract the executors were given. A failed gate sends its phase back to be redone.
The plan may be corrected; the brief may not. When the build proves the plan wrong, the spec is amended and a 
D##
row records what the code demonstrated (
phases/5-repair.md
) — never a way to retire a requirement or to slip in an idea.
有两个调节项，在阶段 0（
phases/0-modes.md
）一次性确定：模式——
full
、
semi
（默认）、
interview
、
manual
；深度——
strict
、normal（默认）、
deep
。
阶段fullsemiinterviewmanual
1 Manifest自动自动自动自动
2 Briefing自主简报仅处理简报尚未明确的部分先进行对抗式审查，再处理每个分叉决策同上
3 Spec自动自动自动展示 → 等待 «ок»（确定）
4 Plan自动，并通知自动，可停止自动，可停止讨论 → 等待 «ок»（确定）
5 Build · 6 Review自动自动自动自动
8 Final报告 + 假设报告报告报告
interview
与 
manual
只在两个单元格上不同——规格门禁和计划门禁。
Manifest 门禁在每种模式下都会运行——它们依据用户自己的原话检查构建，而且不会耗费用户时间：
门禁之后通过条件
G1Briefing每项需求都有状态；任何 
open
状态都必须有已记录的原因
G2Spec
open
数量为零——并且独立读者仅凭简报和规格进行审阅时，找不到任何遗漏
G3Plan每项 
in-spec
需求都对应某个任务单，且每个任务单都能追溯到一项需求——
ap.py check-plan
G4Final在干净克隆中、不提供规格的情况下，基于简报进行盲验收
G2 和 G4 是整个流程两端对同一项工作的检查：它们以用户的原话为衡量依据，同时排除执行者的转述。两者之间，一切都以规格为衡量依据，因为规格才是交给执行者的契约。门禁失败时，对应阶段会被退回重做。
计划可以修正，简报不可以。 当构建证明计划有误时，应修订规格，并由 
D##
行记录代码所证明的事实（
phases/5-repair.md
）——绝不能用它来取消某项需求或偷偷加入一个想法。

Secrets

Secrets

Binding on every phase; the phases do not restate it.
  • Never request one. Which provider and whether an account exists are questions; the key, token, password or connection string never is.
  • Redact at ingest, before anything is written — the gate in 
    phases/1-manifest.md
    . «Verbatim» always means «verbatim after redaction».
  • Refer to it by name — 
    STRIPE_SECRET_KEY
    . The user puts values into 
    .env
    themselves; 
    .env
    is ignored before the first commit; the report lists the names still empty.
  • A leaked secret is a stop condition: reported at once, in plain words, with the advice to rotate it.
以下约束对每个阶段都有效，各阶段不再重复：
  • 绝不索要 secret。 可以询问使用哪个 provider，以及用户是否已有账户；但 key、token、password 或 connection string 绝不在询问之列。
  • 在接收内容时即进行脱敏，且必须早于任何内容被写入——门禁位于 
    phases/1-manifest.md
    。“逐字保留”始终指“脱敏后逐字保留”。
  • 只按名称引用它——例如 
    STRIPE_SECRET_KEY
    。用户自行将值填入 
    .env
    ；首次 commit 前，
    .env
    会被忽略；报告会列出仍为空的名称。
  • secret 一旦泄露，就是停止条件：立即用直白语言报告，并建议轮换该 secret。

Files this skill owns

此 skill 拥有的文件

.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
│   ├── 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
├── 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/
is committed — it is the user's record of what was promised and delivered. The memory file is the project as it stands for whoever opens it next; 
docs/adr/
is why it stands that way; 
CONTEXT.md
is what its words mean; 
spec.md
is throwaway once the work ships.
.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
│   ├── 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
├── 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/
会被提交——它是用户对承诺内容和交付内容的记录。memory 文件呈现项目当前的样子，供下一个打开项目的人查看；
docs/adr/
解释项目为何成为现在的样子；
CONTEXT.md
说明项目用语的含义；
spec.md
在工作发布后即可丢弃。

Judgement

判断

Numbers in this skill — tiers, question counts, wave widths — are calibration for a first guess, never targets. The rules are arguments, each paid for, and arguments can lose: where following one would make the result worse for the user, break it deliberately, say so in one line, and carry on. Never quietly, and never keep one only because it is written down.
The rules that set the run's cost are the exception — what goes to repair, which tickets get a point review, how many times a fix is re-reviewed. Widening them «for quality» is how a run doubles its bill with nobody having decided to. Break one only by telling the user in one line what it will cost.
Five rules are not calibration and do not lose — in every mode, at every depth:
  1. A requirement is removed only by the user, in their own words, quoted into the manifest and appended to the brief. The same holds for one they add mid-flight.
  2. A secret is never requested, echoed or written — not into a file, a prompt, a commit or a report.
  3. A fact about the user is never invented. Prices, texts, addresses, accounts stay visible placeholders.
  4. An irreversible or outward-facing action is a question — deploy, publish, pay, message a third party, delete data, rewrite history.
  5. The orchestrator does not write the project's code. Its keyboard reaches 
    .autopilot/
    , the memory files, 
    .gitignore
    , 
    .env.example
    and git; everything else goes to a subagent (
    phases/5-subagents.md
    ).
此 skill 中的数字——层级、问题数量、波次宽度——只是用于首次估算的校准值，绝不是目标。规则是论据，每条都有代价，而论据也可能败下阵来：如果遵守某条规则会让结果对用户更糟，就故意破例，用一行说明，然后继续。绝不应暗自破例，也绝不能只因规则已写明就拒绝作出例外。
决定本次运行成本的那一类规则除外——哪些内容需要进入修复、哪些任务单需要重点评审、一次修复要重新评审多少次。仅仅为了“质量”而扩大这些范围，会让运行成本翻倍，却无人作出决定。只有先用一行告知用户代价，才能打破其中一条规则。
以下五条规则既非校准项，也不可让步——在每种模式、每个深度下都适用：
  1. 只有用户能取消某项需求：必须用用户自己的原话，将这项要求引用进清单并追加到简报中。用户在中途新增需求时，同样适用。
  2. 绝不请求、回显或写入 secret——不写入文件、prompt、commit 或报告。
  3. 绝不臆造关于用户的事实。 价格、文案、地址和账户均保留为可见占位符。
  4. 任何不可逆或对外的操作都必须先询问——部署、发布、付款、向第三方发消息、删除数据、重写历史。
  5. 编排器不编写项目代码。 它的键盘只能触及 
    .autopilot/
    、memory 文件、
    .gitignore
    、
    .env.example
    和 git；其他一切均交给 Subagent（
    phases/5-subagents.md
    ）。

When to use it

何时使用

The user dictates what to build and expects the finished thing; they will not read specs or review code. «Собери под ключ», "just build it". Wanting the idea taken apart question by question and the build done without them is still Autopilot — 
interview
; wanting to approve the spec and the tickets is 
manual
.
Not: co-writing code line by line with the user; a small single-file change (just do it); an idea bigger than one project whose destination is unclear (settle that first).
当用户口述要构建什么并期待完整成品，而且不会阅读规格或评审代码时，使用此 skill。“Собери под ключ”（完整交付）、“just build it”（直接做出来）都属于此类。即使用户希望通过逐个问题拆解想法，并仍期望在无需自己参与的情况下完成构建，也仍属于 Autopilot——使用 
interview
；如果用户希望批准规格和任务单，则使用 
manual
。
**不适用于：**与用户逐行共同编写代码；小型单文件改动（直接做即可）；规模超过单个项目且目标不清晰的想法（应先明确目标）。