PR Iteration Workflow Workshop

Structured pull request iteration methodology for managing multi-round review cycles, addressing feedback efficiently, resolving conflicts, and maintaining PR velocity without quality compromises.

When to Use This Skill

Choose PR Iteration Workflow when:

• PRs go through multiple rounds of review feedback
• Need to manage review comments across large, complex PRs
• Coordinating reviews from multiple reviewers with conflicting feedback
• Streamlining the request-review-revise cycle for faster merges
• Training teams on efficient PR feedback resolution

Consider alternatives when:

• PRs are straightforward and merge in one round
• Using trunk-based development with pair programming
• Need design review before code — use RFC/ADR processes

Quick Start

Copy
# Activate PR iteration workflow
claude skill activate precision-pr-iteration-workflow-workshop

# Manage PR iteration
claude "Help me address the review feedback on PR #345 efficiently"

Example: PR Iteration Tracking

Copy
## PR #345: Add User Authentication

### Iteration 1 (Initial Review)
**Reviewer**: @alice | **Status**: Changes Requested
| # | Comment | Category | Status |
|---|---------|----------|--------|
| 1 | Missing rate limiting on login endpoint | Security | ✅ Fixed |
| 2 | Password validation too weak (min 6 → 12) | Security | ✅ Fixed |
| 3 | Consider using bcrypt instead of SHA256 | Architecture | ✅ Fixed |
| 4 | Add error handling for database connection | Robustness | ✅ Fixed |
| 5 | Nit: Rename `usr` to `user` | Style | ✅ Fixed |

### Iteration 2 (Re-review)
**Reviewer**: @alice | **Status**: Changes Requested
| # | Comment | Category | Status |
|---|---------|----------|--------|
| 6 | Rate limiter should use sliding window | Enhancement | ✅ Fixed |
| 7 | Add integration test for auth flow | Testing | ✅ Fixed |

### Iteration 3 (Final Review)
**Reviewer**: @alice, @bob | **Status**: ✅ Approved
- All comments addressed
- Tests passing
- Ready to merge

Core Concepts

PR Lifecycle Stages

Stage	Actions	Duration Target
Draft	Work in progress, early feedback welcome	While building
Ready for Review	Complete, CI passing, description filled	Mark when done
In Review	Reviewer examining changes	4-24h first response
Changes Requested	Author addressing feedback	4-8h per iteration
Re-Review	Reviewer verifying fixes	2-4h per re-review
Approved	All approvals received	Merge within 2h
Merged	Integrated into main branch	Same day as approval

Comment Resolution Strategies

Strategy	When to Use	Example
Fix and reply	Clear, actionable feedback	"Fixed — updated to use bcrypt"
Discuss	Disagree or need clarification	"I considered that, but X because Y"
Create follow-up	Valid but out of scope	"Good idea, created issue #456 for this"
Acknowledge	Style nit, will fix	"Good catch, fixed"
Request offline discussion	Complex architectural disagreement	"Let's discuss in standup — multiple valid approaches"

Configuration

Parameter	Description	Default
max_iterations	Alert if PR exceeds N rounds	3
response_sla	Author response time for feedback	8h
re_review_sla	Re-review time after changes	4h
stale_comment_days	Days before unresolved comments flagged	3
auto_merge	Auto-merge when all checks pass + approved	true
squash_merge	Squash commits on merge	true

Best Practices

1. Address all comments before requesting re-review — Don't request re-review with unresolved comments. Batch your fixes, push all changes, then request re-review once. Partial responses create confusion and waste reviewer time on multiple passes.

2. Reply to every comment, even if just "fixed" — Reviewers need to know their feedback was seen and addressed. A one-word "Fixed" or "Done" reply saves the reviewer from re-reading the code to check if it was handled.

3. Use "fixup!" commits during iteration, squash on merge — Create fixup! original commit message commits for review feedback changes. This makes it easy for reviewers to see exactly what changed between iterations. Squash all commits when merging for a clean history.

4. Resolve disagreements quickly — don't let PRs stall — If author and reviewer disagree, involve a third person or discuss synchronously. A PR stalled for days due to disagreement costs more than either approach. Set a rule: if not resolved in 24h, escalate to tech lead.

5. Split feedback into blocking and non-blocking categories — Mark critical issues (bugs, security, correctness) as "blocking" and style preferences as "nit" or "non-blocking." This helps authors prioritize fixes and prevents style discussions from delaying important changes.

Common Issues

PRs require 4+ rounds of review before merging. This usually indicates unclear requirements or architectural misalignment. Have a brief design discussion before coding begins. For complex features, use a draft PR with the interface/types first to align on approach before implementing the full solution.

Different reviewers give conflicting feedback. Designate a primary reviewer whose feedback takes precedence. When reviewers disagree, they should discuss with each other (not through the author). Document the resolution in the PR for context.

Author gets defensive about review feedback. Frame reviews as collaborative improvement, not criticism. Reviewers should explain the "why" behind suggestions. Authors should default to assuming good intent. If tensions arise, discuss team review norms in a retrospective.