Build a Feature End to End

/ca:feature is the one entry point for new implementation work. Run it with a one-line description of what you want built:

/ca:feature "add rate limiting to the public search endpoint"

Host syntax

Claude Code uses /ca:feature ”…”; Codex uses $ca-feature ”…”; Pi uses /ca-feature ”…”. Shared artifact formats do not imply identical host authority. The HTML writer needs the installed engine’s capabilities. An explicit attestation claim separately uses the typed-artifact host boundary.

The request authorizes the agreed feature work. The lane maintains useful artifacts, follows real dependencies and checks the resulting behavior. Ask about consequential missing choices and respect explicit user pauses; routine artifact updates do not create another permission layer.

The work, from your side

Intent → specification → plan → reviewed delivery

Full-lane overview. New typed HTML work requires the applicable installed-host capabilities. Small-lane work and retained Markdown pairs follow the distinct paths below.

1. 01

   You set the outcome

   Review the specification

   What you get

   A specification with observable acceptance criteria, exclusions and verification oracles.

   Before moving on

   Correct missing behavior and resolve consequential choices. Preserve decisions already made and any requested review pause.

   Use the artifact review checklist →
2. 02

   You review the approach

   Inspect the linked plan

   What you get

   Tasks with exact paths, dependencies and checks linked to the specification criteria.

   Before moving on

   Check criterion coverage, real dependencies and current specification binding. In-scope maintenance uses the existing authorization.

   Inspect the planning contract →
3. 03

   codeArbiter works and reports progress

   Test, implement, review

   What you get

   Implementation progress, actual check results, relevant reviewer findings and pending work.

   Before moving on

   Resolve applicable blocking findings. REVIEW and DONE describe implementation progress, not independent verification.

   Follow the worked feature →
4. 04

   You retain delivery authority

   Inspect the commit and PR

   What you get

   A selectively staged commit and a pull request with fresh verification for the current source.

   Before moving on

   Check implemented scope, criterion coverage and unresolved findings. A PR is not a merge or a deployment.

   Review the PR boundary →

Reading map, not a captured run or live status. Only the actual artifacts, approvals and fresh checks establish what has completed.

See one complete example

Your first feature follows the same saved-search CSV export from a request through a corrected criterion, linked plan, actual fixture tests, review and PR checklist. It distinguishes illustrative human dialogue from captured fixture evidence. This page is the lane reference for applying that pattern to your own work.

You can state the outcome naturally; explicit commands select the same existing lane. A clear request does not replace the user decisions or permissions required by that lane.

First: full lane, small lane, or resume

The command classifies the request before it writes anything.

Path	When it applies	First durable evidence
Path Full lane	When it applies Any scope touch, new public surface, new dependency, more than two implementation files, or uncertainty	First durable evidence A maintained spec under .codearbiter/specs/
Path Small lane	When it applies At most two implementation files, no sensitive or architectural scope touch, and one to three testable criteria	First durable evidence Inline criteria reflecting the request plus one append-only triage.log line
Path Resume	When it applies A matching spec or plan already exists	First durable evidence The existing pipeline re-enters at its furthest completed checkpoint

The small lane trims ceremony, not gates: it still starts with test obligations, clears review and commit-gate, and finishes through a PR. If the classifier is uncertain, the full lane wins.

An interrupted run is not silently restarted. Name the same slug or ask for resumable work. The owning lane inspects the furthest valid checkpoint, not merely the latest filename. An usable spec without a plan returns to planning; an incomplete spec resumes its missing requirements. Inspect IN_PROGRESS work and outstanding workers before redispatch. REVIEW and DONE record implementation progress; actual checks determine verification. Resume and recover explains the continuation boundaries.

Refine the Idea Into a Spec

The brainstorming skill frames the outcome, selects a viable approach, makes acceptance observable, writes the specification and reviews it. It uses existing answers and asks only about consequential unresolved choices. Ordinary method choices stay within the agent’s scope. An explicitly requested pause remains effective.

Verification obligations come from agreed criteria and applicable contracts or security controls. One criterion may require several checks. The spec remains the working agreement for the feature.

Break the Spec Into a Plan

The writing-plans skill creates coherent tasks with useful outcomes, relevant paths, actual dependencies and concrete verification. Task size follows useful progress and review, without a compulsory duration or a separate agent lifecycle for each small edit.

For new full-lane work, the spec and plan are written as .codearbiter/specs/<slug>.html and .codearbiter/plans/<slug>.html through the installed typed-artifact engine. Existing Markdown pairs stay on their exact legacy path. Readiness diagnostics identify missing task structure or criterion coverage. Resolve requirements needed for the affected task while continuing independent authorized work.

Inspect the working agreement

Open the actual specification and plan. In the specification, inspect caller, trigger, observable behavior, exclusions and each verification oracle. In the plan, follow those stable criterion IDs to tasks, dependencies, paths and named checks. Ask for a scoped revision where the connection is missing. Use the native typed writer for revisions, preserving human edits and stable references. Opening HTML does not create an approval event. Use Review specifications and plans for the inspection checklist.

A typed plan can exist as an incomplete draft preview. Required coverage is many-to-many; the specification owns criterion identities. The native engine preserves source identity and concurrent-write checks. A structural failure prevents claiming a successful save; a draft label alone does not prevent already-authorized work.

Implement Test-First, Batch by Batch

The executing-plans skill selects meaningful batches and hands their scope to the implementation owner. Choose direct implementation or useful delegation. Review the combined change at the scope its risk and applicable policy warrant.

The tdd skill runs six phases for each task, in order:

• Obligations and approach. Map claims to meaningful checks before changing code.
• Baseline. Prefer test-first feature checks. Existing implementation may use current criterion-focused checks and meaningful negative controls. Confirmed fixes require genuine regression RED; refactors use passing characterization baselines.
• Implementation. Make the scoped change and run proving checks and affected existing tests.
• Obligation verification. Match claims to observed results, leaving failures and untested requirements outstanding.
• Coverage. Meet the declared profile’s required metrics and critical-path requirements, with unavailable measurements explicit.
• Lint and handoff. Run applicable quality tools and return actual results and pending checks.

After a batch, the coordinator reports changes, checks and next work, then continues within the authorization. An explicitly requested pause, actual consequential choice or applicable host restriction stops affected work. Checkpoint numbering is not itself a dependency.

Feature coordinates coherent batches; sprint owns full-plan autonomous execution and ends at an open PR. Both preserve real user decisions and current checks.

Commit selected work

When a batch is ready, run:

/ca:commit

The commit-gate skill is the only path to a git commit. It runs nine phases: permission, branch, classification, verification (tests, lint, secrets scan), behavioral proof, diff review, selective stage, message, and commit. A finding at any phase stops the commit.

The gate does not auto-decide hard gates. A secret in the diff, a crypto change, or a branch violation is a true stop that requires your explicit resolution. “It looks right” is not authorization.

Open the Pull Request

When the branch is ready to propose for integration, run:

/ca:pr

The pr command verifies the current branch’s base-to-HEAD diff and applies its reviewer matrix. Existing applicable results can be reused; missing or affected checks run before readiness is claimed. Unresolved BLOCK findings must be corrected. Opening a PR does not authorize a merge, and exact-head hosted CI remains required before an authorized merge.

Know that the lane is complete

Before calling the feature done, verify all of these:

• criteria still represent the agreed outcome and any material changes have their owner’s decision;
• implementation progress is accurate; DONE does not imply verification;
• each required claim has adequate current evidence, with missing or failed checks explicit;
• applicable local checks and review cover the actual source;
• any requested commit or PR was created through its owner under the existing authorization;
• merge, publication and live-host qualification are reported only when actually established.

Report implementation, verification, review and delivery separately. A plan label or one focused test cannot stand in for all four, and an unfinished unrelated task does not erase useful progress.

Common stops

Stop	What it means	Resume path
Stop A consequential unresolved decision	What it means The actual owner must choose	Resume path Ask once, preserve settled answers and continue independent tasks
Stop A task has no exact path or verification	What it means The plan is underspecified	Resume path Return that task to writing-plans
Stop A confirmed fix lacks target RED	What it means The regression baseline is missing	Resume path Observe the actual defect before repair; setup failure is insufficient
Stop A reviewer reports BLOCK	What it means A required correction remains	Resume path Resolve the finding and rerun affected verification
Stop The session ends	What it means Durable state remains on disk	Resume path Reinvoke feature; do not start over

Related

Skill or command	Where
Skill or command /ca:feature	Where commands/feature
Skill or command /ca:commit	Where commands/commit
Skill or command /ca:pr	Where commands/pr
Skill or command brainstorming	Where skills/brainstorming
Skill or command writing-plans	Where skills/writing-plans
Skill or command tdd	Where skills/tdd
Skill or command executing-plans	Where skills/executing-plans
Skill or command commit-gate	Where skills/commit-gate

For the concepts behind gated lanes and gate strengths, see Concepts.