/autopilot

name: autopilot
description: Builds an app, site, bot, or feature end-to-end from a dictated idea — requirements, briefing, spec, tickets, subagents, review, acceptance — with a live dashboard, for users who expect a finished result without reviewing specs or code. Starts only on /autopilot; a bare /autopilot resumes an interrupted run.
disable-model-invocation: true
argument-hint: "[full|semi|interview|manual] [strict|deep] что нужно построить или путь к brief.md"
metadata:
  version: "2.1.0"

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](phases/0-modes.md) dial; depth that **detaches** from the brief is never allowed.

Reading this 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.

| Phase | Read | Produces | |---|---|---| | 0 Preflight | `phases/0-modes.md`, `phases/0-preflight.md`, then `0-memory.md`, `0-instruments.md` | mode announced, repo configured, dashboard open, `carried.md` after a landed run | | 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, progress file, 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`, `carried.md` if the run has one, and the file of the phase you are in. Nothing else.

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` | План · Разработка · Код-ревью · Приёмка |

**«Сборка» — весь прогон**, поэтому пятый этап — «Разработка». **Единица работы — «таск»**: «задача» — это то, что поставил пользователь.

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`.

| Phase | full | semi | interview | manual | |---|---|---|---|---| | 1 Manifest | auto | auto | auto | auto | | 2 Briefing | self-briefing | only what the brief leaves open | the adversarial pass, then every fork | the same | | 3 Spec | auto | auto | auto | show → wait for «ок» | | 4 Plan | auto, notify | auto, stoppable | auto, stoppable | discuss → wait for «ок» | | 5 Build · 6 Review | auto | auto | auto | auto | | 8 Final | report + Assumptions | report | report | report |

`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:

| Gate | After | Passes when | |---|---|---| | **G1** | Briefing | every requirement has a status; none `open` without a recorded reason | | **G2** | Spec | zero `open` — **and an independent reader given only the brief and the spec finds nothing missing** | | **G3** | Plan | every `in-spec` requirement is in a ticket and every ticket traces to one — `ap.py check-plan` | | **G4** | Final | blind 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.

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`. «Verba