feature command

Command

Build an authorized feature from a maintained specification, testable criteria and useful plan, without duplicating user approval.

Invoke it

Claude Code/ca:feature

Codex$ca-feature

Pi/ca-feature

Availability is read from each shipped host catalog. Preview-only commands are marked on the page.

What it does

The feature entry turns your requested outcome into testable criteria and a practical plan. Your request supplies the authorization to work. codeArbiter asks about consequential missing choices once, preserves settled decisions, and continues within the agreed scope.

A small change can use an inline mini-spec only when it touches at most two implementation files plus tests, has one to three concrete criteria, and touches no protected scope or new dependency, endpoint, command or configuration surface. Any uncertain condition selects the full lane, which maintains a specification and matching task plan before implementation.

Tasks are implemented directly or delegated when useful. The caller selects an appropriate verification approach, records the observed sequence and results, and routes applicable review. Progress reports do not require acknowledgement unless you requested a pause. Interrupted work resumes from the existing artifacts and actual remaining tasks. Local checks cover the affected scope; exhaustive exact-head hosted CI remains mandatory before merge.

Usage

/ca:feature <what you want to build>

A short description of the desired capability opens classification and supplies the intended scope. Include any decisions or review pauses you want to reserve for yourself.

Example

> /ca:feature add alphabetical ordering to the existing saved-search CSV export

The existing exporter needs one implementation file and its tests; no protected scope
or new endpoint, dependency, command or configuration surface is involved.
Small-lane criterion: export rows in ascending search-name order and preserve each row's fields.

Logged to triage.log. Selected verification: focused ordering and existing CSV round-trip tests.
[ordering test fails because rows retain input order]
[exporter updated; ordering and round-trip tests pass]
The completion report names the checks and any remaining review or delivery work.

When to reach for it

Reach for /ca:feature for a bounded capability with useful progress reports. For autonomous execution across a whole plan, use /ca:sprint. Both preserve real user decisions and host permissions; neither requires repeated artifact approval to continue ordinary work.

For the connected operating model, read gated lanes and test-first evidence. The map distinguishes a routed procedure from a command you must type, and retains the caller’s review and delivery boundaries.

Gates

Gate	When	Effect
triage	before any routing decision	the request is classified small-lane or full-lane against fixed criteria; an uncertain case always falls to the full lane
consequential decision	a required product choice is unresolved	ask once and keep affected work waiting; settled choices and independent work continue
verification	before implementation begins	select checks against the criteria, then record the actual test sequence and results before claiming completion
requested checkpoint	the user explicitly asks to review a group of tasks before continuation	pause at that checkpoint; routine progress reports otherwise continue into the next independent work

Route context

Find this entry in the workflow atlas. Compare its related teaching maps, host spelling and context inputs. The exact procedure below remains the owner.

Source

Source — plugins/ca/commands/feature.md (v3.7.0)

---
description: "Build an authorized feature from a maintained specification, testable criteria and useful plan, without duplicating user approval."
argument-hint: "<what you want to build>"
---

# /ca:feature — spec-driven feature

The feature entry maintains a useful spec and plan before full-lane implementation. The user request supplies the intended authorization; the artifact engine does not require another permission code. Check criteria and applicable tests before claiming completion.

## Structured-artifact boundary

For new full-lane work or an existing `.html` spec/plan match, load
`${CLAUDE_PLUGIN_ROOT}/includes/artifacts.md` before resume classification or artifact
I/O. After lane classification, call
`_select_authoring_route` with the trusted project root, slug, `workflow: feature`,
and the selected lane. Use only its returned mode, format, and paths. For a
selected HTML route it
checks the installed capability before writing; a missing or invalid helper is
a STOP and the workflow must not fall back to Markdown.
Its typed identity, binding, and task-progress operations replace rendered-label and Markdown status-cell assumptions for that pipeline.
New full-lane specs use the installed structured-artifact engine and default to
canonical `.html`. An existing `.md` pair remains on the legacy path. Discovery requires a
complete same-extension spec/plan pair: select that exact pair as authoritative. A
mixed-extension or duplicate match is a STOP. A lone spec resumes in its exact format,
and the next plan must use the same extension. The workflow must not create, rename, or convert its counterpart to repair ambiguity. HTML `--farm` dispatch stays
blocked. Small-lane behavior is unchanged: its confirmed mini-spec remains inline
and does not create a spec artifact.

**Orientation:** if the code map is present (`.codearbiter/code-map.md`, or its HTML knowledge document), read it first — a coarse concern→path→role map that orients task authoring. Absent is fine; it is read-on-demand, populated by context-creation or commit-gate heal. At each actual author or independent reviewer dispatch, use the private `_artifactpromptlib.compose_feature_actor_input` contract described in `tdd` and `subagent-driven-development`; send the bounded relevant input to that actor. Host permissions still apply to commands; delivery records do not independently grant or deny execution.

## Resume — an interrupted pipeline is re-entered, never restarted

Before triage, scan `${CLAUDE_PROJECT_DIR}/.codearbiter/specs/` and `plans/` for artifacts
whose slug matches `$ARGUMENTS` (invoked bare, list every resumable pipeline and
ask which). Call the private bridge resolver `_resolve_workflow_pair` with the
trusted project root and selected slug; its returned paths and format own this
resume. Select a complete same-extension pair as authoritative. A lone spec
resumes in its exact format, and the next plan must use the same extension. A
mixed-extension or duplicate match is a STOP. A crash, compaction,
or closed session mid-pipeline loses nothing — the spec, the plan, and each task's
state are on disk. For an HTML pair, obtain state only through the installed
engine `identity`, `index`, and symbol-scoped `read` operations; do not scrape
rendered labels or embedded JSON. For a Markdown pair, use the
existing Markdown status ledger. Resume either exact format
without creating or consulting a shadow artifact; the workflow must not create,
rename, or convert its counterpart. On a match,
summarize the resume point without requesting an additional permission reply, then re-enter at the furthest useful stage:

1. **Plan exists with remaining, blocked, or unverified work** → `executing-plans` for actual outstanding tasks. HTML `REVIEW` and `DONE` are implementation progress, not proof of passing checks.
2. **Plan work complete with applicable checks recorded** → the authorized `commit-gate` handoff, without making a proof receipt another permission.
3. **Spec exists, no plan** → `writing-plans`.
4. **Spec exists but is incomplete** → inspect the missing actual requirements with `brainstorming`, rather than restarting the interview.

Re-running `brainstorming` against a usable existing spec discards decisions and re-asks answered questions. Only an explicit user
request ("start over") restarts an existing slug — and that is logged to `triage.log` like any
classification.

## Step 0 — change-class triage (logged)

Before routing, classify the request. The **small lane** applies only when ALL of these hold —
judged against `$ARGUMENTS` and a quick look at the code, never assumed:

- the change touches ≤ 2 implementation files (plus their tests);
- no §4 reference-map scope-touch: auth/crypto/secrets, dependencies, migrations/schema, telemetry,
  public API surface, domain vocabulary;
- no new dependency, endpoint, command, or configuration surface;
- the behavior change is expressible as 1–3 concrete, individually testable acceptance criteria.

**Small-lane SMARTS.** Only when the change involves a material solution choice — two or more
materially plausible ways to build it — run a SMARTS scan per `${CLAUDE_PLUGIN_ROOT}/includes/smarts/core.md`,
inline with no grader or scout, and state its one-line result with the mini-spec. Otherwise state
`SMARTS: no material solution choice` and continue; that path adds no SMARTS table and no extra
artifact. If the scan shows that the better approach would violate any small-lane criterion above,
route to the **full lane**.

**Small lane:** state the mini-spec inline (the 1–3 criteria). Unless the user requested a pause or a real consequential question remains, proceed without a second permission reply. Append one line to `${CLAUDE_PROJECT_DIR}/.codearbiter/triage.log`
(append-only, `>>`):

```
[ISO-8601 timestamp] | BY: <git user.email> | LANE: small | SCOPE: <one-line> | BASIS: <criteria met>
```

Then route directly to `tdd` (`${CLAUDE_PLUGIN_ROOT}/skills/tdd/SKILL.md`) — the stated criteria are its obligations; run applicable TDD checks — and exit through the full `commit-gate` and `finishing-a-development-branch` exactly as
the full lane does. The lane trims ceremony, never gates.

Any criterion violated, or uncertain → **full lane** (below). Uncertainty is full-lane; the triage
never guesses.

## Flow — full lane

Route through the pipeline in order; each step gates the next:

1. **`brainstorming`** (`${CLAUDE_PLUGIN_ROOT}/skills/brainstorming/SKILL.md`) — refine `$ARGUMENTS` into a concrete spec by Socratic questioning: challenge
   vague language, surface hidden complexity, force trade-offs. Writes the spec to
   route-selected spec path. New full-lane work writes
   `${CLAUDE_PROJECT_DIR}/.codearbiter/specs/<slug>.html` through the installed engine.
   A missing consequential decision is asked once, not converted into a general spec-approval gate.
2. **`writing-plans`** (`${CLAUDE_PLUGIN_ROOT}/skills/writing-plans/SKILL.md`) — turn the maintained spec into coherent tasks, each with relevant paths and a
   verification that maps to a `tdd` obligation (it does not replace one). Writes
   matching route-selected plan path with bijective criterion↔task coverage.
3. **`executing-plans`** (`${CLAUDE_PLUGIN_ROOT}/skills/executing-plans/SKILL.md`) — runs coherent batches through `subagent-driven-development`, directly or with useful agents. Reports real progress and check results; pauses only for explicitly requested checkpoints or real missing decisions.
4. **`commit-gate`** — the only path to a commit; nine gates, including behavioral proof.
5. **`finishing-a-development-branch`** — terminal step: open-PR / merge-via-PR / discard. Every
   change lands through a PR; never a direct write to the default branch.

The autonomous counterpart (`/ca:sprint`) maintains the same spec→plan but passes the full plan to
`subagent-driven-development` directly, without per-batch checkpoints. That path is its own entry,
not `/feature`.

## Scope routing

Scope suggests useful author skills (`backend-author`, `frontend-author`, `infra-author`), not mandatory one-agent-per-task dispatch. Run the affected local checks and preserve failures; exhaustive cross-area and cross-platform proof remains exact-head hosted CI before merge under `${CLAUDE_PLUGIN_ROOT}/includes/verification-boundary.md`.

## When NOT to use

- A known defect with a reproduction → `/fix`.
- A behavior-preserving restructure → `/refactor`.
- A question or quick discussion → ask it directly; no command needed.
- Persisting work already written → `/commit`.

## Hard gate

MUST preserve testable intent and perform applicable checks before claiming completion. An unapproved artifact is not a denial of an already-authorized feature. MUST NOT take the small lane
unless every Step 0 criterion holds, and MUST log the classification to
`.codearbiter/triage.log` before `tdd` begins. MUST NOT skip `writing-plans` in the full lane.
MUST NOT guess consequential unresolved user decisions; keep the affected task visibly waiting.
MUST NOT restart an interrupted pipeline whose artifacts exist on disk — resume at the furthest
checkpoint per the Resume ladder, unless the user explicitly asks to start over.

View in repo