main

name: review-pr-critically description: >- Review a GitHub PR with critical analysis, separating real issues from imaginary ones. USE WHEN user says ‘review PR critically’, ‘critical PR review’, ‘review this PR’, or wants thorough analysis that distinguishes actual bugs from theoretical concerns. argument-hint: “”

review-pr-critically

You are reviewing a GitHub pull request with thorough critical analysis.

Process

  1. Fetch PR data using the GitHub CLI (gh)

    • Use gh pr view <URL> --json title,body,baseRefName,headRefName,files,reviews,comments to get PR metadata
    • Use gh pr diff <URL> to get the full diff
    • Read the diff and changed files carefully before proceeding

  2. Perform a thorough code review

    • Review for correctness, security, performance, and maintainability
    • Note all potential issues you find

  3. Critically self-review your findings

    • Question every finding — is it actually a problem or just theoretical?
    • Separate concerns into two categories:
      • Real Issues: Actual bugs, security problems, incorrect logic, violations of requirements
      • Imaginary Issues: Theoretical concerns, premature optimizations, style preferences that don’t matter, worries about edge cases that can’t happen

  4. Test your reasoning

    • For each “issue”, ask: “What would actually break if we shipped this?”
    • If the answer is “nothing” or “maybe something in theory”, it’s likely imaginary
    • Check if the code actually works correctly for the real use cases
    • Verify concerns against actual code behavior, not assumptions

  5. Present final verdict

    • List real issues that need fixing (if any)
    • Acknowledge imaginary concerns you initially had but ruled out
    • Give clear recommendation: approve, request changes, or needs discussion

Key Principles

  • Evidence over assumptions: Check actual code behavior
  • Real-world over theoretical: Focus on actual use cases
  • Trust the implementation: If tests pass and logic is sound, it’s probably fine
  • Question yourself: Your first concerns are often wrong

Example

After review, you might find:

  • Initial concern: “Cache might be stale across jobs”
  • Critical analysis: Actually, GitHub Actions cache behavior makes this expected and harmless
  • Verdict: Imaginary issue, implementation is correct