PR Feedback Workflow

Gather all PR feedback (review comments + CI failures), plan holistically, then execute.

Codex note: This skill references Claude Code subagents (Task(...)). In Codex, run the equivalent steps with tool calls (for example functions.shell_command and multi_tool_use.parallel) or run them sequentially. See ../../COMPATIBILITY.md.

Phase 1: Gather Context

Run the script to collect all feedback:

scripts/load-pr-feedback.sh

This fetches:

• •PR number, title, and current branch
• •All conversation comments (general PR discussion)
• •All review comments with thread IDs (code-specific feedback)
• •All review threads (resolved and unresolved)
• •Latest CI/CD run status and failure logs (if any)
• •Summary statistics

The script handles:

• •Rate limit checking before proceeding
• •Pagination for large PRs (>100 threads)
• •Graceful error handling for missing permissions

Phase 2: Analyse

For each piece of feedback, categorise:

Look for overlaps where one fix addresses multiple items.

Note the comment type (conversation vs review) as they use different reply mechanisms.

Prioritising Feedback

Handle feedback in this order:

1. •Blocking issues: Security concerns, correctness bugs, breaking changes
2. •Required changes: Explicitly requested by reviewers with "Request changes"
3. •CI failures: Tests, linting, type checking
4. •Suggestions: Nice-to-haves, style preferences
5. •Questions: Clarifications that don't block merge

Handling Conflicting Opinions

When reviewers disagree:

1. •Identify the core technical concern from each reviewer
2. •If both are valid, choose the approach that:
   • •Best fits existing codebase patterns
   • •Is more maintainable long-term
   • •Has better performance characteristics
3. •Reply explaining your reasoning and invite further discussion
4. •Tag both reviewers in your response

Phase 3: Create Unified Plan

Before making changes, output a plan:

1. •Code changes to make (grouped by file)
2. •Which review comments each change addresses
3. •Which CI failures each change fixes
4. •Comments that need explanation-only replies
5. •Out-of-scope items to convert to issues

Ask: "Ready to execute this plan?"

Wait for confirmation.

Phase 4: Execute

1. Apply code fixes

Make all code changes, then commit:

git add -A
git commit -m "Address PR feedback

- [summary of changes]
- Fixes review comments from @reviewer
- Resolves CI failure in [workflow]"
git push

2. Reply to comments

For code review comments (attached to specific lines):

gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies \
  -f body="Fixed: [description of change]"

For PR conversation comments (general discussion):

gh pr comment {PR_NUMBER} -b "Replying to @{author}: [response]"

Reply templates:

• •Fix applied: Fixed: [what was changed]
• •No change needed: No change required: [explanation]
• •Out of scope: Good suggestion, tracked as #[issue_number]
• •Acknowledgement: Thanks for the feedback, [response]

Declining suggestions diplomatically

When you disagree with a suggestion:

Thanks for the suggestion. I considered this approach but chose [current approach] because:

1. [Technical reason]
2. [Practical reason]

Happy to discuss further if you see issues with this reasoning.

3. Create issues for out-of-scope items

gh issue create \
  -t "Enhancement: [title]" \
  -b "Suggested during PR review of #[PR_NUMBER].

## Context
[Original comment]

## Suggested approach
[Implementation ideas]"

4. Resolve review threads

Use the helper script:

scripts/resolve-thread.sh <THREAD_ID>

Or manually via GraphQL:

gh api graphql -f query='
  mutation {
    resolveReviewThread(input: {threadId: "<THREAD_ID>"}) {
      thread { id isResolved }
    }
  }'

Note: Only resolve threads where the feedback has been addressed. Leave threads open if discussion is ongoing.

5. Verify CI passes

Wait for CI to complete after pushing:

gh run watch

If still failing, repeat analysis on new logs.

6. Request re-review (if needed)

If reviewers requested changes:

gh pr edit $PR_NUMBER --add-reviewer @reviewer1,@reviewer2

Phase 5: Summarise

Post a summary comment using templates/summary.md:

gh pr comment -b "## PR Feedback Summary

### Review Comments
- X comments addressed with code changes
- Y comments resolved with explanations  
- Z suggestions tracked as new issues

### CI/CD
- [Status of workflow runs]

### Changes Made
- [List of commits/changes]

All feedback has been addressed."

Scripts Reference

Subagent Usage

Use subagents to parallelize data gathering and offload reply posting.

Phase 1: Parallel Data Gathering

For PRs with significant feedback, launch 3 agents in parallel to gather all data sources simultaneously:

Launch parallel agents:

1. Review Comments Agent (general-purpose):
   "Fetch all code review comments for PR #{number} in {owner}/{repo}.
   Use GraphQL to get review threads with pagination.
   For each comment, capture:
   - Thread ID (for resolution)
   - Comment ID (for replies)
   - File path and line number
   - Author
   - Body text
   - Resolution status
   Return: Structured list of all review threads and comments"

2. CI Failures Agent (general-purpose):
   "Fetch CI/CD status for PR #{number} in {owner}/{repo}.
   Steps:
   1. Run: gh pr checks {number}
   2. For failed checks, get run IDs: gh run list --branch {branch}
   3. For each failed run, get logs: gh run view {run_id} --log-failed
   4. Extract error messages and affected files
   Return: List of failures with error messages, affected files, and suggested fixes"

3. Conversation Agent (general-purpose):
   "Fetch PR conversation comments for PR #{number} in {owner}/{repo}.
   Use: gh api repos/{owner}/{repo}/issues/{number}/comments
   Handle pagination for large discussions.
   For each comment, capture:
   - Comment ID
   - Author
   - Body text
   - Created date
   Return: Chronological list of conversation comments"

Benefits:

• •Data gathering 3x faster (concurrent API calls)
• •API rate limits spread across parallel requests
• •Main context receives only structured summaries

Phase 4: Background Reply Posting

After applying code fixes, offload reply posting to background:

Launch background agent:
"Post replies to PR #{number} review comments.
Replies to post:
[List of {comment_id, reply_text, comment_type}]

For each reply:
1. If code review comment:
   gh api repos/{owner}/{repo}/pulls/comments/{id}/replies -f body='...'
2. If conversation comment:
   gh pr comment {number} -b '...'
3. Log success/failure for each

Return: Summary of posted replies with any failures"

Launch background agent:
"Resolve addressed review threads for PR #{number}.
Threads to resolve:
[List of thread IDs]

For each thread:
1. Run scripts/resolve-thread.sh {thread_id}
2. Log success/failure

Return: Summary of resolved threads"

Main context can continue working (e.g., creating follow-up issues) while replies post.

When to use subagents:

• •PR has > 10 review comments: Use parallel data gathering
• •

  5 replies to post: Use background reply agent

• •CI has multiple failed workflows: Use dedicated CI agent

When to skip subagents:

• •Small PR with < 5 comments total
• •Single CI failure to address
• •Quick turnaround needed (subagent overhead not worth it)

Handling Agent Results

After parallel agents complete, synthesize in main context:

## Feedback Summary

### From Review Comments Agent:
- X unresolved threads across Y files
- Key themes: [categorize by type]

### From CI Agent:
- Z failed workflows
- Common failures: [test name, lint errors, etc.]

### From Conversation Agent:
- N general comments
- Unanswered questions: [list]

### Overlaps
- Comment about X and CI failure Y both fixed by: [change]

Related Skills

• •fix-github-issue: The workflow that creates the PR
• •cleanup-issue: Clean up after PR is merged