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.