carve-feature

Derive SPEC.md and CONTEXT.md contracts from existing code without changing its behavior.

1|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/matthewalton/speccle --skill carve-feature-matthewalton
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: carve-feature
Source: https://github.com/matthewalton/speccle/tree/main/packages/plugin/skills/carve-feature
Command: npx skills add https://github.com/matthewalton/speccle --skill carve-feature-matthewalton

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Legacy or ungoverned code often works correctly but has no written specification, making it risky to change and impossible to review against intent. This Skill brings existing code under a documented convention by deriving acceptance criteria from observed behavior, without modifying the code itself. ## Core Features & Use Cases - Behavior-Derived Specs: Reads existing tests, source code, and docs to draft SPEC.md, CONTEXT.md, and CLAUDE.md that describe what the code observably does today. - Deterministic Linting: Runs the speccle oracle CLI to lint the derived spec until clean, enforcing fixed rules like malformed-id, weasel-wording, and compound-criterion. - Criterion Claiming: Tags existing tests with [KEY-n] criterion ids, moves tests beside the code they defend, and writes new tests only for unclaimed criteria. - Findings Workflow: Suspicious behavior is recorded as findings for a human to rule intended-or-bug at the spec summary, never silently fixed. - Use Case: You inherit a working checkout module with no documentation. Ask the agent to carve it into a governed feature folder, and it produces a linted spec, a glossary, tagged tests, and a summary of questionable behaviors for your ruling. ## Quick Start Carve the existing checkout module into a governed feature folder by deriving its spec from observed behavior and tagging the tests that already defend each criterion.

Frequently Asked Questions about carve-feature

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a spec for existing legacy code?▼

Read the existing tests first, then the source, then docs, and derive one testable criterion per observed behavior into a SPEC.md with stable [KEY-n] ids. Never write the criterion you wish were true; record suspicious behavior as a finding for human review instead.

What is the difference between carving a feature and building a new one?▼

Carving documents behavior that already exists without changing code, while a feature pipeline builds behavior that does not exist yet. A mixed request is handled as a carve followed by separate governed work, never one pass.

Does carving code change or refactor the source files?▼

No, a carve never edits source files. The final diff touches only test files and the markdown contract (SPEC.md, CONTEXT.md, CLAUDE.md, decisions/), and this invariant is verified with git status before handing back.

How are tests linked to spec criteria?▼

A test claims a criterion when the [KEY-n] token appears in its full concatenated name, typically by renaming the enclosing describe block. Tests that map to no criterion stay untagged, and new tests are written only for unclaimed criteria.

What happens when a newly written test fails during a carve?▼

A failing new test is a discovery, not a draft to iterate on. Either the code was misread and the statement gets fixed and re-linted, or a bug was found, which is removed from the spec and recorded in the project's tracker.

When should I not use the carve-feature approach?▼

Do not carve when the boundary is an unnamed catch-all like src/ or when source sits loose outside the boundary's src/ folder. Those cases require a pre-carve refactor done by the user before carving can begin.