autopilot

Autopilot

Overview

Autopilot flies a dictated idea from words to a working project in one dialogue, without making the user approve each stage. It is self-contained: every rule it needs lives in phases/. No other skill has to be installed.

Two ideas carry the whole design.

The order is the product. Code is written in the second-to-last phase. Everything before it exists to decide what to build, and everything after it exists to prove the right thing got built.

The brief is the contract, not the design. Two obligations follow from it, and they pull in opposite directions on purpose.

Nothing may quietly vanish. The user's original words become a numbered manifest before anything else happens, and every phase is gated on it. What breaks naive vibecoding is not bad code — it is a requirement that stopped existing somewhere around the third rewrite.

The brief is not the design. It is a silhouette: it describes the happy path and nothing underneath — no empty states, no failures, no interruptions, no limits. Working those out is legitimate work, not scope creep, and it is where much of the value of this process comes from. How far to take it is the user's dial, set by the depth parameter. What is never allowed at any setting is depth that detaches from the brief.

Reading this skill

This file is the orchestrator: modes, phase order, gates. The rules for each phase live in phases/ and are read at the moment that phase starts, not before — that is what keeps the working context small.

The unit of loading is the file, not the section. «Read only the block at the top» is not a mechanism — a read pulls in the whole file — so anything needed by one phase and not another is its own file. That is why Phase 0's share of the instruments and of the project memory sit in phases/0-instruments.md and phases/0-memory.md rather than at the top of the phase-7 and phase-9 files: taking the whole of both would cost thirty-eight thousand characters in the one context that is never refreshed, to answer questions that arrive four phases later.

Phase	Read	Produces
0 Preflight	phases/0-preflight.md, then 0-instruments.md and 0-memory.md	repo configured, .autopilot/ created
1 Manifest	phases/1-manifest.md	brief.md, manifest.md
2 Briefing	phases/2-briefing.md	answers recorded into the manifest
3 Spec	phases/3-spec.md	spec.md
4 Plan	phases/4-plan.md	tickets/NN-*.md (or none — see tiers), interfaces.md seeded
5 Subagents	phases/5-subagents.md	code, commits, interfaces.md grown
6 Review	phases/6-review.md	per-ticket review
7 Instruments	phases/7-instruments.md — in Phase 4, when the tickets are cut	state.js, dashboard.html (opened for the user)
8 Final	phases/8-final.md	blind acceptance, final report
9 Memory	phases/9-memory.md — in Phase 5 and Phase 8	CLAUDE.md / AGENTS.md, docs/adr/ — the project as the next session will find it

The words the user sees

The phases have English names in this file and the user never sees them. In the chat, on the dashboard and in the final report there is exactly one Russian word per stage, and it is this one. Two vocabularies for one process is how a person reads the README and then cannot find any of it on the screen.

Phase	stages[].id	Пользователю
0 Preflight	preflight	Подготовка
1 Manifest	manifest	Требования
2 Briefing	briefing	Брифинг
3 Spec	spec	Спецификация
4 Plan	plan	План
5 Subagents	build	Разработка
6 Review	review	Код-ревью
8 Final	final	Приёмка

Two rules hold this together:

• «Сборка» — это весь прогон, а не один этап. «Сборка идёт», «сборка прервалась», «продолжи сборку» — про процесс целиком. Поэтому пятый этап называется «Разработка»: иначе одно слово означает и часть, и целое. И «сборка» в смысле npm run build — тоже не он.
• Единица работы — «таск». Не «задача», не «тикет», не «issue». «Задача» — это то, что поставил пользователь (бриф); одно слово на две разные вещи ломает и отчёт, и дашборд.

Phases 7 and 9 are not sequential, and each is split in two along the line where it is read. The instruments are raised in Phase 0 from phases/0-instruments.md — template, starting state, the update ritual — and phases/7-instruments.md is opened only when the tickets are cut. The project memory is raised in Phase 0 from phases/0-memory.md — which file, and the skeleton — and phases/9-memory.md is opened when the build discovers something and again in Phase 8, where a subagent writes the full description from the finished code.

Modes

Everything typed after /autopilot splits into four parts: the mode (optional bare word — full, semi, interview, manual), the depth (optional bare word — strict, deep), the finish (optional bare word — polish), and the brief (everything else). No dashes on any parameter. Text that is not a recognised parameter is always brief.

/autopilot full deep интернет-магазин керамики — full mode, deep elaboration. Order does not matter; all three parameters are optional and independent.

Mode	Triggers	Human gates
full — полный автомат	/autopilot full, «полный автомат», «полностью сам», «ничего не спрашивай», "fully automatic", "don't ask me anything"	none
semi — полуавтомат (default)	/autopilot semi, «полуавтомат», nothing specified	questions, on genuine forks only
interview — режим интервью	/autopilot interview, «режим интервью», «погриль меня», «допроси», «задай все вопросы», «разбери задачу со мной», "grill me", "interview me", "ask me everything"	questions, all of them
manual — ручной	/autopilot manual, «ручной режим», «согласовывай каждый шаг», "approve every step"	the same questions + spec + tickets

Why four and not three. A mode decides two separate things: how much the user is asked about the product, and how much of the process they approve. Those are different kinds of their time — answering questions is the work, approving artifacts is control over how the work runs — and wanting one without the other is the ordinary case, not an exotic one. interview is that case: take the задачу apart with me question by question, then build the rest yourself. manual is interview plus the two artifact gates, and nothing else.

• Announce the resolved mode and offer the others, once, before Phase 1. The user must never discover the mode by noticing questions that did or did not arrive — and they cannot ask for a mode they do not know exists. In a chat client there is no --help to read: this block is the only place the dials are ever named, so it is not optional.

  Режим: полуавтомат · глубина: обычная — спрошу только то, что в задаче не определено, дальше соберу сам.
  Дашборд открыл — обновляется сам.
  Память проекта — AGENTS.md (+ CLAUDE.md со ссылкой). Скажи, если нужен другой.
  
  Можно переключить в любой момент, просто скажи:
  • «полный автомат» — не спрашиваю вообще ничего
  • «погриль меня» — разберу задачу вопросами до конца, дальше соберу сам
  • «ручной режим» — то же плюс согласуешь спецификацию и список тасков
  • «строго по брифу» / «проработай глубоко» — меньше или больше проработки сверх сказанного
  • «вылижи» — в конце сравню с эталоном и доведу; дольше и дороже
  

  With polish on, the first line names it and its ceiling: «Режим: полуавтомат · глубина: обычная · доводка: до трёх кругов».

  One short block, once, at the start. It is a hint, not a question — say it and go straight into Phase 1; waiting for a reply to it is exactly the pause this skill exists to remove. Do not repeat it later, do not restate it after a mid-run switch (one line is enough there: «Понял, дальше ручной режим»).

• Ambiguity resolves to semi. A mode word contradicting the rest of the sentence («ручной режим, но не спрашивай») → the explicit mode word wins; two mode words → ask which one, in one line.

• The mode can be switched mid-run («переключись в ручной») — it applies from the next phase onward. Phases already passed are not replayed.

• Extra instructions in the brief (stack, language, budget, «без базы данных», deadline) are manifest requirements like any other. They constrain the build; they never replace a phase.

• No mode removes the manifest gates or the safety gates. Irreversible or outward-facing actions — deploy, publish, pay, send messages to third parties, delete data, rewrite git history — stay a question in all four modes, including full.

Depth

How far past the brief's own words the spec is allowed to go. The mode decides how much the user is asked; depth decides how much is worked out for them. They are independent.

Depth	Triggers	Deepening a requirement (R##.n)	New capabilities (A##)
strict	/autopilot strict, «строго по брифу», «только то, что сказал», «ничего не добавляй», "strictly as written", "nothing extra"	only what the requirement cannot work without	not allowed
normal (default)	nothing specified	freely, by judgement — as much as the feature warrants	allowed, with a parent, within proportion
deep	/autopilot deep, «проработай глубоко», «максимальная глубина», «продумай за меня», "go deep", "think it through"	the full depth pass, every dimension, every requirement	actively encouraged, same two limits

• Default is normal, and normal means permitted. The agent elaborates where elaboration obviously helps and does not chase every edge of every requirement. This is the setting most briefs should run on.
• strict does not mean careless. Errors and empty states are still handled — a build that crashes on bad input does not satisfy the requirement it was written for. What strict removes is anything the user did not ask for: no extra capabilities, no anticipating needs, no "пока я тут, добавлю".
• deep does not lift the attachment rules. Every A## still names its parent requirement; the proportion limit still holds. deep buys thoroughness, never a different project.
• deep also turns on the adversarial pass — the premortem over the brief in phases/2-briefing.md, which asks where the idea itself comes apart rather than where a requirement is underspecified. It runs at deep in every mode, and in interview and manual at every depth, because taking the задачу apart is what those modes are for. The mode then decides what happens to what it finds: a question, or an ASSUMPTION decided for the user.
• Depth is announced with the mode, in the same opening block: «Режим: полуавтомат · глубина: максимальная».
• Depth can be changed mid-run («поменьше отсебятины», «продумай глубже») — applies from the next phase. Already-written spec sections are not retroactively trimmed unless the user asks.

The rules for each level live in phases/3-spec.md.

Polish — доводка

Off by default. One bare word turns it on, and it is the only parameter that costs the user real money and real time rather than just attention.

	Triggers	What it adds
polish	/autopilot polish, «вылижи», «доведи до идеала», «сравни с эталоном», «не останавливайся, пока не будет как надо», «бюджет не важен, важен результат»	after the blind acceptance, up to three rounds of comparing the running build against the user's own reference and fixing the differences

Why this is a third dial and not a value of depth. Depth decides how much is worked out before the code exists; polish decides how much is corrected after it does. A strict brief can deserve a flawless finish, and a deep spec can be right the first time. Folding one into the other would tie two independent decisions to one word, which is the same argument that gives this skill four modes instead of three.

Two things are decided here; everything else — the critic's prompt, the filter, the stop conditions, the bookkeeping — is in phases/polish.md, read only when the parameter is on.

• It measures against a reference, never against taste. No reference.md with something comparable in it → the loop says so in one line and does not run. A critic with nothing to compare against invents a standard, and the run then pays for chasing it.
• Its findings become tickets, cut and flown and reviewed and committed like any others. Nothing about доводка bypasses Phase 6 or the green suite; it is more work of the same kind, not a different kind of work.

Announced with the mode and depth in the opening block, ceiling named: «доводка: до трёх кругов».

When to Use

• User dictates what to build and expects the finished thing, not a collaboration on process.
• User is non-technical: will not read specs, judge ticket granularity, or review code.
• "Собери под ключ", "just build it", "не задавай лишних вопросов".
• User wants the idea taken apart with them question by question, and the build done without them — that is interview mode, still Autopilot.
• User wants to approve the spec and the tickets but not to run the pipeline by hand — that is manual mode, still Autopilot.

When NOT to use: the user wants to co-author the code itself line by line (work with them directly); the task is a small single-file change (just do it); the idea is bigger than one project and its destination is unclear (settle the destination first, then return here).

The flight

Phase	full	semi (default)	interview	manual
0 Preflight	auto	auto	auto	auto
1 Manifest	auto	auto	auto	auto
2 Briefing	skipped → self-briefing	only what the brief leaves open — sometimes none	the adversarial pass, then every fork it opens	the same
3 Spec	auto	auto	auto	show → wait for explicit «ок»
4 Plan	auto, notify only	auto, stoppable	auto, stoppable	discuss → wait for explicit «ок»
5 Subagents	auto	auto	auto	auto
6 Review	auto	auto	auto	auto
8 Final	report + Assumptions	report	report	report

polish adds a step inside Phase 8, in every mode — the доводка loop, between the blind acceptance and the report. It changes no cell above: it asks the user nothing, and it approves nothing with them.

interview and manual differ in exactly two cells — the spec gate and the plan gate. If you find yourself treating them differently anywhere else, one of them is wrong.

The manifest gates run in every mode. They are checks against the user's own words, not requests for the user's time — no mode buys the right to skip them.

Gate	After phase	Condition to pass
G1	2 Briefing	every requirement has a status; none left open

...