Lean PR Review

Perform a structured pull request review using §2 Review Mode conventions and §6 waste categories.

When to use

• The user asks to "review this PR", "review these changes", or "check my diff"
• The Review agent hands off a PR-scoped review task
• A pull request needs a quality gate before merge

When NOT to use

• The user wants a full architectural review (use Review Mode directly with the full codebase)
• The changes are a single-line typo fix (overkill — just approve)

Steps

1. Get the diff — Read the PR diff or the set of changed files. If working locally, use git diff main...HEAD or the equivalent for the target branch.

2. Scan each changed file — For every file in the diff, read the full file (not just the diff hunk) to understand context.

3. Classify each finding — For every issue found, record:

   [severity] | [file:line] | [waste category] | [description]
   

   Severity levels:

   • critical — blocks merge; security flaw, data loss risk, or broken functionality
   • major — should fix before merge; logic error, missing test, or significant smell
   • minor — nice to fix; style issue, naming, minor inefficiency
   • advisory — informational; suggestion for future improvement

   Waste categories (§6):

   • W1 Overproduction · W2 Waiting · W3 Transport · W4 Over-processing
   • W5 Inventory · W6 Motion · W7 Defects · W8 Unused talent

4. Check test coverage — Verify that new or changed behaviour has corresponding tests. Flag untested paths as major | W7 Defects.

5. Check for baseline breaches — Compare against §3 baselines:

   • File LOC limits (warn / hard)
   • Dependency budget (if deps were added)
   • Type errors (must be zero)

6. Produce the report — Format as:

   ## PR Review — <PR title or branch name>
   
   ### Summary
   <1–2 sentence overview of the changes and their quality>
   
   ### Findings (<N> total: <critical> critical, <major> major, <minor> minor, <advisory> advisory)
   
   #### Critical
   - [critical] | [file:line] | [W7] | <description>
   
   #### Major
   - [major] | [file:line] | [W4] | <description>
   
   #### Minor
   - [minor] | [file:line] | [W1] | <description>
   
   #### Advisory
   - [advisory] | [file:line] | [W8] | <description>
   
   ### Verdict
   <APPROVE / REQUEST CHANGES / COMMENT>
   

7. Wait — Do not apply fixes. Present the report and wait for the user to decide what to address.

Verify

• Every finding has all four fields: severity, file:line, waste category, description
• Critical findings are genuinely blocking (not inflated)
• Test coverage was checked for all new behaviour
• Baseline breaches are flagged
• Report ends with a clear verdict