ca-sprint git:20261101.e484ec4A

Immutable. This exact content never changes and is served at /api/v1/blob/f681d15894388e9d.

---
name: ca-sprint
description: "Run an autonomous sprint from maintained specs and plans, with truthful verification and no duplicate artifact approval ceremonies."
argument-hint: "[goal] [--farm]"
---

# /ca-sprint — autonomous sprint

The user's requested sprint establishes its working scope. Use `brainstorming` to clarify genuinely missing outcomes, `writing-plans` to maintain a practical plan, and `subagent-driven-development` to execute through real task dependencies without per-batch permission questions. Record meaningful choices and honest evidence; do not invent approvals, clear user stops, or infer tests passed from progress labels.

For each independently actionable deliverable, select or create one work ID
through the installed `hooks/work.py` facade. Use an explicit ID or stable
source origin to resume; title and command invocation are not identity. A
single-outcome sprint may use one item. For several deliverables, set the same
optional cycle key on each item with `work.py set-cycle`, or pass `--cycle-id`
on creation. The cycle groups member work IDs; it does not copy their specs,
plans, task states or checks into a second ledger. `work.py cycle-view
<cycle-id>` is the derived group overview. Keep real spec/plan attachments on
their selected member work item and report local progress, checks, PR delivery
and provider effects independently. See `<plugin-root>/includes/helper-invocation.md` for
literal helper invocation and retry boundaries.

Where the native project has explicitly configured transition mapping, use
the ordinary one-item lifecycle call for each member. It saves the mapped
tracker intent or a waiting reason with local progress. Do not translate
status labels or stage each target in a separate model-facing call. A later
explicit `work.py sync-mapped <WORK-ID>` handles only that item's mapped
targets and reports partial results; no sprint transition sends over the network.

## Flow

Load and follow `<plugin-root>/SPRINT.md`:

1. **Specify and plan:** build or resume the exact spec/plan representation. Ask about consequential missing choices, not about arbitrary approval hashes.
2. **Execute:** work through task-scoped prerequisites and coherent batches, implement or delegate where useful, and check changed behavior. Retry affected failures without restarting a reviewer fleet.
3. **Report and deliver:** show actual results, pending checks, and open choices. Use the existing authorized `commit-gate` and PR handoff; opening a PR does not authorize merging or publishing.

Real host/tool permissions, explicit security policy, irreversible operation limits and user stops remain intact. Artifact `DONE` means implementation reported complete, not independently verified acceptance.

## Arguments

- **Goal:** intended sprint outcome and scope.
- **`--farm`:** separately requested legacy Markdown preview backend; obey its provider, budget and circuit-breaker boundaries. HTML farm is disabled, and failure does not authorize a silent backend switch.

## Routes to

`<plugin-root>/SPRINT.md` routes through `brainstorming`, `writing-plans`, `subagent-driven-development`, `commit-gate`, and `finishing-a-development-branch`.

For a single bounded feature, use `/ca-feature`. No repetitive initial spec approval interview is implied by either entry.