sdlc-review

Reviews code changes against specifications and project standards, then writes findings to state.

Updated Jun 1, 2026
One-click install
npx skills add https://github.com/juartaurus98/codebase --skill sdlc-review-juartaurus98
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sdlc-review
Source: https://github.com/juartaurus98/codebase/tree/main/.claude/skills/sdlc-review
Command: npx skills add https://github.com/juartaurus98/codebase --skill sdlc-review-juartaurus98

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often collapse into style opinions or miss whether the change actually implements its specification. This Skill enforces a spec-first review of diffs, files, or features against the project's production standards, and routes findings into the development loop so nothing gets lost. ## Core Features & Use Cases - Spec-first review: Checks whether a change satisfies its .feature scenarios, SRS requirements, and techdoc component map before evaluating style, architecture, SOLID, DRY, and test quality. - Findings routed to state: Every finding becomes a structured row with severity, category, and a route_to target so the SDLC loop can act on it; blocker and major findings block the G6 gate. - AI prompt review: When the change involves LLM prompts, it validates version bumps, guardrails, token budgets, cost, latency, and eval deltas against baseline. - Use Case: After finishing a feature branch, invoke /review with the FEAT-ID to get a ship/revise/block verdict report with concrete fix diffs, without the reviewer ever modifying your code. ## Quick Start Ask the AI to run /review on the staged changes to verify they meet the specification and production standards before opening a pull request.

Frequently Asked Questions about sdlc-review

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

FAQPage Schema
How do I review a code change against its specification before merging?▼

Invoke /review with a path, FEAT-ID, or 'staged' to target the change. The review first checks whether the code satisfies its .feature scenarios and SRS requirements, then evaluates architecture, style, and test quality, producing a ship, revise, or block verdict.

What does the /review command check in a code review?▼

It checks specification compliance first, then architecture layering, SOLID, DRY, KISS, YAGNI, naming, types, error handling, and test quality. It also runs the project's own lint, format check, typecheck, test, and coverage tools and quotes their real output.

Can an automated code review modify my code during review?▼

No. This review is strictly read-only: the delegated quality-guardian agent has Read, Grep, Glob, and Bash but no Write or Edit permissions. It proposes fix diffs in the report but never applies changes.

How are code review findings tracked and routed?▼

Every finding is written as a structured row with id, severity, category, and a route_to target from the framework's loop_routes. Blocker and major findings block the G6 gate and drive a loop-back; minor and nit findings are carried as tech debt.

Does the review handle LLM prompt changes?▼

Yes. When the change involves AI prompts, it verifies version bumps rather than in-place edits, input guardrails, output validation, token budgets, cost and p95 latency against spec, and the eval delta versus baseline.

What happens if tests were not run before the review?▼

The review proceeds in PARTIAL state but explicitly reports that test results were unavailable rather than implying the change is untested. Any check that could not run is reported as unknown, never as a pass.