From spec-compliance
This skill should be used when the user asks to "make this spec tight", "lock this down", "deviation-resistant", "spec compliance", "implement this exactly", "faithful implementation", "literal spec", "stop deviating", "follow this precisely", "Claude keeps changing my design", or expresses frustration about Claude Code not following a plan. Also triggers on: "convert this to MUST/MUST NOT", "lock down requirements", "testable spec", "binary spec". Converts design docs, implementation plans, and natural-language specs into deviation-resistant specifications that Claude Code will follow literally.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spec-compliance:spec-complianceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Convert natural-language plans, design docs, and implementation specs
Convert natural-language plans, design docs, and implementation specs into a format that eliminates interpretation during Claude Code sessions. Every requirement in the output is binary, testable, and explicitly scoped.
Claude Code treats specs as guidance, not contracts. It reads "the hero should use a gradient" and produces a gradient that looks reasonable. But the spec author chose a specific gradient with specific stops for specific reasons. The gap between "reasonable" and "specified" is where deviation lives.
This skill closes that gap by converting every requirement into one of four statement types that leave no room for interpretation.
A positive requirement. Binary: either true in the final implementation or not. No partial compliance.
Rules for writing MUST statements:
An explicit prohibition. Prevents the five deviation modes.
Rules for writing MUST NOT:
What to do when the spec disagrees with the codebase. Addresses reasonable substitution, the most common deviation mode.
Three standard IF CONFLICT statements belong in every spec:
A specific check to confirm a requirement was implemented correctly. Each VERIFY pairs with one or more MUST statements.
Rules for writing VERIFY:
Prefer checks in this priority order:
Every spec produced follows this exact structure:
# [Feature Name] Implementation Spec
## META
Status: LOCKED
Spec version: 1.0
Author: [user] via spec-compliance
Date: [date]
Implements: [reference to design doc or conversation]
## SCOPE
Files to create or modify (exhaustive list):
- path/to/file.tsx
Files that MUST NOT be modified:
- path/to/protected/file.tsx
## REQUIREMENTS
### [Section Name]
MUST: [requirement]
MUST NOT: [prohibition]
VERIFY: [check]
## CONFLICT PROTOCOL
IF CONFLICT: This spec takes precedence over existing code.
IF CONFLICT: If a MUST cannot be met, STOP and report.
IF CONFLICT: If you believe a requirement is wrong, implement
it anyway and note your concern afterward.
## COMPLETION CHECKLIST
Run all VERIFY statements in order. Report pass/fail for each.
If any VERIFY fails, fix and re-run before marking complete.
Read the entire design doc, session brief, implementation plan, or natural-language description completely before responding.
Parse the source for every stated or implied requirement. Classify each:
Anticipate where Claude Code is likely to deviate. Generate MUST NOT
statements for each risk. Consult references/deviation-risks.md for
common risks organized by task type.
For every MUST, ask: "How would I confirm this is correct without reading the full codebase?" The answer becomes a VERIFY statement.
Write the full spec document. Include a brief summary at the top noting how many MUST, MUST NOT, and VERIFY statements it contains.
Before delivering, scan the spec for common gaps:
| Tool | Relationship |
|---|---|
| session-launcher | Scopes the session (what to build). Spec-compliance locks requirements within that scope. Use session-launcher first. |
| spec-guard | Enforces compliance at edit-time via hooks. Spec-compliance produces the spec that spec-guard enforces. |
| design-pro | Produces design rationale. Spec-compliance converts those decisions into locked requirements. |
references/deviation-risks.md - Common deviation risks by task
type (component, styling, API, data visualization) with specific
MUST NOT examples for eachreferences/example-spec.md - Complete before/after example
showing a natural-language spec converted to locked formatProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub travis-gilbert/claude-marketplace --plugin spec-compliance