Autopilot by nick-vels: a Claude Code, Cursor and Codex skill that turns a written brief into a built project

What Autopilot solves, and for whom

Most agent workflows assume you will supervise. You read the plan, edit the task list, reject a file, ask for a different library. Autopilot inverts that. The README states the premise plainly: tell it in words what needs to be built and get a finished project, and you do not need to read the specification, evaluate the tasks or understand the code.

The target reader is someone with a project-shaped idea and no appetite for the intermediate artifacts. The README's own examples are small commercial jobs: a Telegram bot that takes repair requests and writes them into a Google Sheet, a landing page for pizza delivery, a booking bot for a manicure salon, a CRM for a car service. These are projects where the specification has no independent value once the thing runs.

That is also the boundary. If your organisation treats the specification as a deliverable, or if a reviewer must sign off before implementation, Autopilot's default behaviour is aimed at the wrong person. The manual mode exists for that case, but it is a mode you have to ask for, not the default.

How the skill runs: interview, spec, tasks, build, check

The pipeline is stated in the repository description and expanded in the README. Autopilot asks 5 to 8 questions, or as the README puts it, questions exactly where the idea has forks. It then writes the specification, thinks through what you did not mention, splits the work into tasks and assembles the project. The README says the agent works on its own and needs nothing else installed.

The part that distinguishes it from a plain prompt is the closing loop. Your brief is copied into a .autopilot/ directory, and the README says the result is checked against that copy at the end. Your original file is left untouched. So the acceptance criterion is not the agent's own summary of what it did, but the text you supplied before anything was built.

Two independent controls sit on top of that. Mode decides how much you are asked; depth decides how much is invented for you. Strict depth means only what you wrote, with no features added even good ones, though the README notes error and empty states are still handled because a requirement without them does not work. The default, ordinary depth, fills gaps that would visibly spoil the result and, per the README, attaches its additions to something you asked for.

Progress is reported through a single HTML dashboard that the agent opens by itself at the start of a build. The README describes it as one file with no server to find or start, live timers, self-refreshing page and no internet connection required. The screenshots in assets/ show three panels: metrics (project progress, brief coverage, time, debt), stages (the full cycle from preparation to acceptance) and build progress (tasks grouped into waves, showing what runs in parallel).

Installing the skill and running a first brief

Everything goes through the skills installer, which the README invokes with npx. The interactive form asks which skills to install and for which agents; you confirm and that is it. Node.js is required for npx, plus one supported agent. The README points at a list of more than 70 supported agents maintained in the vercel-labs/skills repository.

npx skills add nick-vels/skills

The README also documents a non-interactive form with four flags. The --skill flag limits the install to Autopilot, -a names the agent, -g makes the skill available in every project rather than the current folder, and -y suppresses the prompts.

npx skills add nick-vels/skills --skill autopilot -a claude-code -g -y

If you would rather not touch a terminal, the README suggests pasting an instruction block into the agent itself, asking it to run the npx command with your agent name substituted, to give you a Node.js download link if npx is missing, and to install nothing else. The README notes that skills are read at start, so the agent session has to be restarted afterwards. It also distinguishes this first-install command from the separate update and removal command, which the README links to but the excerpt here does not reproduce.

With the skill installed, open the agent in the folder for the new project and pass the idea. The README shows both the explicit slash form and the plain-language form, where the agent is expected to recognise that Autopilot applies.

/autopilot Хочу телеграм-бота, который принимает заявки на ремонт техники
и складывает их в Google-таблицу

For anything substantial the README recommends writing the description to a file first, any name you like, and pointing the command at it. Extra words after the path are folded into the same task.

/autopilot deep docs/идея.md только без оплаты картой

After that you answer the opening questions, the agent states which mode it is in, opens the dashboard and records project memory in AGENTS.md with a CLAUDE.md that links to it. The README says you can ask for a different memory file at that point.

Mode and depth are two dials, not one

The README separates participation from invention, and the distinction is worth taking seriously. Mode answers how many questions you field. Full autopilot asks nothing and closes with a list of decisions taken on your behalf. Semi-autopilot is the default: usually 2 to 8 questions, none at all if the brief is unambiguous, as many as needed if the task is large and rough. Manual mode asks its questions and then waits for your approval of the specification and of the task list.

Depth answers how far the agent goes past your words. Strict means only what you wrote. Ordinary, the default, fills gaps that would clearly damage the result. The README also mentions a deep setting, triggered by the word deep or the phrase about working through thoroughly, which increases how much is developed beyond what you said.

Two things hold across all modes. The agent asks before anything irreversible: publication, payment, sending messages, deleting data. And no mode turns off the final check against your original task. That second guarantee is the more interesting one, because it is the only mechanism in the design that does not depend on your attention.

The mode keywords are written without hyphens: full, semi, manual. Mode can be changed mid-run by saying so, and the README says the change applies from the next stage rather than retroactively.

Where the approach is the wrong tool

The clearest limitation is the one the design accepts on purpose. In full autopilot you do not see the specification before code exists. The decisions the agent made for you arrive as a list at the end, after the work is done. If a wrong assumption is expensive to unwind, that ordering is backwards, and the fix is manual mode rather than any flag.

Strict depth has its own trap. It sounds like the safe setting, and for scope it is. But the README admits it is not absolute: error handling and empty states are still implemented even under strict, because a requirement without them does not function. So strict is not a promise that nothing exists beyond your text. It is a promise about features.

The dashboard is a progress surface, not a control surface. The README describes it as a static HTML file that refreshes itself with no internet needed, which is what makes it convenient and also what it is not: there is no documented way to approve, reject or edit anything from that page. If you want to intervene, you intervene in the chat.

And the whole thing presumes an agent that reads skills at session start. The README states this directly, which means the install is not finished until the agent is restarted. Anyone who installs and immediately types the command into the same session will see nothing happen and conclude the tool is broken.

How it differs from planning-first agent frameworks

The natural comparison is a spec-driven agent workflow, where the specification is a checked-in artifact and implementation is gated on a human reading it. Those tools optimise for reviewability: the plan is the product of the first phase, and you approve it before any code is written. Autopilot optimises for the opposite. The README's framing is that you should not have to read the specification at all, and its manual mode is offered as an exception rather than the shape of the tool.

The second difference is the acceptance test. A planning-first workflow usually verifies against the plan it just generated, which is circular in a quiet way: the agent checks its work against its own interpretation. Autopilot copies your brief into .autopilot/ before building and checks the result against that copy. Your original file is not modified. That is a small architectural decision with real consequences, because it makes the yardstick something you wrote rather than something the agent wrote.

The third is the dashboard. Most agent tooling reports through the terminal or through files you have to open. Autopilot opens a single self-contained HTML page in the browser and keeps it current without a server or a network connection. It is a presentation choice, and it is the reason the README can claim you always see what is happening without learning any commands.

Licence, maintenance and what upgrading costs you

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own project, and it says nothing about the licence of whatever the agent generates for you, which is a separate question the repository does not address here.

On maintenance: the repository is not archived, and the last push was on 2026-08-19. Two releases are listed, v1.0.0 on 2026-08-08 and v1.0.1 on 2026-08-18, both labelled Autopilot. The README does not document a rollback path, and it does not describe what changes between skill versions. Since the skill is installed through the skills installer rather than a package manager with lockfile semantics, the practical upgrade question is whether a newer Autopilot changes how it interprets an existing project's memory files. The README mentions AGENTS.md and CLAUDE.md as project memory but does not describe a migration story for them.

The repository layout includes a skills-lock.json at the top level alongside .agents/, .claude/, skills/, docs/ and tools/. The README does not explain what the lock file pins or whether it protects you from a surprise update, so treat that as something to inspect in the repository rather than something documented.

Editorial conclusion

Autopilot fits people who can describe a project in prose but do not want to read a specification, approve a task list or open an editor. It is the wrong tool if you need to review the spec before code exists, or if the work depends on credentials, payments or production data, because no mode removes the confirmation step before irreversible actions. Verify first that your agent is among those the installer supports, that Node.js is available for npx, and that the copy of your brief under .autopilot/ is the one you want the final check run against.

Frequently asked questions

Official sources

1. License: MIT
2. nick-vels/skills on GitHub
3. Project website
4. README
5. Releases