AI PR Review Methodology Skill
Overview
Evidence-based PR review using 4 phases and 5 analysis dimensions to catch false positives, redundant code, and unverified assumptions.
Prerequisites
- PR workflow knowledge and ability to read diffs
- Shell access and codebase access for verification
Instructions
Gather Context (Phase 1): Read phase-1-context-gathering. Read complete files (not just diffs), search for duplicates, understand root cause, verify all claims.
Structured Analysis (Phase 2): Read phase-2-structured-analysis, then apply dimensions D1-D5 in order:
- dimension-1-problem-verification
- dimension-2-redundancy-check
- dimension-3-system-integration
- dimension-4-senior-review
- dimension-5-false-positive-detection
Evidence Requirements (Phase 3): Compile missing evidence: Problem Demonstration, Solution Validation, Assumption Verification, Cross-Platform Testing.
Scenario Protocol (if applicable): Match PR type to the appropriate scenario:
- scenario-bug-fixes
- scenario-dependency-updates
- scenario-path-changes
- scenario-performance
Generate Review (Phase 4): Use review-output-template and run quick-reference-checklist before submitting.
Checklist
Copy this checklist and track your progress:
Output
| Section |
Content |
| Summary |
PR overview and overall assessment |
| Findings |
Strengths, questions, blocking red flags |
| Recommendation |
APPROVE / REQUEST CHANGES / COMMENT |
Output discipline: All scripts support --output-file <path>.
Error Handling
Non-zero exit codes on failure. See detailed guide in Resources.
Resources
phase-1-context-gathering — Phase 1: gather complete context before analysis
- 1.1 When to perform context gathering
- 1.2 Action 1: Read complete files, not just diffs
- 1.2.1 How to read complete files during a PR review
- 1.2.2 Example: Good vs bad context gathering
- 1.3 Action 2: Search for existing solutions and duplicates
- 1.3.1 How to search for duplicates before analyzing a PR
- 1.3.2 Example: Discovering an existing solution
- 1.4 Action 3: Understand the problem (root cause vs symptoms)
- 1.4.1 How to distinguish root cause from symptoms
- 1.4.2 Example: Symptom-level vs root-cause understanding
- 1.5 Action 4: Verify all claims made in the PR
- 1.5.1 How to verify file path claims
- 1.5.2 How to verify command availability claims
- 1.5.3 Example: Verifying a claimed installation path
- 1.6 Completion checkpoint for Phase 1
phase-2-structured-analysis — Phase 2: apply the 5-dimension analysis framework
- 2.1 When to use the structured analysis framework
- 2.2 Overview of the 5 analysis dimensions
- 2.3 How to apply the dimensions sequentially
- 2.4 How to flag items requiring author evidence
- 2.5 Cross-references to each dimension file
dimension-1-problem-verification — D1: verify the problem and root cause
- D1.1 When to apply problem verification
- D1.2 Identifying the exact error message or unexpected behavior
- D1.3 Determining root cause vs treating symptoms
- D1.4 Verifying the fix addresses the root cause
- D1.5 Documenting assumptions about the system and environment
- D1.6 Testing methodology: before/after, multi-platform, edge cases, automated tests
- D1.7 Red flags that indicate problem verification failure
- D1.8 Example: A fix that treats symptoms vs one that addresses root cause
dimension-2-redundancy-check — D2: detect redundant or duplicate code
- D2.1 When to apply redundancy checking
- D2.2 Searching for similar patterns in the codebase
- D2.3 Identifying when existing code already handles the case
- D2.4 List and array addition analysis: priority order and placement justification
- D2.5 Configuration changes vs code changes
- D2.6 Red flags for redundancy
- D2.7 Example: Detecting a redundant path addition
dimension-3-system-integration — D3: validate system integration and paths
- D3.1 When to apply system integration validation
- D3.2 File path verification on target systems (macOS, Linux, Windows)
- D3.3 Cross-referencing paths with official documentation
- D3.4 Path handling: home directory expansion, relative vs absolute, platform-specific
- D3.5 Installation location accuracy across package managers
- D3.6 Red flags for integration failures
- D3.7 Example: Validating a claimed binary installation path
dimension-4-senior-review — D4: senior-developer architectural review
- D4.1 When to apply senior developer review criteria
- D4.2 Architectural layer assessment
- D4.3 Technical debt and maintainability evaluation
- D4.4 Performance and resource implications
- D4.5 Security implications analysis
- D4.6 Backwards compatibility assessment
- D4.7 Red flags for architectural concerns
- D4.8 Example: Evaluating a quick fix for long-term impact
dimension-5-false-positive-detection — D5: detect false-positive fixes
- D5.1 When to apply false positive detection
- D5.2 Assumption identification and verification
- D5.3 Alternative explanation analysis
- D5.4 Placebo effect check methodology
- D5.5 Cargo cult programming detection
- D5.6 Confirmation bias detection
- D5.7 The ultimate test: reversibility verification
- D5.8 Red flags for false positives
- D5.9 Example: A false-positive bug fix with before/after analysis
scenario-bug-fixes — Scenario protocol: reviewing bug-fix PRs
- S-BUG.1 When to use this scenario protocol
- S-BUG.2 Original error identification
- S-BUG.3 Root cause identification requirements
- S-BUG.4 Reproduction before the fix
- S-BUG.5 Fix demonstration
- S-BUG.6 Regression test requirement
- S-BUG.7 Example: Reviewing a bug fix PR end-to-end
scenario-dependency-updates — Scenario protocol: reviewing dependency updates
- S-DEP.1 When to use this scenario protocol
- S-DEP.2 Justification requirements for new or updated dependencies
- S-DEP.3 Security vulnerability scanning
- S-DEP.4 License compatibility checking
- S-DEP.5 Bundle size and performance impact assessment
- S-DEP.6 Checking for alternatives using existing dependencies
- S-DEP.7 Example: Reviewing a PR that adds a new npm package
scenario-path-changes — Scenario protocol: reviewing path/location changes
- S-PATH.1 When to use this scenario protocol
- S-PATH.2 Mandatory verification steps for path changes
- S-PATH.3 Verification commands to request from the author
- S-PATH.4 Evidence requirements specific to path changes
- S-PATH.5 Example: Reviewing a PR that adds a new binary search path
scenario-performance — Scenario protocol: reviewing performance changes
- S-PERF.1 When to use this scenario protocol
- S-PERF.2 Benchmark requirements (before and after)
- S-PERF.3 Multiple test runs and statistical significance
- S-PERF.4 Verifying no functionality regressions
- S-PERF.5 Significance justification (complexity vs improvement tradeoff)
- S-PERF.6 Example: Reviewing a caching optimization PR
review-output-template — Review output format
- T.1 When to generate the review output
- T.2 The complete review output template (copy-paste ready)
- T.3 How to fill each section of the template
- T.4 Choosing the final recommendation: APPROVE, REQUEST CHANGES, or COMMENT
- T.5 Setting the confidence level: High, Medium, or Low
- T.6 Writing the author note
- T.7 Example: A completed review output
quick-reference-checklist — 12-item pre-approval checklist
- C.1 When to use this checklist
- C.2 The 12-item pre-approval checklist
- C.3 How to handle checklist failures
- C.4 Example: Walking through the checklist for a sample PR
detailed-guide — Full methodology reference
Examples
gh pr diff 42 > /tmp/pr42.diff
gh pr view 42 --json title,body,files
# Apply D1-D5 dimensions, compile evidence, generate review
gh pr review 42 --body "## Summary\nReviewed with AI PR methodology.\n### Recommendation: APPROVE"
1---2name: amia-ai-pr-review-methodology3description: Use when performing structured AI-driven PR reviews — 8-dimensional rubric (correctness, security, performance, test coverage, maintainability, docs, style, dependencies) with verdict ladder (approve/request-changes/comment) and severity classification. Trigger with /amia-ai-pr-review, 'review this PR', or any PR-evaluation request. Loaded by ai-maestro-integrator-agent-main-agent.4license: MIT5---67# AI PR Review Methodology Skill89## Overview1011Evidence-based PR review using 4 phases and 5 analysis dimensions to catch false positives, redundant code, and unverified assumptions.1213## Prerequisites1415- PR workflow knowledge and ability to read diffs16- Shell access and codebase access for verification1718## Instructions19201. **Gather Context (Phase 1):** Read [phase-1-context-gathering](references/phase-1-context-gathering.md). Read complete files (not just diffs), search for duplicates, understand root cause, verify all claims.21222. **Structured Analysis (Phase 2):** Read [phase-2-structured-analysis](references/phase-2-structured-analysis.md), then apply dimensions D1-D5 in order:23 - [dimension-1-problem-verification](references/dimension-1-problem-verification.md)24 - [dimension-2-redundancy-check](references/dimension-2-redundancy-check.md)25 - [dimension-3-system-integration](references/dimension-3-system-integration.md)26 - [dimension-4-senior-review](references/dimension-4-senior-review.md)27 - [dimension-5-false-positive-detection](references/dimension-5-false-positive-detection.md)28293. **Evidence Requirements (Phase 3):** Compile missing evidence: Problem Demonstration, Solution Validation, Assumption Verification, Cross-Platform Testing.30314. **Scenario Protocol (if applicable):** Match PR type to the appropriate scenario:32 - [scenario-bug-fixes](references/scenario-bug-fixes.md)33 - [scenario-dependency-updates](references/scenario-dependency-updates.md)34 - [scenario-path-changes](references/scenario-path-changes.md)35 - [scenario-performance](references/scenario-performance.md)36375. **Generate Review (Phase 4):** Use [review-output-template](references/review-output-template.md) and run [quick-reference-checklist](references/quick-reference-checklist.md) before submitting.3839### Checklist4041Copy this checklist and track your progress:4243- [ ] Read complete files, not just the diff44- [ ] Search for existing solutions and duplicates45- [ ] Verify all claims and understand root cause46- [ ] Apply all 5 analysis dimensions (D1-D5)47- [ ] Compile missing evidence list48- [ ] Apply scenario-specific protocol if applicable49- [ ] Generate structured review using the template5051## Output5253| Section | Content |54|---------|---------|55| Summary | PR overview and overall assessment |56| Findings | Strengths, questions, blocking red flags |57| Recommendation | APPROVE / REQUEST CHANGES / COMMENT |5859> **Output discipline:** All scripts support `--output-file <path>`.6061## Error Handling6263Non-zero exit codes on failure. See detailed guide in Resources.6465## Resources6667- [phase-1-context-gathering](references/phase-1-context-gathering.md) — Phase 1: gather complete context before analysis68 - 1.1 When to perform context gathering69 - 1.2 Action 1: Read complete files, not just diffs70 - 1.2.1 How to read complete files during a PR review71 - 1.2.2 Example: Good vs bad context gathering72 - 1.3 Action 2: Search for existing solutions and duplicates73 - 1.3.1 How to search for duplicates before analyzing a PR74 - 1.3.2 Example: Discovering an existing solution75 - 1.4 Action 3: Understand the problem (root cause vs symptoms)76 - 1.4.1 How to distinguish root cause from symptoms77 - 1.4.2 Example: Symptom-level vs root-cause understanding78 - 1.5 Action 4: Verify all claims made in the PR79 - 1.5.1 How to verify file path claims80 - 1.5.2 How to verify command availability claims81 - 1.5.3 Example: Verifying a claimed installation path82 - 1.6 Completion checkpoint for Phase 18384- [phase-2-structured-analysis](references/phase-2-structured-analysis.md) — Phase 2: apply the 5-dimension analysis framework85 - 2.1 When to use the structured analysis framework86 - 2.2 Overview of the 5 analysis dimensions87 - 2.3 How to apply the dimensions sequentially88 - 2.4 How to flag items requiring author evidence89 - 2.5 Cross-references to each dimension file9091- [dimension-1-problem-verification](references/dimension-1-problem-verification.md) — D1: verify the problem and root cause92 - D1.1 When to apply problem verification93 - D1.2 Identifying the exact error message or unexpected behavior94 - D1.3 Determining root cause vs treating symptoms95 - D1.4 Verifying the fix addresses the root cause96 - D1.5 Documenting assumptions about the system and environment97 - D1.6 Testing methodology: before/after, multi-platform, edge cases, automated tests98 - D1.7 Red flags that indicate problem verification failure99 - D1.8 Example: A fix that treats symptoms vs one that addresses root cause100101- [dimension-2-redundancy-check](references/dimension-2-redundancy-check.md) — D2: detect redundant or duplicate code102 - D2.1 When to apply redundancy checking103 - D2.2 Searching for similar patterns in the codebase104 - D2.3 Identifying when existing code already handles the case105 - D2.4 List and array addition analysis: priority order and placement justification106 - D2.5 Configuration changes vs code changes107 - D2.6 Red flags for redundancy108 - D2.7 Example: Detecting a redundant path addition109110- [dimension-3-system-integration](references/dimension-3-system-integration.md) — D3: validate system integration and paths111 - D3.1 When to apply system integration validation112 - D3.2 File path verification on target systems (macOS, Linux, Windows)113 - D3.3 Cross-referencing paths with official documentation114 - D3.4 Path handling: home directory expansion, relative vs absolute, platform-specific115 - D3.5 Installation location accuracy across package managers116 - D3.6 Red flags for integration failures117 - D3.7 Example: Validating a claimed binary installation path118119- [dimension-4-senior-review](references/dimension-4-senior-review.md) — D4: senior-developer architectural review120 - D4.1 When to apply senior developer review criteria121 - D4.2 Architectural layer assessment122 - D4.3 Technical debt and maintainability evaluation123 - D4.4 Performance and resource implications124 - D4.5 Security implications analysis125 - D4.6 Backwards compatibility assessment126 - D4.7 Red flags for architectural concerns127 - D4.8 Example: Evaluating a quick fix for long-term impact128129- [dimension-5-false-positive-detection](references/dimension-5-false-positive-detection.md) — D5: detect false-positive fixes130 - D5.1 When to apply false positive detection131 - D5.2 Assumption identification and verification132 - D5.3 Alternative explanation analysis133 - D5.4 Placebo effect check methodology134 - D5.5 Cargo cult programming detection135 - D5.6 Confirmation bias detection136 - D5.7 The ultimate test: reversibility verification137 - D5.8 Red flags for false positives138 - D5.9 Example: A false-positive bug fix with before/after analysis139140- [scenario-bug-fixes](references/scenario-bug-fixes.md) — Scenario protocol: reviewing bug-fix PRs141 - S-BUG.1 When to use this scenario protocol142 - S-BUG.2 Original error identification143 - S-BUG.3 Root cause identification requirements144 - S-BUG.4 Reproduction before the fix145 - S-BUG.5 Fix demonstration146 - S-BUG.6 Regression test requirement147 - S-BUG.7 Example: Reviewing a bug fix PR end-to-end148149- [scenario-dependency-updates](references/scenario-dependency-updates.md) — Scenario protocol: reviewing dependency updates150 - S-DEP.1 When to use this scenario protocol151 - S-DEP.2 Justification requirements for new or updated dependencies152 - S-DEP.3 Security vulnerability scanning153 - S-DEP.4 License compatibility checking154 - S-DEP.5 Bundle size and performance impact assessment155 - S-DEP.6 Checking for alternatives using existing dependencies156 - S-DEP.7 Example: Reviewing a PR that adds a new npm package157158- [scenario-path-changes](references/scenario-path-changes.md) — Scenario protocol: reviewing path/location changes159 - S-PATH.1 When to use this scenario protocol160 - S-PATH.2 Mandatory verification steps for path changes161 - S-PATH.3 Verification commands to request from the author162 - S-PATH.4 Evidence requirements specific to path changes163 - S-PATH.5 Example: Reviewing a PR that adds a new binary search path164165- [scenario-performance](references/scenario-performance.md) — Scenario protocol: reviewing performance changes166 - S-PERF.1 When to use this scenario protocol167 - S-PERF.2 Benchmark requirements (before and after)168 - S-PERF.3 Multiple test runs and statistical significance169 - S-PERF.4 Verifying no functionality regressions170 - S-PERF.5 Significance justification (complexity vs improvement tradeoff)171 - S-PERF.6 Example: Reviewing a caching optimization PR172173- [review-output-template](references/review-output-template.md) — Review output format174 - T.1 When to generate the review output175 - T.2 The complete review output template (copy-paste ready)176 - T.3 How to fill each section of the template177 - T.4 Choosing the final recommendation: APPROVE, REQUEST CHANGES, or COMMENT178 - T.5 Setting the confidence level: High, Medium, or Low179 - T.6 Writing the author note180 - T.7 Example: A completed review output181182- [quick-reference-checklist](references/quick-reference-checklist.md) — 12-item pre-approval checklist183 - C.1 When to use this checklist184 - C.2 The 12-item pre-approval checklist185 - C.3 How to handle checklist failures186 - C.4 Example: Walking through the checklist for a sample PR187188- [detailed-guide](references/detailed-guide.md) — Full methodology reference189 - [4 Phases Overview](#4-phases-overview)190 - [5 Analysis Dimensions](#5-analysis-dimensions)191 - [Key Principle](#key-principle)192 - [Evidence Requirements](#evidence-requirements)193 - [Scenario-Specific Protocols](#scenario-specific-protocols)194 - [Troubleshooting](#troubleshooting)195 - [Error Handling](#error-handling)196 - [Extended Examples](#extended-examples)197 - [Related Skills](#related-skills)198199## Examples200201```bash202gh pr diff 42 > /tmp/pr42.diff203gh pr view 42 --json title,body,files204# Apply D1-D5 dimensions, compile evidence, generate review205gh pr review 42 --body "## Summary\nReviewed with AI PR methodology.\n### Recommendation: APPROVE"206```