autopilot
Skill0 starsChanged 5 months agoMITView on GitHub
Drives an idea from any pipeline entry point — a cold raw prompt included — to one open MVP pull request in a single autonomous run, pausing only at a single Idea checkpoint and halting on genuine anomalies. Thin orchestrator: it detects the furthest-along artifact, then chains the existing producer skills ideate → specify → plan → implement → pull-request, arming a run-scoped autonomy signal that releases the human-approval gates and switches the producers into decide-and-record. It re-implements no producer logic and reuses the approval-autonomy implement/plan gate layer unchanged. Publish ceiling is local commits + one PR — never merge, deploy, or ship. Trigger: "do it autonomously", "/autopilot", "/autopilot <slug>", or "autonomously" appended to any ideate/specify/plan/implement request.
- Commits and pushes
74 other projects use a version of this.
Adopted by
Most recently taken up by
- zahidakhyar/skillstheir own version, first seen Nov 8, 2026
- kimkon1011/orgiast-claude-rulestheir own version, first seen Nov 8, 2026
- lohi-ai/babysittheir own version, first seen Nov 8, 2026
- paramcodes/skillstheir own version, first seen Nov 8, 2026
- jinjan21-lgtm/autopilottheir own version, first seen Nov 8, 2026
- ourostack/ouroboros-skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use review-bugbot, rename-chat and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
0mlkrizzz655335vSkillreview-bugbot
缺陷导向代码审查。用 Bugbot 子代理找 bug。
Also in 3 projects that use this
0mlkrizzz655335vSkillrename-chat
重命名当前聊天。按聊天内容改标题。"disable-model-invocation: true
Also in 3 projects that use this
Tsumugii24Skillsplit-to-prs
Split current work into small reviewable PRs. Use when the user asks to split a chat, set of changes, branch, or PR.
Also in 4 projects that use this
PandelisZSkillupdate-cli-config
View and modify Cursor CLI configuration settings in ~/.cursor/cli-config.json. Use when the user wants to change CLI settings, configure permissions, switch approval mode, enable vim mode, toggle display options, configure sandbox, or manage any CLI preferences.
Also in 3 projects that use this
32103210Skillmigrate-to-skills
Convert 'Applied intelligently' Cursor rules (.cursor/rules/*.mdc) and slash commands (.cursor/commands/*.md) to Agent Skills format (.cursor/skills/). Use when you want to migrate rules or commands to skills, convert .mdc rules to SKILL.md format, or consolidate commands into the skills directory.
Also in 3 projects that use this
32103210Skillupdate-cursor-settings
Modify Cursor/VSCode user settings in settings.json. Use when you want to change editor settings, preferences, configuration, themes, font size, tab size, format on save, auto save, keybindings, or any settings.json values.
Also in 3 projects that use this
- +1 more from 32103210
- +1 more from 0mlkrizzz655335v
Other versions74 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 74
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- Yeachan-Heo/oh-my-codex★ 34ksame name
- SethGammon/Citadel★ 927same name
- H-mmer/pentest-agents★ 815same name
- Harry-kp/vortix★ 757same name
- nick-vels/skills★ 599same name
- yan-labs/yan-skills★ 232same name
- kentcdodds/kcd-skills★ 64same name
- Kanevry/session-orchestrator★ 53same name
64 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 3 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 66 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
If a stage's quality gate returns Issues Found, or an anomaly halts implement, autopilot STOPS and hands back the blocker — it never …
- Distinctive: line 40
Refuse only: when the input is a genuinely empty ask — no prompt and no resolvable artifact to act on.
- Very specific: line 56
If the trigger names a slug (/autopilot <slug>), resolve that artifact.
- Distinctive: line 59
If nothing resolves and there is no prompt to ideate from, refuse and say what's missing.
- Very specific: line 100
Not applicable when the Idea pre-exists: When the run enters at or after an already-Approved Idea, no checkpoint fires — the human already …
- Very specific: line 109
After implement completes, autopilot invokes specstudio:pull-request exactly once to push the feature branch and open a single PR (built-in …
- Distinctive: line 116
Before any stage runs, autopilot emits one disclosure message so the user knows exactly what the run will do unattended.
“Common” is measured: kept by at least 6 in 10 of the 66 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Autopilot
Turn a single trigger into an end-to-end autonomous run: from a raw prompt (or any partial artifact) to one open MVP pull request, with no per-question stops and exactly one human checkpoint at the crystallized Idea. Autopilot is a thin orchestrator — it drives the existing ideate → specify → plan → implement → pull-request skills, arms the run-scoped autonomy signal defined in autonomy-autopilot.md, and hands back the trail. It owns orchestration, the Idea checkpoint, the publish ceiling, and the handback — nothing else.
Hard Gate
<HARD-GATE>
Autopilot MUST NOT:
- Re-implement any producer skill's logic, gates, or artifact writes — it only invokes them.
- Mask any gate other than a `type: human` approval entry. `type: ai` / `type: deterministic` reviewers, `specscore spec lint`, and `implement`'s conflict detection ALWAYS run and can halt the run.
- Skip the `confirm_idea` checkpoint when the run auto-creates an Idea and `autonomy.autopilot.confirm_idea` is not `false`.
- Publish past its ceiling: local commits + exactly ONE pull request. It MUST NOT merge, deploy, invoke `ship`, open a second PR, or retry a failed PR delegate.
- Auto-invoke `specstudio:verify` or `specstudio:ship`.If a stage's quality gate returns Issues Found, or an anomaly halts implement, autopilot STOPS and hands back the blocker — it never releases a quality gate to keep moving.
</HARD-GATE>
When to Use
- The user says "do it autonomously",
/autopilot,/autopilot <slug>, or appends "autonomously" to any pipeline request — even on the very first prompt, before any artifact exists. - The user wants to reach an MVP without answering per-stage clarifying questions or approving each gate, accepting one Idea checkpoint and a decision log they review afterward.
Refuse only when the input is a genuinely empty ask — no prompt and no resolvable artifact to act on.
Entry-Point Detection
Autopilot has no fixed precondition — it starts wherever the work currently is. Resolve the furthest-along existing artifact for the work, then run every remaining stage:
| Input state | Autopilot runs |
| Raw prompt, no artifact | ideate → specify → plan → implement → pull-request |
Draft / In Review Idea | ideate (finish) → specify → plan → implement → pull-request |
Approved Idea | specify → plan → implement → pull-request |
Approved Feature, no Plan | plan → implement → pull-request (or implement directly, per implement's Feature-sourced mode) |
Approved Plan | implement → pull-request |
Resolution steps:
- If the trigger names a slug (
/autopilot <slug>), resolve that artifact; otherwise infer the work from the prompt and scanspec/ideas/,spec/features/,spec/plans/for a matching in-flight artifact. - Pick the furthest-along artifact in the pipeline order
idea < feature < plan. Enter at the stage that produces the next artifact. - The trigger phrase is the consent to auto-create and auto-approve every artifact the run produces (subject only to the
confirm_ideacheckpoint). There is no separate "must be an approved Idea first" gate. - If nothing resolves and there is no prompt to ideate from, refuse and say what's missing.
The Run
Autopilot performs the run as an ordered drive over the producer skills. It does not reimplement any of them; each stage is the existing skill invoked in the current session.
- Arm. Establish the run-scoped autonomy signal (autonomy-autopilot.md) at run scope — once for the whole run (see Single Arming). Resolve
autonomy.autopilot(publish_ceiling,confirm_idea,stop_on) across the scope ladder. - Disclose. Emit the single up-front disclosure message (see the Disclosure section) before any stage runs.
- Drive the stages from the resolved entry point, in order, advancing to the next stage only after the current stage completes successfully:
- ideate (if entry ≤ Idea) → then honor the
confirm_ideacheckpoint (see the Idea Checkpoint section). - specify (if entry ≤ Feature) — its
gates.feature.approvedtype: humanentry is masked by the run-scoped signal; thetype: aireviewer still runs. - plan (if entry ≤ Plan) — its human review gate is masked; the baseline reviewer and P-001 coverage still hold.
- implement —
implementation.pre_commitis autonomous perapproval-autonomy;implementation.pre_pushis masked here (the push happens at the PR stage). Anomaly-halts still stop the run. - pull-request — open exactly one PR (see the Publish Ceiling section).
- ideate (if entry ≤ Idea) → then honor the
- Hand back the trail (see the Handback section).
At every stage, a masked type: human entry is released by the reviewer-gates runner's Step 1.6; the producers take their decide-and-record branch instead of asking clarifying questions. Autopilot itself asks nothing except the one confirm_idea checkpoint.
Single Arming
The trigger arms the run-scoped autonomy signal once, for the remainder of the run. Autopilot does NOT re-arm at each stage boundary — crossing from specify into plan into implement requires no fresh signal.
The one exception is inherited, not owned: if implement hits an anomaly-halt (sibling conflict, BLOCKED subagent, unresolved lint, source-Feature drift), that is a genuine stop under approval-autonomy's rules, and implement requires the explicit continue re-arm before resuming. That anomaly re-arm is implement's, scoped to its own stage — it is not a per-stage gate autopilot introduces. A subsequent autopilot run starts unarmed and re-reads config from scratch.
Anomaly Halts
Autonomy masks human approval, never quality. Autopilot stops and hands back the blocker whenever:
- a stage's
type: ai/type: deterministicreviewer returnsIssues Found; specscore spec lintfails and--fixdoes not resolve it in one pass;implementreports any anomaly in its halt set (perapproval-autonomy);- a
stop_ondecision class fires (conflictis always in the set and not removable).
On any halt, autopilot names the specific cause, performs no auto-resolution, and does not advance. The user fixes it and re-triggers (or issues implement's continue re-arm for an implement-stage anomaly).
Idea Checkpoint (confirm_idea)
When the run auto-creates an Idea (entry at or before the Idea stage), autopilot pauses exactly once — the single human-approval stop of an otherwise unbroken run. This is the cheapest, highest-leverage place to bound drift: a raw one-line prompt is the most ambiguous possible input, and a 30-second Idea read catches divergence before it propagates downstream.
- Default on. With
autonomy.autopilot.confirm_ideaunset ortrue, afterideatecrystallizes the Idea autopilot presents it and waits for explicit approval before invokingspecify. Theidea.approvedhuman review gate is not masked at this checkpoint — it is deliberately preserved. Recognize approval with the standard explicit-approval phrase set; a vague positive gets one confirmation question. - Opt-out. With
confirm_idea: false, the checkpoint is masked like every other human gate and the cold-start run is fully unbroken. - Not applicable when the Idea pre-exists. When the run enters at or after an already-
ApprovedIdea, no checkpoint fires — the human already approved that Idea. The checkpoint is specifically for Ideas the run itself shaped.
On explicit approval (or when confirm_idea: false), continue to specify. On a change request, fold it into the Idea and re-present — the run does not proceed past an unapproved run-created Idea.
Publish Ceiling
Autopilot's ceiling is local commits + exactly one pull request, resolved from autonomy.autopilot.publish_ceiling (default pr):
- Commits land during
implementvia the existingimplementation.pre_commitgate (autonomous perapproval-autonomy).implementation.pre_pushis masked in the implement stage — the push happens once, at the PR stage. - After
implementcompletes, autopilot invokesspecstudio:pull-requestexactly once to push the feature branch and open a single PR (built-ingit push+gh pr create, or the project's configuredpull_request.delegate). Itspull_request.pre_dispatchtype: humanentry is masked; atype: deterministicverify gate there is not masked and can still block. publish_ceiling: commitstops after local commits (no PR);publish_ceiling: stagestops after staging.
Autopilot MUST NOT merge, deploy, invoke ship, open more than one PR, or retry a failed PR delegate. The push safety floor (main/master/release/* denied by default) still applies — autonomy never weakens it.
Disclosure
Before any stage runs, autopilot emits one disclosure message so the user knows exactly what the run will do unattended. It states:
- the resolved entry point and the stages that will run;
- that human-approval gates are masked for the run, except the single
confirm_ideacheckpoint (named explicitly); - that clarifying decisions will be auto-made and recorded to each artifact's decision log;
- that the run will commit locally and open one PR, and will not merge or deploy.
The disclosure is informational — it is not a per-stage approval prompt. The run proceeds immediately after it.
Handback
On successful completion, autopilot hands back a single summary — the primary review surface, meant to be read first:
- the resolved entry point and stages run;
- the created artifact paths (Idea / Feature / Plan);
- the local commit SHAs;
- the opened PR URL;
- the aggregated Autonomous Decisions log — every decide-and-record entry from every stage (Idea
## Key Assumptionsadditions + Feature/Plan## Autonomous Decisions), collected in one place.
Autopilot does not auto-invoke specstudio:verify or specstudio:ship; it MAY recommend the user run them next.
References
- autonomy-autopilot.md — the
autonomy.autopilotconfig namespace, the run-scoped autonomy signal, and the decide-and-record +## Autonomous Decisionscontract. - reviewer-gates/runner.md — Step 1.6, the run-scoped human-gate mask this skill arms.
- approval-autonomy Feature — the reused implement/plan gate layer, anomaly-halts, and
continuere-arm. - publication-policy.md — the scope ladder the run-scoped signal sits on, and the push safety floor.
- Producer skills: ideate, specify, plan, implement, pull-request.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

