main

ResolvePRComments Workflow

Resolve review comments on your own pull request.

When to Use

  • “resolve pr comments”
  • “address review feedback”
  • “fix pr comments”
  • “respond to reviewers”

Required Tool

Always use gh-pr review --llm to gather comment context:

gh-pr review <number> --llm

Focus on the === REVIEW COMMENTS === section which shows:

  • File and line number
  • Comment author and status (resolved/unresolved)
  • Comment text and suggestions
  • Threaded replies

Workflow

Phase 1: Discovery

gh-pr review <number> --llm

For each unresolved comment:

  • Understand the reviewer’s intent
  • Check if code changed since comment (stale?)
  • Determine: code change needed OR can discard?

Categorize by priority:

  • CRITICAL: Security, data loss, breaking changes
  • HIGH: Bugs, performance, architecture
  • MEDIUM: Code quality, maintainability
  • LOW: Style, minor optimization, docs

Phase 2: Planning

Present actionable comments:

Comment Priority Description Risk Effort
#123 HIGH Add error handling Low Simple
#124 MEDIUM Rename variable Low Simple

Wait for user approval before proceeding.

Phase 3: Execution

For each approved comment:

  1. Read all relevant files
  2. Implement the change following codebase conventions
  3. Validate - does it address the comment? tests pass?
  4. Commit with reference: 
    fix(auth): validate email format before API call

Refs: https://github.com/org/repo/pull/123#discussion_r456

Phase 4: Completion

Verification checklist:

  • All commits pushed
  • Tests passing
  • Commit messages reference comments

Summary:

  • Addressed: (list with commit SHAs)
  • Discarded: (with justification)
  • Deferred: (awaiting discussion)

Handling Special Cases

Scenario Action
Conflicting feedback Flag for user decision
Stale comments Note code changed, show current state
Out-of-scope requests Suggest separate PR/issue
Ambiguous comment Ask reviewer for clarification

Critical Rules

  • DO: Wait for approval, validate changes, one logical change per commit, preserve style
  • DON’T: Start without approval, skip testing, bundle unrelated changes, rush