Autopilot skill
Orchestrator skill: from an idea the agent writes requirements and a spec, splits work into tasks, builds the project, checks it
- 594 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- In `full` mode the agent asks no questions, runs commands, installs dependencies and makes commits on its own.
- Parallel subagents write code into the repository and you do not review each task diff.
- A build can create a repository and spends paid tokens of several models.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/autopilotDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- In `full` mode the agent asks no questions, runs commands, installs dependencies and makes commits on its own.
- Parallel subagents write code into the repository and you do not review each task diff.
- A build can create a repository and spends paid tokens of several models.
This is third-party code. Review the repository files before installing.
What it does
Autopilot is a skill for Claude Code, Cursor and Codex that takes a project from an idea description to a working result in one dialogue. It starts only on the `/autopilot` command, splits the text into numbered requirements, asks questions at forks, writes a spec, cuts the work into tasks and hands them to separate subagents, one commit per task. At the end a separate agent receives the original text and the finished project without the spec and checks the result against the user's words. Build progress shows on the `.autopilot/dashboard.html` panel, which opens by itself, with stages named in Russian: preparation, requirements, briefing, specification, plan, development, code review, acceptance. There are four modes: `full`, `semi` by default, `interview` and `manual`. Depth of elaboration is set with the words `strict` and `deep`.
Who it is for. Entrepreneurs and vibe coders who describe a bot, site or service in words and expect a finished project without reading specs or code.
Good fit when
- The idea is described on one page and should become a Telegram bot that puts requests into a spreadsheet.
- The brief is large, so it goes into `brief.md` and `/autopilot brief.md` starts the build.
- A session broke off mid-build and `/autopilot` with no words continues from the saved state.
- The client wants to approve the spec and the task list personally, so `manual` mode is switched on.
Not a fit when
- The change fits in one file and it is simpler to ask the agent directly.
- The code is written together with the agent line by line.
- The goal is bigger than one project and still unclear, so it has to be formulated first.
Example request
/autopilot full a Telegram bot for booking manicures: the client picks a time, the technician gets a notification, bookings land in a spreadsheet.Limitations
A build spends many tokens: each task is done by a separate subagent, and the whole branch review and acceptance come at the end. The skill creates a repository, writes code and makes commits, and asks permission before payments, messages to people and data deletion. One agent writes about 3,000 lines, so a project is split into at most 12 tasks and a bigger one goes into a second run. Once per build the skill contacts GitHub to check the version, which the `AUTOPILOT_NO_UPDATE_CHECK=1` variable turns off. Updating works only through `npx skills update autopilot -g`, and the session must be restarted afterwards.
How to disable. Remove the skill with `npx skills remove autopilot -g`. Keep the `.autopilot/` folder and `AGENTS.md` in finished projects or delete them by hand.
FAQ
How do I install Autopilot in Claude Code?
Run `npx skills add nick-vels/skills --skill autopilot -a claude-code -g -y` and restart the session, because skills load at startup. For Cursor or Codex change the value of the `-a` flag.
How do the modes differ?
`full` asks nothing, `semi` asks only about forks, `interview` goes through every fork and the weak spots of the idea, and `manual` also waits for your OK on the spec and the task list.
What does the progress panel show?
What is happening now, how many tasks are done, every requirement as a quote from the brief with its status, checks and keys for `.env`. A blue header means the build is running, orange means it waits for you, green means it is done.
Does Autopilot store my keys?
No, it does not ask for keys or passwords. If a key lands in the chat, a filter replaces it with `[REDACTED:...]` before anything is written to a file, and the key itself is better reissued.
How do I resume an interrupted build?
Type `/autopilot` with no words. The skill restores the state from files in `.autopilot/` and continues from where it stopped.
Discussion
No questions or reviews yet.
Related
SkillsAn autonomous iteration skill for agents: modify, verify, revert failed changes, and repeat the loop toward a target metric
A skill that interviews you and writes requirements.md, design.md and tasks.md so Claude Code and Cursor work from one plan
A Grid Dynamics plugin that loads a team's shared engineering standards, architecture and workflows into a coding agent session
The /improve skill: a strong model audits a repository and writes self-contained fix plans, and you hand the execution to a cheaper model
A CLI that guides AI coding from idea to review through requirements, plan, code and checks and keeps traces in the repo.
A spec-driven dev process for agents: gated phases, context memory, and a set of agents and skills
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Autopilot (this card) | no | 594 | |
| Spec Kit | no | 148,171 | a GitHub CLI that installs spec-driven commands and leaves the steps to you; Autopilot runs the whole cycle itself and checks the result with blind acceptance |
| Spec-Driven Develop | no | 993 | a three-skill plugin for large tasks in an existing project; Autopilot starts with questions about the idea and keeps a progress panel |
README in short
The description exists in English and Russian. It covers four modes, three depth levels, the phases from preflight to acceptance, the rules for splitting into tasks and a list of what Autopilot never does, such as dropping requirements without you or asking for keys.
README badge
Original SKILL.md
--- 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.2.1" --- # 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