leonardopordeus

Tailor Spec — Testing skill for Claude Code

Testing community

An agent-agnostic skill that turns fuzzy feature requests into concrete implementation plans through a phased, review-gated workflow.

How to install Tailor Spec

This entry records only its repository, not the path inside it, so there is no exact command to give. Open leonardopordeus/tailor-spec and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Tailor Spec does

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

Alternatives in Testing

  • Pua — Use when the user invokes /pua or asks for PUA mode, try-harder/retry help, change-approach coaching, completi 19.5k ★
  • Notion Spec To Implementation — Convert Notion specs into linked implementation plans and tasks 14.6k ★
  • Claude Code Spec Workflow — Automated Kiro-style Spec workflow for Claude Code 3.6k ★

README

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