القائمة
Trigger with /eia-ai-pr-review. Use when performing deep evidence-based PR reviews, investigating false-positive fixes, or validating integration changes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Quality gate enforcement for PR integration. Use when verifying code through pre-review, review, pre-merge, or post-merge checkpoints. Trigger with /eia-enforce-gates.
Software release management and coordination. Use when creating releases, bumping versions, or rolling back deployments. Trigger with release tasks or /eia-create-release.
Use when managing team tasks through GitHub Projects V2 or synchronizing project state via GraphQL API. Trigger with /sync-projects or when updating project items.
Use when diagnosing CI/CD failures. Trigger with CI failure logs or pipeline errors.
Use when processing parallel PRs. Trigger with git worktree or parallel development requests.
Use when managing GitHub Issues including creation, labels, milestones, assignees, and comments using gh CLI. Trigger with create issue, set labels, assign milestone.
| name | eia-ai-pr-review-methodology |
| description | 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 |
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:
The 5 analysis dimensions (applied in Phase 2) are:
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.
Before using this skill, you should be familiar with:
Applying this skill produces a structured review document containing:
The template for this output is provided in review-output-template.md.
Follow these steps in order. Do not skip phases.
Read phase-1-context-gathering.md and complete all 4 context gathering actions before proceeding.
Table of Contents for phase-1-context-gathering.md:
Read phase-2-structured-analysis.md for an overview of the 5 analysis dimensions, then read each dimension reference file in order.
Table of Contents for phase-2-structured-analysis.md:
Read dimension-1-problem-verification.md.
Table of Contents for dimension-1-problem-verification.md:
Read dimension-2-redundancy-check.md.
Table of Contents for dimension-2-redundancy-check.md:
Read dimension-3-system-integration.md.
Table of Contents for dimension-3-system-integration.md:
Read dimension-4-senior-review.md.
Table of Contents for dimension-4-senior-review.md:
Read dimension-5-false-positive-detection.md. This is the most critical dimension.
Table of Contents for dimension-5-false-positive-detection.md:
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:
ls or equivalent. For commands: output showing availability. For system behavior: documentation links or code proof.If the PR matches one of these scenarios, read the corresponding reference file for scenario-specific review protocol:
Path/File Changes: Read scenario-path-changes.md.
Table of Contents for scenario-path-changes.md:
Bug Fixes: Read scenario-bug-fixes.md.
Table of Contents for scenario-bug-fixes.md:
Performance Improvements: Read scenario-performance.md.
Table of Contents for scenario-performance.md:
Dependency Updates: Read scenario-dependency-updates.md.
Table of Contents for scenario-dependency-updates.md:
Read review-output-template.md and use the template to produce your final review document.
Table of Contents for review-output-template.md:
Before submitting your review, run through the quick reference checklist. Read quick-reference-checklist.md.
Table of Contents for quick-reference-checklist.md:
Copy this checklist and track your progress through the PR review workflow:
The full checklist with detailed explanations is in quick-reference-checklist.md.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.