What AcePilot does
The ship mode is designed for changes with high blast
radius. It plans before it executes, reviews before it commits, and
logs every decision. When the PR opens, there are no surprises.
Scan
Reads the target module and all callers. Maps the blast radius — every file that imports or depends on the code being refactored. Builds a complete picture before any line changes.
Working Backwards
Writes the PR description first — what done looks like, what changed, why, and the test plan. Then generates the task list from that spec. Forces clarity before a single line changes. The PR description is never written after the fact.
Execute
Refactors incrementally. Each task follows the same cycle: orient, execute, verify, qualify. Every checkpoint must pass tests before the next task starts. Circuit breaker: 3 consecutive failures trigger a BLOCKED state. Never an infinite loop.
Specialist review
Full team reviews every changed file. @architect checks for coupling increases and API surface breaks. @security checks for auth logic regressions, timing vulnerabilities, and input handling. @designer checks any UI that changed for accessibility and layout. Findings are fixed inline before qualifying.
Qualify
@reviewer reads TASKS.md (the spec), the git diff (the changes), and DECISIONS.md (the intent). Returns DONE or DONE_WITH_CONCERNS — never silent. Concerns are logged to DECISIONS.md with reasoning. Nothing is silently shipped.
PR
git push followed by gh pr create with
the pre-written description. CI/CD detects the PR and deploys a
preview environment if Vercel or Netlify is configured. The preview
URL is posted back to the terminal.
// What you get
- PR opened automatically with a complete description (what changed, why, test plan)
- All 6 specialists reviewed the final diff — security, UX, architecture, product
- Every concern logged in DECISIONS.md — nothing swept under the rug
- Passing tests before commit — never a broken main branch
- Preview deployment URL from CI/CD (if Vercel or Netlify is configured)
- DECISIONS.md entry: key choices made during refactor, with reasoning
Real example
/acepilot ship refactor auth module consolidated 4 auth
helpers into 1 module, updated 12 call sites, added 8 test cases, and
opened a PR — all in one session.
During the specialist review, @security found a token comparison using
== instead of crypto.timingSafeEqual. The
original code had been in production for 6 months. The fix was applied
before the PR was created. The DECISIONS.md entry records why
timing-safe comparison matters for token validation and links to the
relevant Node.js documentation.
When to use this
- Large refactors where you want specialist review before code hits main
- When you need an audit trail (DECISIONS.md) for architecture changes
- When the blast radius is high and you want zero surprises
- When the team needs a real PR with a real description, not just a diff
Try it yourself
$ cd acepilot && ./acepilot-14.0/install.sh
# In your project directory
$ claude
> /acepilot ship refactor [your module]
Replace [your module] with any natural language description
of what to refactor — a file path, a module name, or a description like
"the payment processing flow". AcePilot figures out the scope from
context.
Ship your next refactor cleanly
Free tier. No credit card. Install in 30 seconds.
Install AcePilot free