sprint

Feature Forge — preview

--farm — preview. This flag is part of the Feature Forge and ships dormant by default. Promotion to stable is driven by real-world evidence.

Autonomous sprint — one interactive spec gate, then plan-to-PR execution with every auto-decision SMARTS-scored and logged. Hard gates remain true stops.

What it does

This is codeArbiter’s autonomy mode. It collapses the usual spec-plan-execute cycle into one interactive checkpoint up front, then runs the rest of the arc — task selection, test-first implementation, review, and landing the branch — without stopping between batches. Every call it makes on your behalf along the way is scored and appended to a running log with a confidence rating, so a low-confidence choice is easy to find and revisit later even though nobody was there to approve it in the moment.

Usage

/ca:sprint [goal] [--farm]

A short goal seeds the spec conversation that opens the sprint. Add --farm to send implementation work to lower-cost worker agents while the same spec-authoring, test-writing, and review responsibilities stay put.

Example

> /ca:sprint add rate limiting to the public webhook endpoint

Opening the sprint spec conversation...
[Socratic refinement — per-IP limit, window, response on exceed]
Spec written to .codearbiter/specs/webhook-rate-limit.md. Plan written with 5 tasks.
Approve spec and plan to begin autonomous execution? (y/n)
> y

Executing task 1/5... task 2/5... task 3/5 touches security-controls.md scope — this is a hard gate,
halting for your decision rather than choosing on your behalf.

Task 3 adds a Redis-backed limiter key derived from client IP. Confirm this fits the approved
security posture before I continue? (y/n)
> y

...task 4/5... task 5/5 complete. Every auto-decision logged to sprint-log.md (1 low-confidence entry).
Routing to commit-gate, then finishing-a-development-branch (opening a PR — sprint never merges).

When to reach for it

Reach for /ca:sprint when the spec can be made concrete up front and you want the whole plan to run without per-batch checkpoints. /ca:feature is the better fit when you want to review progress between batches.

Gates

Gate	When	Effect
spec + plan approval	before autonomous execution starts	hard stop; both the sprint spec and the resulting plan need your explicit sign-off
hard gates	a security boundary, crypto/secret handling, an irreversible operation, an override request, an unresolved confirmation point, or a merge to the default branch comes up mid-run	execution halts and surfaces the decision to you instead of choosing on your behalf

Source

Source — plugins/ca/commands/sprint.md (v2.9.1)

---
description: Autonomous sprint — one interactive spec gate, then plan-to-PR execution with every auto-decision SMARTS-scored and logged. Hard gates remain true stops.
argument-hint: "[goal] [--farm]"
---

# /ca:sprint — autonomous sprint

The autonomy mode. Brainstorm a sprint spec with the user — the one interactive gate — then execute
the approved plan end-to-end without per-batch checkpoints, deciding "as the user" via SMARTS on
every non-hard-gate point. Every auto-decision lands in `.codearbiter/sprint-log.md` (append-only)
with a confidence flag; the `low`-confidence entries are exactly what the user reviews afterward.
Nothing is hidden behind autonomy.

## Flow

Load and follow `${CLAUDE_PLUGIN_ROOT}/SPRINT.md` — it is the procedure. In brief:

1. **Sprint spec (STOP)** — `brainstorming` scoped to a sprint, then `writing-plans`. Explicit user
   approval of spec AND plan before autonomy begins.
2. **Autonomous execution (BLOCK)** — `subagent-driven-development` runs the plan; test-first via
   `tdd`, two-pass reviewed, fresh-run verified. SMARTS decides non-hard-gate points; everything logs.
3. **Land & summarize (BLOCK)** — `commit-gate`, then `finishing-a-development-branch`, which
   auto-selects open-PR. `/ca:sprint` never merges and never discards; the merge decision is the user's.

Hard gates — `security-controls`, crypto/secrets/auth, irreversible ops, `/override`, an
unresolvable `[CONFIRM-NN]`, merge-to-default — are NEVER auto-decided. They halt and surface.

## Arguments

- **`"goal"`** — seed for the sprint-spec brainstorm.
- **`--farm`** — cost-arbitrage backend: cheap workers implement under the same gates; Claude still
  authors spec, failing tests, plan, and reviews everything. Pre-flights `FARM_API_KEY`.

## Routes to

`${CLAUDE_PLUGIN_ROOT}/SPRINT.md` (mode body), which routes through `brainstorming`,
`writing-plans`, `subagent-driven-development`, `commit-gate`, `finishing-a-development-branch`.

## When NOT to use

- A single feature with human checkpoints → `/ca:feature`.
- Work whose spec cannot be made concrete up front — the one interactive gate is load-bearing;
  a thin spec makes hard-gate stops frequent instead of rare.

View in repo