Autopilot
Claude Code plugin: skills, commands, and tooling for SpecScore-driven specification authoring (specstudio:ideate, specstudio:specify, …)
npx -y skills add specscore/specstudio-skills --skill autopilotAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
11.6 KB, ~2.6k tokens by cl100k_base, as published. Nobody here has run it
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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most ship operate skills give in ~2.6k tokens
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07
- Document a rollback plan before deploymentin 41 of 779, across 22 files
- Update the changelogin 21 of 779, across 19 files
- Run the test suitein 20 of 779
- Create an annotated git tagin 20 of 779
- Clean up feature flags after full rolloutin 18 of 779, across 10 files
- Verify deployment health after launchin 18 of 779, across 10 files
- Test both feature flag statesin 17 of 779, across 9 files
- Verify the working tree is cleanin 17 of 779
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- Set up error monitoring before launchin 15 of 779, across 7 files
- Monitor metrics at each rollout stagein 14 of 779, across 5 files
- Create a GitHub releasein 14 of 779
Said here and by no other author read
- arm the run-scoped autonomy signal once
- emit a single up-front disclosure message
- resolve the furthest-along existing artifact
- invoke existing producer skills in pipeline order
- mask type human approval gates during the run
- auto-make clarifying decisions and record them
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.