spec-review

Validate design specs for completeness, traceability, and EARS-pattern acceptance criteria.

4|Updated Feb 9, 2021
One-click install
npx skills add https://github.com/breengles/poor-man-OS-setup --skill spec-review-breengles
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-review
Source: https://github.com/breengles/poor-man-OS-setup/tree/main/.claude/skills/spec-review
Command: npx skills add https://github.com/breengles/poor-man-OS-setup --skill spec-review-breengles

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents implementation delays by validating that a design spec is complete, acceptance-criteria compliant, and ready to execute.

Core Features & Use Cases

  • Requirements coverage validation: Ensures every numeric requirement ID in requirements.md is represented in design.md and that no design elements are orphaned.
  • EARS compliance review: Checks that acceptance criteria follow EARS patterns and are testable without leaking implementation details.
  • Clarification marker enforcement: Fails specs that still contain unresolved “[NEEDS CLARIFICATION:” markers in requirements.md or design.md.
  • Optional constitution alignment: If specs/constitution.md exists, verifies the design honors its principles or explicitly justifies deviations.

Quick Start

Use the spec-review skill with the feature name “my-feature” to review the spec located at specs/my-feature/.

Frequently Asked Questions about spec-review

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

FAQPage Schema
How do I validate requirements traceability between design and requirements markdown files?

To validate requirements traceability, ensure every numeric requirement ID in requirements.md is represented in design.md. The spec review process checks for orphaned design elements and enforces ID consistency to prevent implementation gaps.

What is EARS compliance for acceptance criteria and how do I enforce it in a spec review?

EARS compliance ensures acceptance criteria follow specific patterns and remain testable without leaking implementation details. A spec review validates your acceptance criteria against these EARS patterns to guarantee they are clear and executable.

How do I check a design spec for unresolved clarification markers before implementation?

Checking for unresolved clarification markers involves scanning requirements.md and design.md for "[NEEDS CLARIFICATION:" text. The spec review process fails any design spec containing these markers to block premature implementation.

Can I use a spec review to verify feature readiness against a project constitution?

Yes, if a specs/constitution.md file exists, the spec review verifies that your feature design honors its principles. The review will flag any deviations, requiring them to be explicitly justified before the spec passes.

What is the best way to structure feature-scoped specs for a complete technical readiness review?

Structure feature-scoped specs under specs/<feature-name>/ including requirements.md and design.md as mandatory files. You can also add optional tasks.md, research.md, and constitution.md to provide full context for the technical readiness review.

What happens when a design spec fails an EARS compliance or traceability review?

When a design spec fails review, the process produces a verdict summary with actionable FAILs. This summary highlights exact traceability gaps, EARS pattern violations, and unresolved markers needed to achieve technical readiness.