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.