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.
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.
$ npx skills add nick-vels/skills --skill autopilot -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install nick-vels/skills autopilot --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .claude/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/nick-vels/skills/tree/main/skills/autopilotType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add nick-vels/skills --skill autopilot -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install nick-vels/skills autopilot --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/autopilot .agents/skills/autopilot && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .agents/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add nick-vels/skills --skill autopilot -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install nick-vels/skills autopilot --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/autopilot .cursor/skills/autopilot && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .cursor/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/nick-vels/skills.git --path skills/autopilot--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add nick-vels/skills --skill autopilot -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install nick-vels/skills autopilot --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/autopilot .gemini/skills/autopilot && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .gemini/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install nick-vels/skills autopilotInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add nick-vels/skills --skill autopilot -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/autopilot .github/skills/autopilot && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .github/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add nick-vels/skills --skill autopilot -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install nick-vels/skills autopilot --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/nick-vels/skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/autopilot .opencode/skills/autopilot && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "autopilot" agent skill from https://github.com/nick-vels/skills/tree/main/skills/autopilot into .opencode/skills/autopilot/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "autopilot", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
autopilotBuilds 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.
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.
5 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit 326c6ea. It shows what the files ask for, not the result of running them.
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.
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.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names these keys or tokens, usually read from environment variables:
STRIPE_SECRET_KEYFrom names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
_SECRET_KEY`. The user puts values into `.env` themselves; `.env` is ignored before the first commit; the report lists tAutomated 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.
The full file from nick-vels/skills at commit 326c6ea, republished under its MIT licence (© nick-vels). 1,207 words, ~2,468 tokens.
.claude/skills/autopilot/SKILL.md (or your agent's skills folder). This skill also uses 23 other files; get the full folder from GitHub.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.
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 |
| 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, 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.
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 | План · Разработка · Код-ревью · Приёмка |
«Сборка» — весь прогон, поэтому пятый этап — «Разработка». Единица работы — «таск»: «задача» — это то, что поставил пользователь.
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.
Binding on every phase; the phases do not restate it.
phases/1-manifest.md. «Verbatim» always means «verbatim after redaction».STRIPE_SECRET_KEY. The user puts values into .env themselves; .env is ignored before the first commit; the report lists the names still empty.ap.py ask stop first, so the dashboard says it too..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.
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:
.autopilot/, the memory files, .gitignore, .env.example and git; everything else goes to a subagent (phases/5-subagents.md).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
SKILL.md and 23 other files in skills/autopilot of nick-vels/skills.
Open the folder on GitHubat commit 326c6ea
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Autopilot End-to-End Builder this skillnick-vels/skills | 414 | — | ~2.5k | Automated safety check: Notes | MIT | |
| Coordinated Agent Teamsjacob-dietle/context-os | 111 | — | ~4.2k | Automated safety check: Pass | MIT | |
| Logseq Review Workflowlogseq/logseq | 45k | — | ~3.8k | Automated safety check: Pass | AGPL-3.0 | |
| Subagent Driven DevelopmentAsvarox/allkaraoke | 261 | 37 repos | ~1.2k | Automated safety check: Pass | None | |
| Paseo Advisor Second Opiniongetpaseo/paseo | 20k | 1 repos | ~756 | Automated safety check: Pass | Custom licence | |
| O2 Review Loopopenobserve/openobserve | 22k | — | ~3.7k | Automated safety check: Pass | AGPL-3.0 |
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.
logseq/logseq
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…
Asvarox/allkaraoke
A skill your agent uses when executing implementation plans with independent tasks in the current session
getpaseo/paseo
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.
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.
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.
Categories
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.
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.
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.
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.
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.
Going by SKILL.md and its folder, Autopilot End-to-End Builder needs credentials named STRIPE_SECRET_KEY.
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.
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.
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.
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.
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.
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.