evidence-backed-review

Installation
SKILL.md

Evidence-Backed Change Review

Core principle. Judge what changes, who relies on it, and what proves it is ready. Code is one artifact, not the boundary of the review.

Establish the request and its context

  1. Keep every requested concern. Record the request before choosing categories. A, B and C are owed back by name even when none has a dedicated rule. A checklist adds to the request, never replaces it.
  2. Read the PR itself. Obtain its actual target and source revisions, description, linked work items, relevant parent requirements, acceptance criteria, and comments recording scope decisions. Follow links through the available authorized reader; do not wait for the user to paste facts you can retrieve.
  3. Separate the delivery from the parent objective. Establish what this PR promises, what later changes deliver, and which parent constraints apply now. Do not require every PR to implement the entire epic. Do not let a narrow description waive a governing requirement.
  4. Resolve disagreements by authority and scope. The description is the author's claim, not independent proof. Read the applicable standard or approved decision, including outside this repository. Record conflicting descriptions or criteria; do not silently pick one. Preserve the source revision or date when available.
  5. Missing context limits a conclusion, not all review. Name the inaccessible item, what it prevents judging, and what you tried. Continue with inspectable risks. No work item linked is not itself a defect; inventing its requirements would be. Ask only for an unresolved decision or unavailable evidence that changes the judgment.

Separate scope from depth

State both in the opening line. Scope is what is under review; depth is how thoroughly it is examined.

Installs
35
First Seen
Aug 14, 2026