spec-review

Reviews implementation plans against architecture docs and repository code before coding begins.

4|Updated Jul 30, 2026
One-click install
npx skills add https://github.com/gabriellst/codm --skill spec-review-gabriellst
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-review
Source: https://github.com/gabriellst/codm/tree/main/.claude/skills/spec-review
Command: npx skills add https://github.com/gabriellst/codm --skill spec-review-gabriellst

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Implementation plans often contain hidden architecture violations, contract mismatches, and assumptions about SDK hooks or types that do not exist, which surface only after code is written. This Skill validates a plan against architecture documentation and the actual repository state before any implementation starts, catching design issues early. ## Core Features & Use Cases - Architecture Compliance Review: Maps each plan item to mandatory rules extracted from docs like BACKEND.md, FRONTEND.md, and CLAUDE.md, flagging violations with severity levels. - Repository Reality Checks: Verifies that planned SDK hooks, types, route structures, and exports actually exist in the current codebase rather than trusting plan assumptions. - Cross-Layer Compatibility Checks: Runs explicit checks between backend contracts and frontend forms, query signatures, search schemas, and verification gates. - Use Case: Before starting a new feature in a monorepo, run this Skill on the implementation plan to receive severity-ordered findings, open questions, and concrete corrections, then iterate until no critical gaps remain. ## Quick Start Ask the AI to review your implementation plan for architectural compliance before you begin coding.

Frequently Asked Questions about spec-review

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

FAQPage Schema
How do I review an implementation plan before coding?

Break the plan into explicit items with phase, layer, and expected artifacts, then map each item to architecture rules from your docs. Validate every assumed hook, type, and route against the actual repository before approving the plan.

How to check if a plan matches backend and frontend contracts?

Run cross-layer compatibility checks comparing backend contract fields against frontend form and query fields, and verify planned SDK hook names against the generated SDK type definitions. Mismatches in naming or signatures are flagged as findings.

When should I use plan review instead of code review?

Use plan review before any implementation starts to catch design issues, contract mismatches, and missing steps early. Code review applies to already-implemented diffs and cannot prevent architectural rework caused by a flawed plan.

What severity levels should plan review findings use?

Use Critical for plans that cannot be implemented correctly or violate high-severity architecture rules, Moderate for regression risks or missing required steps, and Low for non-blocking convention drift or incomplete details.

Why does a plan fail validation even when it looks complete?

Plans often assume SDK exports, hook names, or route structures that do not exist in the repository. Reality checks against generated type definitions and current files expose these fragile assumptions that documentation alone cannot catch.