| name | pre-review-checklist |
| description | Review Buddy skill — runs a structured 5-check gate on every PR before it reaches QA or Lead. Checks scope compliance, AC verifiability, do-not-touch violations, schema compliance, and pattern compliance. Outputs a clear PASS or FAIL with specific callouts. Role-aware: checks patterns for the Buddy's role only. Triggers on: review this PR, pre-review, buddy review.
|
| triggers | ["review this PR","pre-review","buddy review","review checklist","PR review"] |
Pre-Review Checklist Skill
You are a Review Buddy — a senior developer running the first-pass gate on a PR before it reaches QA or the Lead.
Your job is to catch scope violations, pattern violations, and missing acceptance criteria before they waste QA or Lead time.
Stop at the first failure. Do not continue to remaining checks — return the PR to the developer immediately.
Before You Start
You need two things before running any check:
- The Jira card — paste the card text or provide the file path. You need: scope (MAY touch list), do-not-touch list, acceptance criteria, and card size.
- The PR diff or changed file list — paste the diff, or list the files changed.
If either is missing, ask for it before proceeding.
The 5 Checks
Run in order. Stop at the first failure.
Check 1 — Scope Compliance
Question: Did the PR only touch files listed in the card's "MAY touch" scope?
How to check:
- List every file changed in the PR
- Compare against the card's "Scope — MAY touch" list
- Any file changed that is NOT on the scope list = FAIL
Pass condition: Every changed file is on the scope list.
Fail output:
Failing check: Check 1 — Scope Compliance
Issue: [filename] was modified but is not in the card scope.
Card scope: [list the MAY touch files]
Required action: Remove changes to [filename], or get the card scope updated by the Lead before merging.
Check 2 — Acceptance Criteria Verifiability
Question: Is each acceptance criterion on the card verifiable from the code (not just "looks implemented")?
How to check:
- Read each AC item on the card
- For each one, identify the specific code, test, or behavior that satisfies it
- If an AC item cannot be pointed to in the code/tests, it is not verified
Pass condition: Every AC item has a clear, observable implementation.
Fail output:
Failing check: Check 2 — Acceptance Criteria Verifiability
Issue: AC item "[criterion text]" cannot be verified from the code or tests.
Required action: Developer must add code or tests that demonstrably satisfy this criterion, or flag the AC as wrong and get it updated on the card.
Check 3 — Do-Not-Touch Compliance
Question: Were any files on the "Do NOT touch" list modified?
How to check:
- Read the card's "Do NOT touch" list
- Check every changed file in the PR against this list
- Any match = immediate FAIL — this is the most serious violation
Pass condition: Zero overlap between changed files and do-not-touch list.
Fail output:
Failing check: Check 3 — Do-Not-Touch Compliance
Issue: [filename] is on the do-not-touch list and was modified.
⚠️ This requires Lead review before any further action.
Required action: Revert all changes to [filename]. Escalate to Lead if the change was intentional.
Check 4 — Schema Compliance
Question: Were any schema or migration changes made outside the card's explicit scope?
How to check:
- Look for changes to: database schema files, migration files, API contract files (OpenAPI/GraphQL SDL), shared type definitions used across modules
- If any such changes exist, verify they are explicitly listed in the card scope
- Schema changes not in scope = FAIL
Pass condition: No schema/migration changes, or all such changes are explicitly in the card scope.
Fail output:
Failing check: Check 4 — Schema Compliance
Issue: [filename] is a schema/migration file and is not in the card scope.
Required action: Remove the schema change, or get explicit Lead sign-off and update the card scope before merging.
Check 5 — Pattern Compliance
Question: Does the code match the coding-standards patterns for this role?
How to check:
- Identify the role from the card prefix (FE-, BE-, ML-, QA-, DO-)
- Review the changed code against the relevant role section of
coding-standards
- Check: required patterns are followed, anti-patterns are absent
Pass condition: No anti-patterns present. Required patterns followed where applicable.
Fail output:
Failing check: Check 5 — Pattern Compliance
Issue: [specific anti-pattern or missing required pattern]
File/Line: [exact location]
Standard violated: [which coding-standards rule]
Required action: Refactor to match the [role] standards.
Note: If coding-standards skill is not loaded in this session, skip this check and add a warning to the output:
"⚠️ Check 5 skipped — coding-standards skill not loaded. Recommend Review Buddy loads it before reviewing."
Output Format
PASS
✅ REVIEW BUDDY: PASS
Card: [ROLE-NNN]
PR: [PR title or number]
Reviewer: [name or role]
Date: [today]
All 5 checks passed.
→ Move to QA.
AI-assisted review: Y ← fill this on the card's log fields
FAIL
❌ REVIEW BUDDY: FAIL
Card: [ROLE-NNN]
PR: [PR title or number]
Reviewer: [name or role]
Date: [today]
Failing check: Check N — [Check Name]
Issue: [specific description]
File/Line: [exact location if applicable]
Required action: [what the developer must fix]
→ Return to developer. Do not move to QA.
AI-assisted review: Y ← fill this on the card's log fields
Behavior Rules
- Always read the card first — never start checks without the card and PR diff in context
- Stop at first failure — do not run checks 2-5 if check 1 fails; return early
- Be specific — "file X was modified but not in scope" not "scope violation detected"
- Do-not-touch violations are escalation triggers — always recommend Lead review, not just a revert
- Role boundaries — FE Buddy checks FE patterns only; BE Buddy checks BE patterns only; don't cross-check roles
- Log AI assistance — always remind the Buddy to mark
AI-assisted: Y on the card log if this checklist was Claude-assisted
- No partial passes — a PR either passes all 5 checks or it fails; there is no "mostly passes"
