amend-feature

Amend Feature

Evolve a feature that already shipped — without re-running the greenfield gate. The feature has an approved spec and working code; the job is to classify the change honestly against that spec, then route it to the lightest lane that still keeps the spec and the tests true.

This is a fast lane, not a gate bypass. Every path still exits through test-first, and anything with real design questions escalates to frame-change. "Small" is a claim you prove-claim against the existing spec, not a feeling.

1. Ground the change in the existing spec

Find the feature's spec — docs/specs/<date>-<feature>/{requirements,design,tasks}.md via docs/specs/INDEX.md — and read the requirements the change touches plus the design section that owns them. If the feature has no spec at all, amend-feature is the wrong skill: a brand-new capability is frame-change, a break is root-cause.

Done when: you can name the requirement IDs the change affects.

2. Classify the change — out loud

State which case this is and why, the same way frame-change names a tier:

• Tier 0 — no behavior change. A recolor, an icon, a label, a copy edit; every existing acceptance criterion still reads true unchanged. → REQUIRED SUB-SKILL: use test-first (assert the visual/behavioral change at its seam). No spec edit beyond fixing a criterion whose wording is now stale.
• Tier 1 — changes or extends existing spec'd behavior, ≤ ~half a day. The change modifies what an existing requirement already promises, or adds a small follow-on to it. → mini-spec: add or amend-feature the requirement plus a ... SHALL CONTINUE TO ... guard for the behavior that must keep working (REQUIRED SUB-SKILL: use specify-behavior in its tier-1 mini-spec mode — append the fix and guard to the owning feature's requirements.md; no new feature code, no whole-file review), then REQUIRED SUB-SKILL: use test-first.
• Genuinely new scope. New behavior the spec never covered, a real UX or design decision with live alternatives, more than ~half a day, or it spans subsystems. → STOP amending. REQUIRED SUB-SKILL: use frame-change — this earns the full cycle. Do not shape big new work here.

The honest test for the escalation: does the existing spec's intent already cover this behavior? If you are inventing what it should do, it is new scope — hand it up.

Done when: the tier is stated out loud and the case is chosen.

3. Keep the audit-trace honest

After the change lands through test-first, its new or changed requirement carries its ID into the test tag and the commit trailer like any other. If you edited requirements.md, design.md, or tasks.md, REQUIRED SUB-SKILL: use realign-spec to realign Status: and the trace. Otherwise REQUIRED SUB-SKILL: use audit-trace directly and read its finding set. The check stays clean, or the change is not done.

Done when: the change is implemented test-first, its requirement ID traces end to end, and the audit-trace check reports no errors.

Red flags — you are in the wrong lane

• You are inventing behavior the spec never described → that is frame-change, not amend.
• The "small" change grew a design decision with real alternatives → escalate; do not decide it by feel here.
• You are about to change code without touching a test → that is test-first, always.
• The feature was never spec'd, or it is simply broken → frame-change (new) or root-cause (broken), not amend.
• You are splitting one request into a trivial part and a new-behavior part → route each half separately: the tweak stays here, the new behavior goes to frame-change.