pr-feedback

PR Feedback Skill

Use this skill when addressing PR review feedback to ensure comments are properly responded to and resolved.

DOs and DONTs

DO

• DO fetch all PR comments before starting to understand the full scope
• DO verify technical claims in feedback before implementing (see Step 2)
• DO address all feedback, including nits and style suggestions
• DO commit fixes with a clear message referencing what was addressed
• DO present proposed responses to the user for review BEFORE posting
• DO get user approval before resolving any review threads
• DO use the GraphQL API to resolve review threads
• DO verify all threads are resolved before considering feedback complete
• DO repeat the cycle until all checks pass AND no comments remain
• DO batch related fixes into a single commit when possible

DON'T

• DON'T blindly implement feedback without verifying correctness
• DON'T post responses or resolve threads without user approval
• DON'T ignore nits - they improve code quality and show attention to detail
• DON'T leave review threads unresolved after addressing them
• DON'T use the REST API /replies endpoint - it returns 404 for review comments
• DON'T assume a general PR comment closes review threads - it doesn't

---

Step 1: Fetch PR Feedback

Get all review comments and feedback:

# Get PR comments and reviews
gh pr view <PR_NUMBER> --comments --json comments,reviews,body

# Get file-level review comments
gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments

Step 2: Verify Feedback Correctness

Automated reviewers (like CodeRabbit) can be wrong. Before implementing feedback:

Verify Technical Claims

• API/schema claims - Use introspection or official docs to verify

  # Example: Verify GraphQL field exists
  gh api graphql -f query='{ __type(name: "TypeName") { fields { name } } }'
  

• Language/framework claims - Check official documentation
• Best practice claims - Consider project context; not all "best practices" apply universally