spec-compliance

Verify implementation coverage against specs, tickets, and PRDs with requirement checklists.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/Royrahav/my_claude_components --skill spec-compliance-royrahav
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-compliance
Source: https://github.com/Royrahav/my_claude_components/tree/main/skills/spec-compliance
Command: npx skills add https://github.com/Royrahav/my_claude_components --skill spec-compliance-royrahav

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When implementing features from a spec, ticket, or PRD, requirements get silently dropped, half-built, or quietly abandoned when they turn out to be hard — and unrequested scope creep sneaks in. This Skill enforces a systematic four-phase verification workflow so nothing is missed and nothing extra is built before declaring work done. ## Core Features & Use Cases - Requirement Decomposition: Turns any spec into a numbered checklist of atomic requirements, including implied requirements, edge cases, error states, permission boundaries, and explicit out-of-scope items. - Acceptance Criteria Extraction: Distinguishes what a feature does from how to know it is done correctly, hunting for unstated criteria around failures, empty states, and third-party dependency behavior. - Diff-Based Verification: Re-reads the checklist against the actual diff to catch partial implementations, abandoned requirements, and scope creep, producing a pass/fail readout per item. - Ambiguity Handling: Flags ambiguous spec points with a decision rule for when to ask the user versus when to default, with batched-question phrasing examples. - Use Case: Before marking a ticket complete, run the checklist against the diff to confirm every requirement — including the implied cascading cleanup and error handling the ticket never spelled out — is actually implemented. ## Quick Start Check this implementation against the spec in the ticket and verify all requirements are covered before marking it done.

Frequently Asked Questions about spec-compliance

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

FAQPage Schema
How do I verify my implementation covers all requirements in a ticket?

Decompose the ticket into a numbered checklist of atomic requirements before coding, then re-read each item against the actual diff after implementation. Produce a pass/fail readout per item rather than relying on a general sense of completeness.

How to catch missing requirements when implementing from a PRD?

Scan for implied requirements the PRD never states: confirmation flows, cascading cleanup, error handling, empty states, and permission boundaries. Specs systematically under-specify unglamorous parts, so treat each explicit requirement as a prompt to ask what else must be true.

What is the difference between spec compliance and code quality review?

Spec compliance governs the WHAT: whether all asked-for behaviors exist and nothing extra was built. Code quality review governs the HOW: whether the code is well-designed and correct. Code can pass one check while failing the other, so both are needed.

When should I ask the user about spec ambiguity versus defaulting?

Ask when the interpretations are hard to reverse, high-stakes, or materially different in scope. Default when the change is cheap to reverse, low-stakes, or the codebase already has a convention — but always state the default explicitly rather than guessing silently.

Why do requirements get silently dropped during implementation?

Requirements are dropped when they turn out harder than expected, when attention shifts mid-task, or when no checklist forces a return trip. Working from memory on specs with more than a few requirements is the primary cause.