SDD review when implementation must be audited against PRD, TechSpec, and tasks, in a session or fresh-context subagent that did not write that code; does not correct findings.
Installs into .claude/skills of the current project.
Are you the author of Sdd Review Code?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/dougcunha-sdd-review-code)
---
name: sdd-review-code
description: SDD review when implementation must be audited against PRD, TechSpec, and tasks, in a session or fresh-context subagent that did not write that code; does not correct findings.
argument-hint: --prd feature-name [--base git-reference]
---
# Review SDD code
Run in a session that did not write or change the code under review, or as a delegated reviewer: a fresh-context subagent the authoring session launches under the protocol in [references/delegated-review.md](references/delegated-review.md), whose contract applies together with this skill. This session consolidates the matrix and writes the report; its subagents are read-only explorers for disjoint inspections. If this session authored any of that code, stop before step 1 and apply the independence rule from `.agents/skills/sdd-orchestrate-tasks/references/session-continuity.md`, which delegates the review or recommends ending the session; if the user continues in the authoring session anyway, record the missing independence under the report's limitations.
1. Require `prd.md`, `techspec.md`, and `tasks.md` under `tasks/prd-[slug]/`. When `context-snapshot.md` exists, load it through the Load branch of `.agents/skills/sdd-snapshot/SKILL.md` as an independent stage. Read PRD and TechSpec once per version; then manifest, tasks, and handoffs. Check every link, extra file, ID, state, and dependency.
**Output:** every task has proven location and state; a missing source blocks review with the exact path.
2. Bound the implementation by `--base` resolved to a commit, including relevant committed, staged, unstaged, and new files. Without a base, use handoffs and worktree; state the scope limitation. In a re-review, include correction reports and handoffs without altering history.
**Output:** reviewable set identified. An invalid base requests correction and never silently changes scope.
3. Build a matrix of every obligation: origin, implementation, test, state, and evidence. Reuse IDs; read each task's details according to its criteria without transcribing sources. Mark `conformant`, `non-conformant`, `pending`, or `not verifiable`. Disjoint slices of the matrix may go to parallel read-only explorers that return states with `path:line` evidence; verify the evidence a finding will rest on, and do not treat a slice without findings as approval of the whole.
**Output:** no orphan obligation; incomplete tasks, broken links, and acceptance without evidence remain gaps.
4. Trace callers, effects, contracts, errors, and risks in changed paths, sending explorers only for sweeps across many files; consult `AGENTS.md` and relevant skills. Check commands and results; reuse execution proven for the same code, configuration, and environment, running missing or invalidated checks in this session and serializing those that share `bin/`, `obj/`, or `TestResults/`.
Run all TechSpec quality profile commands over the reviewable set, blocking and reservation, and subtract the Terrain baseline: debt that existed before the feature is not a finding of this review, and treating it as one hides what the implementation actually introduced. Conformance with acceptance and tests does not replace the profile: a diff that meets every obligation and still carries a new, unjustified blocking hit has a defect. A TechSpec without a quality profile or without a baseline is a gap recorded in limitations, not an empty profile or a zeroed baseline.
In desktop C#/.NET, omit E2E and record the policy, including for inherited commands. Omission is neither a defect nor approved testing; check unit, integration, and manual acceptance evidence required by the TechSpec. Unexecuted essential manual work is `not verifiable`.
**Output:** states supported by evidence or an explicit limitation; zero tests do not prove acceptance.
5. Number findings `CR-01`, `CR-02` within this review. Record origin, fact, file, symbol, and line, impact, severity, and evidence. Recommend a correction only with a proven cause. Identify a prior finding by review path + ID and mark it resolved, persistent, or not verifiable.
A blocking profile hit becomes a finding with the `QA-NN` rule as its origin; a reservation hit becomes an optional improvement with the same traceability. Count the feature's reservations and, when a profile trigger fires, record in the escalation section the relevant skill and the number that justifies it — as a suggestion to the HIL, never executed in this review.
**Output:** actionable findings distinct from optional improvements; all verifiable without conversation history; escalation suggested only with a counted trigger.
6. Read [references/TEMPLATE.md](references/TEMPLATE.md) in full when issuing the report. Reserve the next free numeric suffix under `codereview_[num]/`, considering all existing folders. Write a new `codereview.md`; preserve code, tasks, and previous reports.
As a delegated reviewer, write into the folder the caller reserved instead of reserving another, record the execution as `delegated reviewer`, and return under the contract, without a session pause. In standalone use, run the session pause; a snapshot written then records stage `review`, the report in `covers_through`, `authored_code: no`, and the status as an open thread. Because this session changed no code, it may continue into `sdd-plan-corrections`.
**Output:** immutable report with matrix, findings, validations, limitations, and status below; report path and blocks.
## Status
- `APPROVED`: all obligations conformant, tasks complete, links intact, required validations proven, and no unjustified blocking quality profile hit.
- `APPROVED WITH RESERVATIONS`: only optional improvements, including profile reservation hits, with no requirement, security, or essential evidence pending.
- `REJECTED`: any non-conformant or incomplete obligation, inconsistent state, failing mandatory test, missing essential evidence, or blocking profile hit not covered by `DEC-NN`.
If sources or code change during review, revalidate the affected part before the opinion. A missing environment records command, error, and affected IDs, without turning missing evidence into approval.