/stdd:remove — retire a feature and its three homes

/stdd:remove — retire a feature and its three homes

Feature: $ARGUMENTS

Removing a feature is the mirror of building one: a spec, its source, and its tests arrived together, so they leave together, in one commit. This skill retires the whole slice. Dropping one behaviour from a feature that still exists is a change, not a removal: send that to /stdd:spec $ARGUMENTS (revise in place, retire the affected AC-N). The rationale and the wider lifecycle are in ${CLAUDE_PLUGIN_ROOT}/docs/lifecycle.md ("Removing a feature").

This is destructive and stays under the user's judgement: show the full deletion set and wait for a yes before removing anything.

Steps

1. Locate the three homes. From $ARGUMENTS:

   • the spec docs/specs/$ARGUMENTS.md (and its red-team stamp under docs/specs/.redteam/, if one exists). If the spec is absent, stop and tell the user: the name may be wrong, or the feature was never specified.
   • the source it governs. Read the spec's Public interface and module path to find the src/ files; by convention the spec name mirrors the source path (docs/specs/auth/login.md → src/auth/login.*).
   • the tests: co-located *.test.* / *.spec.* next to that source, or files under tests/ whose names or AC-N tags trace to this spec.

2. Confirm scope. If the user means to keep the feature and drop only part of it, stop and point them at /stdd:spec $ARGUMENTS: that is a revision. Proceed only for a whole-feature retirement.

3. Show the deletion set and get a yes. List every file to be deleted (spec, stamp, source, tests) plus the roadmap row and any overview-doc map line that name the feature. Delete nothing until the user confirms.

4. Delete, staged. git rm each file (source, tests, spec, stamp) so the removal is staged and reviewable. Drop the slice's row from docs/roadmap.md if it is still listed.

5. Sweep docs/ for dangling references: the sweep /stdd:tdd runs at Finish, in reverse. Grep the tree (outside the files you just deleted) for:

   • the spec slug ($ARGUMENTS) and the removed module's file paths;
   • names of exports, types, or config fields the feature owned;
   • the surface's map line in the UI, architecture, or domain-model overview.

   For every hit, decide update or remove and say why. This is the check a removal otherwise lacks: nothing else notices a half-deleted feature.

6. Record the decision. Ask the user:

   • Does this reverse a cross-cutting decision? If so, write a superseding ADR in docs/decisions/. Do not rewrite the old one; the old decision and why it changed are both worth keeping.
   • Is the feature now a deliberate non-goal? If so, record it as an OOS-N in docs/out-of-scope.md (create it from ${CLAUDE_PLUGIN_ROOT}/templates/out-of-scope.md if absent), or let the superseding ADR carry the boundary (one place, not both) so nobody re-proposes it cold.

   Skip either when it plainly doesn't apply, and say so.

7. Verify the tree is still green. Run:

   ./scripts/run-tests.sh --all
   

   Show the full output. A failure here means another feature leaned on the one you removed. Surface the coupling to the user rather than deleting more to make it pass.

8. Hand off to one commit. stdd never commits for the user. Summarise what was removed and what you recorded, then point them at a single commit that says what left and why. The pre-commit gate runs the suite before it lands.