git:20261101.11940bf to git:20261101.e484ec4

7 added, 0 removed. Audit A to A.

---

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.