Cc autopilot

Skill gbotev1/cc-autopilot/skills/cc-autopilot

Run cc-autopilot, a perpetual autonomous AUDIT/GENERATE→TRIAGE→BATCH→FIX→VERIFY→REVIEW→COMMIT loop that holds every change to a configured quality bar through a judge panel. Its fixers each own a file-disjoint slice of the tree so no two can ever touch the same file, and nothing unverified reaches git. Works on a web app via browser judges, or a CLI, library, or service via a gate suite. Use when the user says "run cc-autopilot", "run the sprint", or "execute the plan", or wants to autonomously drive a project toward its quality bar wave by wave. Requires a cc-autopilot.config.json at the repo root.From its SKILL.md

Install

npx -y skills add gbotev1/cc-autopilot --skill cc-autopilot

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

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

SKILL.md

9.6 KB, as published. Nobody here has run it

cc-autopilot: autonomous polish sprint

This skill turns the current session into the manager of a cc-autopilot run: a perpetual, self-correcting loop that holds every change to a configured quality bar through a judge panel, then restocks its own queue with net-new features and intuitiveness wins each time it empties. The fix agents run sequentially per file-disjoint component and never write the same file, while the panel (audit/generate/verify) is what fans out; no unverified-failing change ever lands in git. It runs on a web app via browser judges, or a CLI, library, or service via a gate suite.

Before you start

Confirm the config exists, then run the doctor. Read cc-autopilot.config.json at the repo root. If it's absent, the project hasn't been onboarded; point the user at cc-autopilot/cc-autopilot.config.example.json and cc-autopilot/config.schema.md, and offer to scaffold it. Do NOT proceed without it. Then run node cc-autopilot/scripts/check-config.mjs. It validates the config against the repo (panel seats resolve to real agents, verify-routing seats are in the panel, surface keys are real, state-dir parents exist, the board is valid). A non-zero exit means a blocking problem the manager must fix before wave 1.
Commit the vendored engine if it is still uncommitted. npx cc-autopilot init writes the engine under cc-autopilot/, the root cc-autopilot.config.json, and the .gitignore edit, but deliberately never touches git (it is a pure scaffolder). On a freshly-onboarded repo those files are untracked, so the loop's very first BASELINE clean-tree assert would fail on them. Land them as ONE onboarding commit BEFORE the loop starts, separate from any wave commit. Check git status --short: if cc-autopilot/, cc-autopilot.config.json, or the .gitignore edit are untracked or modified AND no wave has committed yet (config.paths.wavesDir is empty / no sprint wave commit in git log), tell the user what you are about to commit, then git add cc-autopilot cc-autopilot.config.json .gitignore and git commit -m "Onboard cc-autopilot: vendor engine + config". Do this ONLY for the scaffold itself: never sweep unrelated uncommitted work into it, and never run it once a wave has landed (a dirty tree then is a mid-wave state the crash reaper owns, not onboarding). If the scaffold is already committed, this is a no-op: skip it.
Read the operating manual. cc-autopilot/orchestrator.md is the full wave-by-wave loop with every hard-won environment fact. THIS skill is just the entry point; the orchestrator is the law.
Cold-start read order (a fresh session WILL otherwise rediscover state the hard way):
- config.paths.resume: where the sprint is RIGHT NOW
- the latest config.paths.wavesDir/wave-NN.md: carry-forward learnings
- cc-autopilot/orchestrator.md: the operating manual
- cc-autopilot.config.json: the project bindings

The loop (one wave): see orchestrator.md for the full detail

AUDIT/GENERATE → TRIAGE → BATCH → FIX → VERIFY → REVIEW → COMMIT   (perpetual)

Preflight: on config.branch. In visual mode: app up at config.app.url; sweep stale browser tabs. In code mode: no app, no browser, no tab sweep; instead run the config.gates baseline on BASE to confirm the suite is green before claiming work. In both modes: after confirming no prior wave's workflow is still running (the one manual judgment), run node cc-autopilot/scripts/reconcile.mjs, the crash reaper. It resets stuck cards to todo, releases every orphaned lock, parks the cursor, and clears the kept-files freeze; a clean board is a no-op success.
Refill (when todo is thin): convene the panel in BOTH modes concurrently: the two generated scripts under <stateDir>/generated-workflows/ (use the exact paths printed by gen-panel.mjs). Merge their output into config.paths.triageInput, run node cc-autopilot/scripts/triage.mjs. It refuses to refill mid-wave (a held lock, or a cursor phase other than idle/triage): finish the wave or reconcile a dead one first.
Triage: refine the filed cards: severity, the files contention key, verify, blockedBy.
Batch: pick one eligible file-connected component for the next dispatch. Cards sharing a file stay with one sole-writer agent. Cap the component at a reviewable size. Claim it with node cc-autopilot/scripts/wave-state.mjs claim <wave> '<cardIds-json>': it checks eligibility (including the kept-files freeze from components accepted earlier this wave), locks the component, and writes config.paths.currentBatch itself; never hand-write that file.
Dispatch fix: run node cc-autopilot/scripts/gen-fix-batch.mjs (it reads the claim's currentBatch), then dispatch by scriptPath (never by name, since a stale cache returns 0 agents). Use the generated state path printed by the command, not the tracked template. Record the results with wave-state.mjs verifying '<results-json>'.
Verify before dispatching the next component: check-wired.mjs first in both modes. In visual mode (per card): dispatch each seat with the exact agentType + prompt + model verify-judges.mjs prints (the agentType, never the bare seat stem: bundled judges register plugin-namespaced, cc-autopilot:<seat>, in the session's agent registry) (it probes config.app.url first; an unreachable app is a server fault that exits 1, never a card failure, so start the app and re-run instead of reverting). In code mode (per component): verify-judges.mjs --json '<lead-card-json>' returns the gates strategy, then verify-gates.mjs runs the gate suite for the verdict; its exit 1 (proven red) is the only revert signal; exit 2 means the verdict is UNKNOWN (a timeout, a signal or interrupt, a gate command that could not run, a config/arg defect): keep the work, fix the cause, and re-run. Pass → wave-state.mjs accept (in code mode it refuses unless the verdict receipts written by verify-gates.mjs and check-wired.mjs cover this exact component AND the exact working tree they verified - each receipt carries the tree hash it ran against, so an edit after the gates passed forces a re-run - and it deletes them on success); proven red → git restore that card/component against BASE, then wave-state.mjs requeue with the critique.
Review: /code-review + /simplify on the kept diff (a headless session, where the Skill tool refuses them, dispatches an equivalent reviewer subagent per gate instead); file derived findings.
Checkpoint: run config.gates, write the wave log, archive-done.mjs, then node cc-autopilot/scripts/assert-diff.mjs $BASE '<kept-files-json>' (exit 0 = the diff is exactly the kept union, and it writes the diff-verdict.json receipt checkpoint demands, so it must run BEFORE the commit - it refuses outright once $BASE is no longer HEAD; exit 1 names residue to resolve, or a MISSING kept file with no diff: restore it if an edit was wiped, or, after confirming no edit was lost (an already-on-HEAD accept, or an over-declared best-estimate scope), re-run with the confirmed files as a third JSON-array arg to acknowledge them). ONE commit, then node cc-autopilot/scripts/wave-state.mjs checkpoint (clears the kept-files freeze and leftover receipts; it refuses until the wave is really settled, asserted, and committed, naming any held lock, a missing/mismatched diff-verdict receipt, or a kept file still dirty vs HEAD), then push config.pushBranch (NEVER config.protectedBranch without explicit approval).
Repeat perpetually: no clean-and-stop terminus; surface a per-wave summary so the owner can steer or pause.

The two environment facts to respect (don't fight them)

args is NOT threaded into Workflow scripts, so the batch + project config are inlined into the dispatched script by gen-fix-batch.mjs / gen-panel.mjs (the board-file handoff). Always dispatch by scriptPath, never by name.
The chrome-devtools browser is one shared instance (visual mode only), so fix workers never touch the browser; verification is a separate manager-run phase; sweep tabs to one keeper each checkpoint. In code mode there is no browser: verification runs the gate suite per component.

Always-on (optional)

To keep it progressing without re-prompting, run this skill under the loop skill: /loop <the invocation>. Self-paced: each wake runs a wave (or a few), logs it, commits, and schedules the next, perpetually, until the user interrupts.

Guardrails

Push only config.pushBranch. config.protectedBranch (e.g. main) is never pushed without explicit human approval.
A judge that flags a config.guardrails item is wrong; the manager drops it to wontfix.
This is a perpetual Opus-driven panel loop, and it does not self-throttle on cost. The user owns the spend dial (the /loop cadence) and can interrupt anytime.