autopilot
Skill3 starsChanged 6 months agoMITView on GitHub
Intent-to-PR pipeline. Describe an outcome in natural language and the system runs the full development pipeline autonomously — brainstorm, spec, plan, build, ship — with multi-agent adversarial review at every artifact stage. Two gates total (post-brainstorm + PR review on GitHub). Cost-capped. Use when the user says "autopilot", "build this end to end", "take this from idea to PR", or invokes /autopilot {intent}.
- 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.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- code-simplificationSkill
- dcgSkill
- editorial-reviewSkill
- journalSkill
- readme-updateSkill
- security-and-hardeningSkill
- session-retroSkill
- blunder-huntSkill
- brainstormSkill
- convergence-detectSkill
- deslopSkill
- dispatch-parallelSkill
- doc-reviewSkill
- dreamSkill
- incremental-implementationSkill
- planning-and-task-breakdownSkill
- polishSkill
- pr-reviewSkill
- refactor-planSkill
- scope-checkSkill
- security-auditSkill
- spec-driven-developmentSkill
- unstuckSkill
- verification-before-completionSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 3 are distinctive, and 5 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.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 71
Run jutsu swarm dream --mode full against the leading design
- Distinctive: line 88
Wait for user response. Approve → Phase 2.
- Very specific: line 92
Step 1: Write spec to docs/specs/<date>-<slug>.md following the brainstorming spec format.
- Very specific: line 102
Step 1: Write IMPLEMENTATION_PLAN.md following the writing-plans skill format — bite-sized stages with exact file paths + test commands.
- Distinctive: line 129
After PR open (or abort):
- Very specific: line 130
Write run summary to ~/.claude/projects/<project>/memory/autopilot-run-<date>-<slug>.md.
- Very specific: line 132
Update MEMORY.md if a lesson is broadly applicable.
- Distinctive: line 180
Findings are report-only: Never auto-apply.
“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 v2 — Intent → PR pipeline
Take a natural-language intent and run the full development pipeline to a polished PR. Two gates total: brainstorm approval (Gate 1) + PR review on GitHub (Gate 2 — the existing PR semantics). Multi-agent adversarial review replaces the single-reviewer model from v1.
NOTE: kaijutsu-managed. Re-running
jutsu install autopilotoverwrites this file. The previous v1 SKILL.md (if any) is preserved at~/.claude/skills/autopilot/.archived/SKILL.md.
Command Detection
/autopilot {intent}→ Run mode (start new pipeline)/autopilot resume→ Resume mode (continue interrupted run)/autopilot abort→ Abort mode (clean up + stop)/autopilot status→ Status mode (show current phase)
CLI equivalents: jutsu autopilot {init,status,abort,resume,run}. Use the slash command for interactive runs; the cobra group is for scripted use + CI test mode.
Phase Map
/autopilot {intent}
→ Phase 1: BRAINSTORM (interactive — anti-sycophancy via jutsu swarm dream)
→ ★ GATE 1 (configurable: skip | review) ★
→ Phase 2: SPEC
→ write spec to docs/specs/<date>-<slug>.md
→ swarm doc-review on spec [report-only]
→ record approved-spec path in state file
→ Phase 3: PLAN
→ write plan to IMPLEMENTATION_PLAN.md
→ swarm doc-review on plan [report-only]
→ Phase 4: BUILD (stage 1..N — each followed by polish loop)
→ Phase 5: SHIP
→ final swarm pr-review (full lens)
→ reverse-drift gate (informational, tagged on PR)
→ gh pr create (or test-mode: write planned PR JSON)
→ ★ GATE 2 = PR review on GitHub ★
→ Phase 6: LEARN (state file, findings.db, MEMORY.md)Cost Cap
Three layers (per spec Decision #3):
- Soft cap — config default $20 (overridable via
.kaijutsu/autopilot.yaml::cost.max_total_usd); at 50% of soft cap, autopilot pauses + asks user to confirm continue. - Hard ceiling —
MaxAutopilotCostUSD = $100constant incli/internal/cli/autopilot.go. Cannot be raised by editing yaml. Per-run override via--max-cost Nworks only up to ceiling. - Per-shell ceiling override — set
KAIJUTSU_AUTOPILOT_HARD_CAP_OVERRIDE=Nin your shell environment to raise the ceiling for THIS shell. Not stored in repo. Defense against malicious yaml.
Above the ceiling without env var → error. Pre-flight jutsu swarm <preset> --estimate projection runs at Gate 1 before any model dispatch.
Phases (detailed)
Phase 1: BRAINSTORM (interactive)
Interactive conversation with the user about the intent. Anti-sycophancy enabled by default: invoke jutsu swarm dream --mode full --strict --personas brainstorm-creative-claude,architecture-purist-antigravity,claim-auditor-claude against the leading direction. User sees the design ALREADY ARGUED AGAINST before approving Gate 1.
Step 1: Read project context (parallel):
CLAUDE.md(project rules + constraints)~/.claude/projects/*/memory/MEMORY.mdmatching this project.claude/decisions/*.mdwithstatus: activegit log --oneline -20- Past autopilot runs from memory (entries named
autopilot-run-*)
Step 2: Scan for related code — grep + skill-suggest:
jutsu suggest "<intent>"to see if installed skills already handle sub-problems- Grep the codebase for keywords from the intent
Step 3: Anti-sycophancy dream pass (when autopilot.yaml gates.brainstorm: review):
- Run
jutsu swarm dream --mode fullagainst the leading design - Surface load-bearing findings + anti-skill arguments to the user
Step 4: GATE 1 — present design to user with the dream findings already attached:
## Autopilot: Direction Review
**Intent:** "{original intent}"
**Leading approach:** {1-paragraph summary}
**Why this approach:** {2-3 sentences}
**Dream's adversarial findings:** {top 3 load-bearing concerns}
**Estimated cost (pre-flight):** ${X}
Approve, revise, or reject?Wait for user response. Approve → Phase 2. Revise → re-explore. Reject → abort.
Phase 2: SPEC
Step 1: Write spec to docs/specs/<date>-<slug>.md following the brainstorming spec format.
Step 2: Run jutsu swarm doc-review --personas architecture-purist-antigravity,paranoid-security-claude,claim-auditor-claude <spec-path>.
Step 3: Findings printed to stderr inline + appended to <workspace>/findings.md. Findings are report-only (per spec Decision #2). Autopilot does NOT mutate the spec automatically. User can apply specific findings via re-run after editing.
Step 4: Record approved spec path in .kaijutsu/autopilot-state.md (approved_spec_path key) for the reverse-drift gate to consume.
Phase 3: PLAN
Step 1: Write IMPLEMENTATION_PLAN.md following the writing-plans skill format — bite-sized stages with exact file paths + test commands.
Step 2: Run jutsu swarm doc-review --personas perf-purist-codex,claim-auditor-claude,cross-file-antigravity <plan-path>.
Step 3: Findings report-only (same as spec).
Phase 4: BUILD
For each stage in the plan:
- Implement the stage — fresh subagent dispatched per task per the subagent-driven-development protocol.
- Polish loop — invoke
/polishskill against the stage's diff. Up to 4 review-fix passes per stage. If findings remain after 4, escalate to user. - Run tests — project's test command must pass before moving to next stage.
- Commit — descriptive message linking to the spec + plan.
Track cost across all stages. Pause at 50% of soft cap; abort at hard ceiling without override.
Phase 5: SHIP
Step 1: Final swarm pr-review (full lens) — jutsu swarm pr-review --diff-from-branch main --strict --personas paranoid-security-claude,architecture-purist-antigravity,perf-purist-codex,claim-auditor-claude --mode full. Apply load-bearing findings; defensible-skip the rest.
Step 2: Reverse-drift gate — jutsu swarm reverse --spec <state.approved_spec_path> --diff origin/main...HEAD. Drift findings appended to PR description as <details> block. PR labeled autopilot-drift if drift surfaced.
Step 3: Open PR — gh pr create with synthesized body. In test mode (KAIJUTSU_AUTOPILOT_TEST_MODE=1), writes planned PR to .kaijutsu/autopilot-pr.json instead.
Phase 6: LEARN
After PR open (or abort):
- Write run summary to
~/.claude/projects/<project>/memory/autopilot-run-<date>-<slug>.md. - Findings recorded into
~/.kaijutsu/findings.db(existing v0.7 schema). Each autopilot run adds rows so per-agent confidence weights tune the next run. - Update
MEMORY.mdif a lesson is broadly applicable.
State File
Path: .kaijutsu/autopilot-state.md. YAML frontmatter, no body.
---
intent: "<original intent>"
phase: brainstorm | spec | plan | build | ship | learn | done
slug: <feature-slug>
approved_spec_path: docs/specs/<date>-<slug>.md
plan_path: IMPLEMENTATION_PLAN.md
branch: feat/<slug>
pr: <url-or-empty>
started_at: <ISO timestamp>
gate_responses: { brainstorm: approve | revise | reject }
cost_so_far_usd: <running total>
---State file enables resume + status + abort to work after session interruption.
Findings Application Path
Per spec Decision #2: doc-review findings are report-only. Never mutate the artifact silently.
- Findings printed to stderr inline during the swarm run.
- Same findings written to
<workspace>/findings.md. - User reviews findings; if changes are wanted, user edits the spec/plan directly OR re-runs autopilot after editing.
- Autopilot continues to next phase without applying findings unless severity is
blocker(perfindings.escalate_thresholdconfig) — in which case autopilot pauses + asks user how to proceed.
This preserves the reviewer/generator boundary that dream finding #4 surfaced.
Skill References
See references/:
config-schema.md— full.kaijutsu/autopilot.yamlreferencecost-model.md— soft cap + hard ceiling + env overridepersona-defaults.md— which personas run at which phase + how to override
See runbooks/:
abort-and-resume.md— state file format + resume protocoldrift-detection.md— reverse-drift gate behavior + interpretation
Hard Rules
- Two gates only. Brainstorm approval + PR review on GitHub. No mid-flight gates by default.
- Findings are report-only. Never auto-apply.
- Cost ceiling is non-negotiable. Hard ceiling lives in skill code, not yaml.
- Reverse-drift is informational, not blocking. Drift surfaces on the PR; user decides.
- Replace, don't extend. v1 autopilot at
~/.claude/skills/autopilot/.archived/SKILL.md(preserved on install).
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.

