Run an Autonomous Sprint
Use an autonomous sprint when you can describe a substantial outcome and want codeArbiter to carry the work through implementation, verification and a pull request without stopping between task batches. Your request establishes the working scope. codeArbiter maintains a specification and plan, asks about consequential missing choices, and continues within your stated limits. A sprint request does not authorize merging or publication.
The work, from your side
Set the outcome and inspect real progress
Artifact progress supports the work. Actual host permissions, user decisions, security controls and delivery authority remain separate.
You bound the work
Maintain one working agreement
- What you get
- A linked specification and implementation plan for the requested sprint outcome.
- Before moving on
- Inspect scope, exclusions, criterion coverage, dependencies and spending or external-side-effect limits together.
You resolve consequential choices
Answer only what remains open
- What you get
- Actual decisions and explicit limits recorded with the work they affect.
- Before moving on
- Already answered choices stay settled. Ordinary plan maintenance and task progress need no additional artifact approval.
codeArbiter executes within scope
Implement and verify coherent tasks
- What you get
- Observed check results, required review findings, durable task progress and material decisions.
- Before moving on
- Work runs directly or through useful delegation. REVIEW and DONE describe implementation progress; passing checks and independent review require their own evidence.
You inspect the handoff
Finish at a pull request
- What you get
- Commits, the PR and a record of completed and blocked work.
- Before moving on
- Inspect actual local results, exact-head hosted checks and unresolved decisions. Merge and publication need their own authorization.
Reading map, not a captured run or live status. Only the actual artifacts, approvals and fresh checks establish what has completed.
Implementation routing: commands, skills and agents
Follow the public command through planning, execution and delivery. Internal skills and agent roles are routing choices, not additional commands you must invoke.
Follow the work, not a catalog
An authorized sprint reaches a PR
Current assistive source flow with retained historical citations. The user's request authorizes the agreed work; ordinary drafts, task progress and in-scope methods require no second artifact approval, context ticket or receipt-driven reviewer chain. Actual user stops, host/security controls and commit/publication permissions remain. This source explanation is not a captured live host run.
Rows identify roles. Gold commands enter or define a procedure; blue skills coordinate work; green agents perform bounded roles. Arrows cross rows in execution order. A dashed arrow reuses a procedure rather than calling its entry again. Dashed nodes are conditional roles selected for the work.
Chapter 1 / 4
Establish the working agreement
What outcome and constraints define the work?
Link to this chapter- command
/ca:sprint: select the work
Resolve an existing exact-format pair before starting new work. This map follows a new HTML pair; existing Markdown retains its own contract.
Result: One selected format, scope and backend.
define scope → The selected new sprint enters the definition phase.
Source for step 1 - skill
brainstorming: sprint definition
Capture the outcome, exclusions, priorities and real constraints. Read relevant recorded intent and existing decisions; ask only consequential unresolved owner questions.
Result: A ready draft specification and surfaced decisions.
draft pair → Derive useful tasks and checks from the current agreed specification.
Source for step 2 - skill
writing-plans: linked draft
Maintain a same-format spec/plan pair with useful criteria, tasks, dependencies and checks. A draft_preview binding identifies current source; ordinary in-scope plan maintenance needs no separate artifact permission.
Result: A structurally valid linked draft for the agreed outcome.
agreed scope → Keep the linked plan aligned with the authorized outcome; no artifact approval ceremony is required.
Source for step 3 - skill
/ca:sprint: maintain the agreement
Continue under the user's existing authorization with the maintained spec and plan. Do not arm pair approval or delegate-methods for ordinary work. Explicit requested checkpoints and material outcome changes still belong to their actual owner.
Result: A bounded working agreement, without invented approval or new permission receipts.
Source for step 4
Before continuing: A maintained spec and plan for the authorized outcome. Material unresolved product choices go to the actual owner; ordinary planning does not wait for an artifact approval receipt.
Continuations, returns and repeat paths
- authorized work. The maintained plan reaches implementation without artificial batch pauses or pair approval. Next: subagent-driven-development: select. Owning contract
Chapter 2 / 4
Build and verify each task
What replaces the attended batch coordinator?
Link to this chapter- skill
subagent-driven-development: select
Read compact task-context or exact symbols and inspect the full dependency ancestry. Unresolved ancestors remain visible with their IDs and reasons; independent work can proceed. Inspect existing IN_PROGRESS work before redispatch and preserve independently blocked tasks.
Result: One coherent task inside the agreed scope with relevant current facts.
useful unit → Implement directly or delegate when useful within actual host permissions.
Source for step 5 - skill
Task engine: implement or delegate
Work directly for a focused change or delegate a coherent unit when useful. Supply relevant criteria, paths, constraints and checks within actual host permissions. Bounded context delivery ends after two attempts with an advisory unknown observation; missing critical inputs and actual conflicts still stop dependent work.
Result: Implementation work with bounded relevant context.
behavioral task → Use the verification approach appropriate to the change; documentation or non-runnable work uses concrete relevant validation.
Source for step 6 - skill · if applicable
tdd inside authoring
Select proportional verification: genuine regression RED/GREEN for fixes, criterion-focused checks for features, and passing characterization baselines for refactors. Preserve behavioral assertions, meaningful negative controls where needed, coverage and lint.
Result: Evidence returned to the caller, not permission to commit.
actual results → Record checks actually run and inspect the result against the agreed criteria.
Source for step 7 - skill
Task engine: verify truthfully
Compare work with the agreed criteria and run relevant checks through the host-governed tool. Record actual command outcomes and limitations with task-check; caller-reported results do not certify an independent review or passing named-test proof.
Result: Actual checks, failures and unrun obligations, with no fabricated evidence.
Source for step 8
Before continuing: Useful implementation and actual check results. Reported progress remains separate from independent review, passing verification and release readiness.
Continuations, returns and repeat paths
- concrete validation. Documentation-only or other work without a runnable test uses concrete relevant validation and records the actual result. Next: Task engine: verify truthfully. Owning contract
- More eligible tasks. Continue independent dependency-clean work while preserving real blockers and outstanding checks. Next: subagent-driven-development: select. Owning contract
- review warranted. Obtain useful independent or policy-required review for the actual risk and scope. Next: Combined quality reviewers. Owning contract
- no extra review needed. When no additional review is warranted or required, report implementation progress with actual checks and limitations. Next: Task engine: honest implementation progress. Owning contract
Chapter 3 / 4
Assess risks and report progress
What prevents a green task from becoming a false completion claim?
Link to this chapter- agent · if applicable
Combined quality reviewers
Review the relevant diff when risk or change size warrants it. Select specialist review for actual security, dependency or migration concerns or an applicable policy; a receipt change alone does not require another reviewer.
Result: Applicable quality findings against the whole scope.
classify → The active caller retains responsibility for severity and scope.
Source for step 9 - agent · if applicable
finding-triage
Classify actual findings and preserve out-of-scope follow-ups. Correct affected work and revisit only conclusions changed by relevant source, requirements or evidence.
Result: A disposition for the current findings.
honest progress → Record actual implementation progress without claiming that pending verification passed.
Source for step 10 - skill
Task engine: honest implementation progress
Use receipt-free task-review and accept-scope to record implementation readiness or DONE with a real reason. These labels do not certify tests, independent review or release. Preserve blocked members, real user stops and outstanding checks.
Result: Reported implementation progress with evidence and remaining work kept distinct.
Source for step 11
Before continuing: Relevant findings, actual check outcomes and honest implementation state. A failing or unrun check remains visible; an actual user stop remains blocked.
Continuations, returns and repeat paths
- Correction inside scope. Repair affected work and rerun relevant checks; preserve explicit user stops and actual security or host denials. Next: Task engine: implement or delegate. Owning contract
- authorized handoff. Return the honest report to sprint, which owns any authorized commit and PR action. DONE is not release readiness. Next: commit-gate. Owning contract
Chapter 4 / 4
Commit and hand off the PR
Where does autonomous authority end?
Link to this chapter- skill
commit-gate
When a commit is authorized, retain staged-diff inspection, secrets checks and applicable tests through commit-gate. Artifact progress does not create commit, merge or publication authority.
Result: The gated commit and its actual evidence.
current commit → The normal completion path reaches finalization.
Source for step 12 - skill
finishing-a-development-branch
Sprint mode selects Open a PR instead of asking for attended terminal choices. Merge and discard are excluded.
Result: A PR handoff, not authority to land on main.
reuse procedure → Run the existing procedure without invoking its entry again.
Source for step 13 - command
/ca:pr procedure reused in place
The finisher executes the PR procedure here; the command is not re-invoked. Existing caller ownership prevents a routing loop.
Result: Required PR preparation and path-selected review.
review before PR → Only the actual reviewer results support the final verdict.
Source for step 14 - agent
PR reviewers and verdict funnel
Complete the applicable review and resolve blockers before opening. The sprint summary includes logged decisions, low-confidence calls and follow-ups.
Result: An open PR with an honest sprint report and unresolved obligations.
Source for step 15
Before continuing: Inspect the actual PR head, observed checks, meaningful decisions and unresolved findings. Commit and PR actions use existing authorization; merge and publication remain separate.
Continuations, returns and repeat paths
An implementation report and authorized open PR with actual checks, meaningful decisions and remaining work. Reported DONE does not certify verification or release; the sprint never merges or discards work without separate authority.
Host syntax: Claude Code uses /ca:sprint; Codex uses
$ca-sprint; Pi uses /ca-sprint. Examples below use Claude Code syntax.
New HTML work uses the installed native writer on supported hosts. Its capability check protects artifact integrity; it does not grant tool permissions or establish live-host qualification. Explicit attestation has separate host support requirements. See the capability boundaries.
Before you begin
Section titled “Before you begin”- Start on a non-default branch or allow the sprint to create an isolated worktree.
- State the outcome, boundaries, and any spending or external-side-effect limits.
- Identify any unresolved user decisions the goal depends on; independent work can continue.
- Expect a maintained specification and implementation plan. State any review pauses you want.
Invoke the sprint with the outcome, not a list of implementation guesses:
/ca:sprint "Add an export flow for saved searches, including empty-state behavior, audit records, and user documentation"The working spec and plan
Section titled “The working spec and plan”codeArbiter investigates the repository and prepares two linked artifacts:
- Sprint spec: the user outcome, scope, exclusions, acceptance criteria, and hard constraints.
- Implementation plan: exact tasks, files, tests, dependencies, ordering, and verification mapped back to every acceptance criterion.
Read them together to see whether the plan covers the intended outcome. If planning reveals a consequential missing requirement, codeArbiter asks its owner once and keeps the affected work waiting. An implementation method, test runner or task breakdown can change within the agreed outcome with a recorded reason. Neither file introduces a second permission interview.
Inspect the durable package
Section titled “Inspect the durable package”New full-lane work uses .codearbiter/specs/<slug>.html and
.codearbiter/plans/<slug>.html through the installed native writer.
Existing Markdown pairs remain on their exact legacy path. Open both files and inspect the
criteria, exclusions, task coverage, dependencies and verification.
Review specifications and plans explains the distinction between a
browser view, structural readiness, implementation progress and actual evidence.
For the saved-search example, a request for CSV export must not silently include account sharing, external spending or publication. Request a scoped revision if the plan misstates the outcome.
Execution and resumption
Section titled “Execution and resumption”The sprint executes coherent tasks through their actual dependencies:
- read the selected task’s criteria, relevant source and prerequisites;
- select verification appropriate to the change;
- implement directly or delegate a bounded unit when useful;
- run applicable checks and obtain independent review where required;
- record actual results, failures, unrun checks and implementation progress; and
- continue independent work while affected blockers remain visible.
A confirmed bug needs a genuine failing regression before its fix. Feature work verifies the
selected criteria and reports the observed test sequence; a behavior-preserving refactor uses
passing characterization checks. Tests and review follow the work’s obligations and risk.
Typed REVIEW means implementation is ready; DONE means implementation is reported complete.
Neither status certifies passing checks, independent review or user acceptance.
An interrupted session re-enters through the existing spec, plan, task states and sprint log.
Inspect running workers, partial changes and committed work before reconciling an IN_PROGRESS
task. Preserve user stops and do not redispatch an uncertain attempt because its reply was lost.
Recheck evidence affected by source or result changes; resuming alone does not require a new
reviewer fleet. See Resume and recover.
How autonomous decisions work
Section titled “How autonomous decisions work”The sprint makes reversible implementation decisions within the requested outcome. Use
SMARTS when a difficult trade-off warrants comparison across Scalable,
Maintainable, Available, Reliable, Testable and Securable. Material choices, their reasons and
meaningful uncertainty are recorded in .codearbiter/sprint-log.md.
Low-confidence decisions are called out in the pull request so you can review the places where the evidence was genuinely close. Spending outside your stated limit is not treated as an ordinary SMARTS choice.
Factual prerequisites can be checked through ordinary authorized tools. Record what was observed and which tasks it affects. A tool result does not settle a user-owned product choice, and a SMARTS recommendation does not authorize spending or a broader outcome.
Stops that remain yours
Section titled “Stops that remain yours”Stop affected work for:
- an explicit user stop or requested review pause;
- a consequential missing product decision;
- a real host or tool permission denial;
- an applicable security, secrets, migration or publication control; or
- irreversible operations, overrides, external spending or side effects beyond existing authority.
Already-authorized security work does not automatically need another user reply. Resolve actual risks and preserve required review. A failing test calls for diagnosis and correction, not a new permission code. If one task is blocked, independent safe work continues.
Pull request and verification
Section titled “Pull request and verification”The normal sprint exit is a pull request, not a merge. The PR should contain:
- the maintained spec and plan;
- acceptance-criterion to task/test coverage;
- verification commands and results;
- reviewer findings and their dispositions;
- SMARTS decisions, with low-confidence calls highlighted; and
- remaining blocked, unverified or out-of-scope work.
Confirm the PR is draft when you want a deliberate merge barrier. Hosted checks still need to run against the exact current PR head before the work is treated as ready.
Optional farm backend
Section titled “Optional farm backend”HTML plans cannot use --farm.
The following example applies only to an existing authoritative legacy Markdown pair. Do not
convert a new HTML plan to Markdown to make the flag work.
For that existing legacy backend, --farm selects a configured OpenAI-compatible worker:
/ca:sprint "Normalize the public API error contract" --farmThe same working scope, applicable controls, checks, review and PR boundary apply. Farm use is a separately requested preview backend requiring provider configuration, a budget and circuit-breaker limits. Failure does not authorize a silent backend switch. It may transmit secret-redacted, byte-capped task context to the endpoint you configure; read Compatibility: Network Calls before enabling it.
Verify and review
Section titled “Verify and review”After the PR opens:
- read the acceptance criteria and plan delta;
- review low-confidence SMARTS entries in
.codearbiter/sprint-log.md; - confirm every required local verification is present;
- wait for hosted checks on the exact PR head; and
- authorize merge separately when the required evidence supports it.
For the exact orchestration contract, see the sprint command and
the subagent-driven-development skill.