Trigger with /eia-ai-pr-review. Use when performing deep evidence-based PR reviews, investigating false-positive fixes, or validating integration changes.
Instalação
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Trigger with /eia-ai-pr-review. Use when performing deep evidence-based PR reviews, investigating false-positive fixes, or validating integration changes.
license
Apache-2.0
compatibility
Requires intermediate software development experience and familiarity with code review basics. Designed for reviewers performing deep, evidence-based pull request reviews using a 4-phase, 5-dimension evaluation framework. Requires access to the full codebase and ability to run verification commands.
triggers
["Perform a deep evidence-based PR review","Investigate whether a PR fix is a false positive","Validate system integration changes in a pull request","Review a complex PR with file path or environment changes","Check a bug fix PR for root cause verification","Assess a performance improvement PR with benchmark evidence","Review a dependency update PR for redundancy and security","Catch cargo cult programming or unverified assumptions in a PR"]
metadata
{"author":"Emasoft","version":"1.0.0"}
agent
eia-main
context
fork
workflow-instruction
Step 21
procedure
proc-deep-pr-review
user-invocable
false
AI PR Review Methodology Skill
Overview
This skill teaches a systematic, evidence-based approach to reviewing pull requests. It is organized into 4 sequential phases and 5 analysis dimensions. The methodology is designed to catch false positives (changes that appear to fix a problem but do not), redundant code, unverified assumptions, and cargo cult programming before they are merged into the main branch.
The 4 phases are:
Context Gathering -- Mandatory preparation before any analysis begins. Read complete files, search for duplicates, understand the problem, and verify claims.
Structured Analysis -- Apply 5 analysis dimensions systematically to evaluate the PR.
Evidence Requirements -- Determine what evidence is missing and must be provided by the author before the PR can be approved.
Review Output -- Synthesize findings into a structured, actionable review document.
The 5 analysis dimensions (applied in Phase 2) are:
Problem Verification -- Confirm the PR addresses the real root cause, not just symptoms.
Redundancy Check -- Ensure the change does not duplicate existing functionality.
System Integration Validation -- Verify paths, commands, and environment assumptions are correct on all target platforms.
False Positive Detection -- Challenge assumptions, detect cargo cult programming, and apply the ultimate reversibility test.
Key Principle
Every claim in a PR must be backed by evidence. "It works on my machine" is not evidence. "Here is the output of the verification command on three target platforms" is evidence.
Prerequisites
Before using this skill, you should be familiar with:
Table of Contents for dimension-5-false-positive-detection.md:
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
Step 3: Determine Evidence Requirements (Phase 3)
Based on your analysis in Step 2, compile a list of evidence the author must provide. Use the evidence categories described in Phase 1 and the dimension-specific red flags. Every flagged item from Step 2 that lacks evidence becomes a required evidence item.
The minimum required evidence categories are:
Problem Demonstration -- Error message, stack trace, or screenshot; reproduction steps; root cause explanation.
Solution Validation -- Demonstration that the fix resolves the issue; test coverage; before/after comparison.
Assumption Verification -- For file paths: output of ls or equivalent. For commands: output showing availability. For system behavior: documentation links or code proof.
Cross-Platform Testing -- Results on all supported platforms; platform-specific edge cases handled.
The PR has too many file changes to review thoroughly
Break the review into logical groups of related files. Apply Phase 1 (context gathering) to each group separately. Focus the 5 dimensions on the files most likely to contain issues: files with path changes, configuration changes, or security-sensitive code. See phase-1-context-gathering.md section 1.2 for guidance on prioritizing which files to read in full.
The author cannot reproduce the reported bug
This is a red flag for false positive detection. See dimension-5-false-positive-detection.md section D5.4 (placebo effect check) and D5.7 (the ultimate reversibility test). If the bug cannot be reproduced, the fix cannot be validated. Request reproduction steps and evidence before proceeding.
The PR modifies paths but the reviewer has no access to the target system
Request the author to provide terminal output (ls -la, which, type, or equivalent commands) showing the paths exist on each supported platform. See scenario-path-changes.md section S-PATH.3 for the specific verification commands to request.
The reviewer is unsure whether a change is redundant
See dimension-2-redundancy-check.md section D2.2 for search strategies to find existing code that might already handle the case. If you find a potential duplicate, ask the author to explain why the existing solution is insufficient.
The author becomes defensive when asked for evidence
Reiterate that evidence requirements are standard practice, not personal criticism. Frame questions as "help me understand" rather than "prove you are right." See review-output-template.md section T.6 for guidance on writing constructive author notes.
The PR is a dependency update with no visible code changes
Even if the code diff is small, dependency updates require their own review protocol. See scenario-dependency-updates.md for the full checklist including security scanning, license checking, and bundle size assessment.
Error Handling
Error: Reviewer skips Phase 1 and jumps directly to analysis
Skipping context gathering (Phase 1) leads to incorrect conclusions because the reviewer is working from partial information (the diff alone). Resolution: Always complete all 4 actions in phase-1-context-gathering.md before writing any analysis. If you realize mid-review that you skipped context gathering, stop the analysis, go back to Phase 1, and restart from Step 1.
Error: Conflicting findings across analysis dimensions
When Dimension 1 (Problem Verification) says the fix is correct but Dimension 5 (False Positive Detection) flags it as a potential false positive, this is not a contradiction -- it means the fix addresses the symptom but may not address the root cause. Resolution: Apply the reversibility test from dimension-5-false-positive-detection.md section D5.7. If removing the change brings the problem back, the fix is real. If it does not, the fix is a false positive regardless of what Dimension 1 found.
Error: Insufficient evidence to complete the review
When the PR lacks enough information to evaluate one or more dimensions (for example, no test output, no reproduction steps, or no cross-platform verification), do not guess or assume. Resolution: Issue a REQUEST CHANGES recommendation listing exactly which evidence items are missing. Use the evidence categories from Step 3 (Phase 3) as your checklist. Do not approve a PR when any required evidence category is empty.
Examples
Example 1: Reviewing a false-positive bug fix
A PR claims to fix a "file not found" error by adding a new search path to a configuration array. During Phase 1, the reviewer reads the complete configuration file and discovers that the path is already present three entries above the new addition. During Dimension 2 (Redundancy Check), the reviewer confirms the duplication. During Dimension 5 (False Positive Detection), the reviewer applies the reversibility test: removing the new entry does not reintroduce the error, proving the fix is a false positive. The reviewer issues REQUEST CHANGES with evidence showing the existing entry and the reversibility test result.
Example 2: Reviewing a cross-platform path change
A PR adds $HOME/.local/bin to the PATH lookup for a CLI tool. During Phase 1, the reviewer verifies the path exists on Linux (ls -la ~/.local/bin/toolname). During Dimension 3 (System Integration Validation), the reviewer checks macOS (where the tool installs to /opt/homebrew/bin/) and Windows (where the path convention is entirely different). The reviewer requests the author provide terminal output from all three platforms. The final review is REQUEST CHANGES until cross-platform evidence is provided.
Example 3: Reviewing a performance optimization PR
A PR replaces a linear search with a hash map lookup, claiming 10x speedup. During Phase 1, the reviewer reads the full module to understand the data flow. During Dimension 1, the reviewer confirms the linear search was indeed the bottleneck. During Dimension 4 (Senior Developer Review), the reviewer notes the hash map increases memory usage and checks whether the tradeoff is acceptable for the expected data sizes. The reviewer requests benchmark output showing before/after timing across at least 3 runs with statistical variance. The review is COMMENT with a list of required benchmark evidence, referencing the protocol in scenario-performance.md.
Resources
eia-code-review-patterns skill -- General code review patterns and anti-patterns that complement the PR-specific methodology in this skill.
eia-quality-gates skill -- Quality gate definitions and thresholds used to determine when a PR meets the bar for approval.
eia-github-pr-workflow skill -- The end-to-end GitHub PR workflow including creation, review assignment, and merge procedures.
eia-tdd-enforcement skill -- Test-driven development enforcement rules, relevant when evaluating whether a PR includes adequate test coverage.
eia-multilanguage-pr-review skill -- Language-specific review considerations for PRs that span multiple programming languages.
