# Review Requirements

> Review a concrete code change against its originating requirements and report missing, partial, incorrect, or unrequested behavior. Use when checking a PR, branch, commit, or WIP diff with an available request or spec. Do not use for defect-only code review, requirements drafting, or implementation.

- Skill: `bsafronov/review-requirements` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add bsafronov/review-requirements`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bsafronov/review-requirements/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: Apache-2.0
- Author: bsafronov (https://skillmd.com/u/bsafronov)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bsafronov/review-requirements

---


# Review Requirements

Determine whether a change delivers the agreed outcome and only that outcome.
Keep the review read-only.

1. Pin the change scope. Use the supplied comparison point; otherwise infer the
   current branch's merge base when unambiguous. Confirm the diff is non-empty.
2. Pin the requirements source from the user request, linked issue, PR, or named
   specification. Ask only when no authoritative source can be identified.
3. Extract every explicit behavior, constraint, and non-goal. Do not invent
   requirements from design preference.
4. Trace each requirement through changed code, tests, and affected boundaries.
   Classify it as satisfied, missing, partial, or incorrect. Identify behavior
   added outside the agreed scope.
5. Report actionable gaps first. For each gap, cite the requirement source and
   the smallest relevant changed location, then state expected behavior, actual
   behavior, and impact. Verify that every cited source path and one-based line
   exists; do not substitute diff line numbers for source line numbers.
6. If every requirement is satisfied, say so. Report material evidence gaps or
   unverifiable requirements separately.

Use `Missing`, `Partial`, `Incorrect`, and `Scope` as finding labels. Keep
the report limited to requirement-conformance gaps. Leave optional design advice
and unrelated defects to their separate review outcomes.

Stop when every explicit requirement and non-goal maps to implementation
evidence or an actionable finding, with no code changes made.

