Tailor Spec

tailor-spec

An agent-agnostic skill that turns fuzzy feature requests into concrete implementation plans. Works with any coding agent that follows a SKILL.md / AGENTS.md convention (Claude Code, Cursor, and others).

What it does

The agent picks the weight of the spec from the shape of the work, and says which it chose:

• Compact — one compact-spec.md, one approval gate. The default, and where a borderline call lands.
• Full — requirements, design + test plan, tasks. Four documents, three gates. Escalated to when the change spans separately deployed or owned components, breaks compatibility on a public contract, migrates data, decides or stores auth or PII, adds an external dependency or integration, or would outlive a revert. Every trigger carries a limit that keeps it from swallowing ordinary work — a backward-compatible addition is not a break, several files inside one deployable unit is not multiple components, and one more call against a service already in use is not a new integration.

A compact spec that outgrows itself gets split into the full set, keeping its requirement IDs; the expanded documents go back to `Draft` for review rather than inheriting the approval. The reverse runs only while the full documents are still `Draft`, so an approval already given is never thrown away.

Acceptance criteria carry stable `R` IDs, and every design decision, verification row, and task references them — so a requirement change points straight at the work it affects. Every document tracks `Status: Draft | Approved`, so a spec picked up days later resumes where it left off instead of re-asking for approvals; the document owning the task list carries `Implemented` and `Verified` on top of that.

Verification is planned before implementation, and each requirement is matched to the level that can actually close it. A passing unit test is not evidence that a requirement holds at the system boundary — unit tests close a *task*, the verificat