/ca-sprint

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 [includes/helper-invocation.md](../../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 [SPRINT.md](../../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

[SPRINT.md](../../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.