Agent skill

Autopilot End-to-End Builder

by nick-vels in nick-vels/skills

Builds an app, site, bot or feature from a spoken idea through requirements, spec, tickets, subagent work, review and acceptance, with a live progress dashboard.

MITAuto-check: notesAgent Workflows

Install Autopilot End-to-End Builder

skills CLI
$ npx skills add nick-vels/skills --skill autopilot -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install nick-vels/skills autopilot --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/autopilot .claude/skills/autopilot && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
autopilot
GitHub stars
414
Token cost
~2.5k tokens
SKILL.md length
1,207 words
Files
24
Skills in repo
1
Repo updated
First seen
Licence
MIT

At a glance

Builds an app, site, bot or feature from a spoken idea through requirements, spec, tickets, subagent work, review and acceptance, with a live progress dashboard.

  • Works in 5 steps: A requirement is removed only by the… → A secret is never requested, echoed or… → A fact about the user is never invented.… → …
  • Building a complete app or feature from a single dictated idea
  • SKILL.md covers Reading this skill, The words the user sees, The flight and Secrets, plus 3 more sections
  • Needs STRIPE_SECRET_KEY

What it does

Starts only when explicitly invoked, carrying a dictated idea through requirements, a briefing, a formal spec, a build plan, subagent-driven implementation, review and final acceptance in one continuous run, without stopping for approval at every stage. Every rule lives in numbered phase files under `phases/` and prompt files under `prompts/`, so no other skill needs to be installed alongside it, and a bare re-invocation resumes an interrupted run instead of starting over.

Treats the user's own words as a contract rather than a design: everything they said becomes a numbered manifest before anything else happens, and every later phase checks its work against that manifest so a requirement can't quietly disappear partway through. The brief is also described as a silhouette that covers only the happy path, leaving empty states, failures and limits as legitimate design work the skill still has to think through, bounded by a user-chosen depth setting that is never allowed to detach from the original brief.

Each phase file is read only when that phase actually starts, never ahead of time, because a file opened early would sit in context that never gets refreshed again for the rest of the run. Code itself is written second-to-last, in the build phase; everything before it decides what to build, and everything after it proves the right thing was built.

When your agent uses it

  • Building a complete app or feature from a single dictated idea
  • Resuming an autopilot run that was interrupted partway through
  • Letting an agent handle requirements through review without stage-by-stage approval
  • Turning a rough idea into a numbered, checkable requirements manifest

Example prompts

  • “/autopilot build a Telegram bot that reminds me to drink water every two hours.”
  • “/autopilot resume my interrupted project from yesterday.”
  • “/autopilot add a waitlist signup feature to my landing page site.”

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  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…
  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…

What it can do on your machine

Read from SKILL.md and the folder at commit 326c6ea. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • STRIPE_SECRET_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Autopilot End-to-End Builder loads about 2.5k tokens when it runs. Until then it costs about 80 tokens; SKILL.md has 1,207 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~80
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:84
    _SECRET_KEY`. The user puts values into `.env` themselves; `.env` is ignored before the first commit; the report lists t

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from nick-vels/skills at commit 326c6ea, republished under its MIT licence (© nick-vels). 1,207 words, ~2,468 tokens.

Download SKILL.mdSave it as .claude/skills/autopilot/SKILL.md (or your agent's skills folder). This skill also uses 23 other files; get the full folder from GitHub.
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 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.

PhaseReadProduces
0 Preflightphases/0-modes.md, phases/0-preflight.md, then 0-memory.md, 0-instruments.mdmode announced, repo configured, dashboard open
1 Manifestphases/1-manifest.md<дата>-brief.md, manifest.md
2 Briefingphases/2-briefing.md (+ 2-adversarial.md when it runs)answers recorded into the manifest
3 Specphases/3-spec.mdnotes.md in existing code, spec.md, the boundaries in interfaces.md
4 Planphases/4-plan.mdtickets/NN-*.md, the plan commit
5 Buildphases/5-subagents.mdcode, one commit per ticket
6 Reviewphases/6-review.md — at the first point review, and for the whole-branch reviewreviewed code
8 Finalphases/8-final.md, and phases/9-memory.md before spawningblind 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.

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.

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.

Show full SKILL.md (491 more words)Show less

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 — ap.py ask stop first, so the dashboard says it too.

Files this skill owns

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

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

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

© nick-vels, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 23 other files in skills/autopilot of nick-vels/skills.

  • SKILL.md
  • phases/0-instruments.md
  • phases/0-memory.md
  • phases/0-modes.md
  • phases/0-preflight.md
  • phases/0-resume.md
  • phases/1-manifest.md
  • phases/2-adversarial.md
  • phases/2-briefing.md
  • phases/3-spec.md
  • phases/4-plan.md
  • phases/5-repair.md
  • phases/5-subagents.md
  • phases/6-review.md
  • phases/8-final.md
  • phases/9-memory.md
  • phases/dashboard-template.html
  • phases/rationalizations.md
  • prompts/executor.md
  • … and 5 more

Open the folder on GitHubat commit 326c6ea

Compare with similar skills

Autopilot End-to-End Builder next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Autopilot End-to-End Builder compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Autopilot End-to-End Builder this skillnick-vels/skills414—~2.5kAutomated safety check: NotesMIT
Coordinated Agent Teamsjacob-dietle/context-os111—~4.2kAutomated safety check: PassMIT
Logseq Review Workflowlogseq/logseq45k—~3.8kAutomated safety check: PassAGPL-3.0
Subagent Driven DevelopmentAsvarox/allkaraoke26137 repos~1.2kAutomated safety check: PassNone
Paseo Advisor Second Opiniongetpaseo/paseo20k1 repos~756Automated safety check: PassCustom licence
O2 Review Loopopenobserve/openobserve22k—~3.7kAutomated safety check: PassAGPL-3.0

Similar skills

  • Coordinated Agent Teams

    jacob-dietle/context-os

    This skill should be used when decomposing a spec into a multi-agent implementation plan with dependency ordering, parallelism decisions, contract testing, and verification strategy.

    111 GitHub stars~4.2k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • Review Logseq code changes, PRs, patches, commit ranges, or implementation plans through one main-agent orchestration workflow that routes read-only subagents across independent review passes, then…

    45k GitHub stars~3.8k tokensUpdated today
    Knowledge ManagementAuto-check passed
  • Subagent Driven Development

    Asvarox/allkaraoke

    A skill your agent uses when executing implementation plans with independent tasks in the current session

    261 GitHub starsUsed in 37 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • Launches one separate agent through Paseo to give a second opinion on the current task, with a self-contained briefing and no permission to edit files.

    20k GitHub starsUsed in 1 repo~756 tokens
    Agent WorkflowsAuto-check passed
  • O2 Review Loop

    openobserve/openobserve

    Splits a change into planner, coder and independent reviewer roles: you confirm a spec, a subagent implements it, and a separate reviewer checks each round's local WIP commit.

    22k GitHub stars~3.7k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Paseo Committee

    getpaseo/paseo

    Forms a two-agent committee with contrasting profiles to analyze a stuck problem in parallel, reconcile their views and return a consensus plan without editing files.

    20k GitHub starsUsed in 1 repo~496 tokens
    Agent WorkflowsAuto-check passed

Categories

Questions about Autopilot End-to-End Builder

What does Autopilot End-to-End Builder do?

Builds an app, site, bot or feature from a spoken idea through requirements, spec, tickets, subagent work, review and acceptance, with a live progress dashboard. Starts only when explicitly invoked, carrying a dictated idea through requirements, a briefing, a formal spec, a build plan, subagent-driven implementation, review and final acceptance in one continuous run, without stopping for approval at every stage. Every rule lives in numbered phase files under `phases/` and prompt files under `prompts/`, so no other skill needs to be installed alongside it, and a bare re-invocation resumes an interrupted run instead of starting over.

When should I use Autopilot End-to-End Builder?

Autopilot End-to-End Builder fits situations like: building a complete app or feature from a single dictated idea; resuming an autopilot run that was interrupted partway through; letting an agent handle requirements through review without stage-by-stage approval; turning a rough idea into a numbered, checkable requirements manifest.

How do I install Autopilot End-to-End Builder in Claude Code?

Run `npx skills add nick-vels/skills --skill autopilot -a claude-code`. Or copy the skill folder (skills/autopilot in nick-vels/skills) into .claude/skills/autopilot in your project. Claude Code loads it when a task matches its description.

How do I install Autopilot End-to-End Builder in Codex?

Run `npx skills add nick-vels/skills --skill autopilot -a codex`. Or copy the skill folder (skills/autopilot in nick-vels/skills) into .agents/skills/autopilot in your project. Codex loads it when a task matches its description.

Can I use Autopilot End-to-End Builder in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add nick-vels/skills --skill autopilot -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/autopilot, .gemini/skills/autopilot, .github/skills/autopilot and .opencode/skills/autopilot in your project.

What does Autopilot End-to-End Builder need to run?

Going by SKILL.md and its folder, Autopilot End-to-End Builder needs credentials named STRIPE_SECRET_KEY.

Does Autopilot End-to-End Builder access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Autopilot End-to-End Builder safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Autopilot End-to-End Builder use?

Autopilot End-to-End Builder is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Autopilot End-to-End Builder use?

About 2.5k tokens (SKILL.md is roughly 9.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Autopilot End-to-End Builder?

Skills that share tags, products or a category with Autopilot End-to-End Builder: Coordinated Agent Teams (jacob-dietle/context-os, 111 stars), Logseq Review Workflow (logseq/logseq, 45k stars), Subagent Driven Development (Asvarox/allkaraoke, 261 stars) and Paseo Advisor Second Opinion (getpaseo/paseo, 20k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Autopilot End-to-End Builder?

nick-vels (a GitHub user) maintains it in nick-vels/skills, which has 414 GitHub stars. The repository was last updated on October 9, 2026.

Source: nick-vels/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.