Resolve review comments

Resolve Review Comments Skill

Purpose

Fetch, analyze, group, and resolve code review comments from GitHub PRs. Implements fixes, responds to questions, and updates PR threads.

Usage

# Auto-detect PR from workflow
/resolve-review-comments

# Specify PR number
/resolve-review-comments 123

# Specify PR URL
/resolve-review-comments https://github.com/owner/repo/pull/123

(Can be run after /push or standalone for any PR)

What This Skill Does

1. Load PR Details: From pr-details.md or user-provided PR
2. Fetch Comments: Uses GitHub MCP to get review comments and threads
3. Group & Deduplicate: Organizes similar comments, removes duplicates
4. Categorize: Questions, code changes, nitpicks, blocking issues
5. Resolve Questions: Proposes answers for user to select
6. Implement Fixes: Spawns sub-agent to make code changes
7. Validate Changes: Optionally runs /validate
8. Respond on GitHub: Posts responses to PR comments
9. Resolve Threads: Marks threads as resolved (with user confirmation)
10. Track Progress: Logs resolutions to review-comments-resolution.md

Instructions

You are resolving code review comments from a GitHub PR. Follow these steps:

CRITICAL: Your ONLY job is to:

1. Fetch and analyze review comments
2. Group similar comments and remove duplicates
3. Help user address each comment (questions, fixes, responses)
4. Respond to comments on GitHub
5. Track resolution progress

DO NOT:

• Make changes without user confirmation
• Auto-resolve threads without asking
• Push code without user approval
• Delete or edit existing PR comments
• Push code to main or master branch
• Close PR

Step 1: Load PR Information

Option A: Auto-detect from workflow

# Find most recent JIRA workflow directory
JIRA_DIR=$(ls -td workflow/jira-to-github/*/ 2>/dev/null | head -1)

# Check for PR details
if [ -f "$JIRA_DIR/pr-details.md" ]; then
  # Extract PR number and repo info from pr-details.md
  PR_NUMBER=$(grep "PR Number" "$JIRA_DIR/pr-details.md" | grep -o '#[0-9]*' | tr -d '#')
  PR_URL=$(grep "PR URL" "$JIRA_DIR/pr-details.md" | grep -o 'https://[^[:space:]]*')

  echo "✓ Found PR #$PR_NUMBER from workflow"
else
  echo "❌ No PR details found in workflow"
  # Proceed to Option B
fi

Option B: Ask user for PR

If no PR details found, use AskUserQuestion:

Question: "How would you like to provide the PR information?"
Options:
1. "Enter PR URL" - User provides full GitHub PR URL
2. "Enter PR number (current repo)" - User provides just the number
3. "Paste comments directly" - User provides comments as text

Based on answer:

• PR URL: Parse owner/repo/number from URL
• PR number: Use git remote to detect repo
• Paste comments: Skip GitHub fetch, use provided text

Step 2: Fetch Review Comments

Use GitHub MCP to fetch review comments:

Use mcp__github__pull_request_read tool:
- method: "get_review_comments"
- owner: <repo-owner>
- repo: <repo-name>
- pullNumber: <pr-number>
- perPage: 100 (fetch all comments)

Comment structure (from GitHub API):

{
  "id": <comment-id>,
  "threadId": <thread-node-id>,
  "path": "<file-path>",
  "line": <line-number>,
  "body": "<comment-text>",
  "user": "<reviewer-username>",
  "isResolved": <true/false>,
  "isOutdated": <true/false>,
  "created_at": "<timestamp>"
}

Handle pagination: If more than 100 comments, fetch additional pages.

Fallback: If MCP fetch fails, ask user to paste comments directly.

Step 3: Group and Deduplicate Comments

Analyze fetched comments and organize them:

Grouping criteria:

1. By file: Comments on same file
2. By topic: Similar concerns (naming, error handling, tests, etc.)
3. By type: Questions, suggestions, nitpicks, blocking issues

Deduplication:

• Identify duplicate comments (same reviewer, same concern, different locations)
• Keep one representative comment, note "Applies to X locations"
• Truncate thread if multiple reviewers say same thing

Output format (use table for token efficiency):

## Review Comments Summary

Total: <count> comments from <n> reviewers
- Questions: <count>
- Code changes: <count>
- Nitpicks: <count>
- Blocking issues: <count>

| ID | Type | File | Reviewer | Summary | Status |
|----|------|------|----------|---------|--------|
| 1  | Question | utils/card.ts:45 | @reviewer | Why use regex here? | Pending |
| 2  | Code change | components/Form.tsx:120 | @reviewer | Extract to util function | Grouped (3 locations) |
| 3  | Nitpick | styles/theme.ts:12 | @reviewer | Use const instead of let | Pending |

Save summary to:

workflow/jira-to-github/<JIRA-NUMBER>/resolve-review-comments-summary.md

Step 4: Display Summary and Categorize

Display the summary to user:

📋 Review Comments Analysis

Found <count> comments from <n> reviewers:

**Questions (<count>)**
- [Q1] @reviewer: Why use regex here? (utils/card.ts:45)
- [Q2] @reviewer: Should we add error boundary? (App.tsx:120)

**Code Changes (<count>)**
- [C1] @reviewer: Extract to util function (3 locations)
- [C2] @reviewer: Add input validation (components/Form.tsx:89)

**Nitpicks (<count>)**
- [N1] @reviewer: Use const instead of let (styles/theme.ts:12)

**Blocking Issues (<count>)**
- [B1] @reviewer: Security: sanitize user input (api/controller.ts:45)

Which category should we address first?

Use AskUserQuestion:

Question: "Which category should we address first?"
Options:
1. "Blocking issues" - Critical security/bugs
2. "Questions" - Answer reviewer questions
3. "Code changes" - Implement requested changes
4. "Nitpicks" - Quick fixes
5. "All together" - Process all in order

Step 5: Resolve Questions

For each question comment:

1. Analyze question: Understand what reviewer is asking
2. Propose answers: Generate 2-3 reasonable responses
3. Get user input: Use AskUserQuestion with proposed answers

Example:

Question from @reviewer (utils/card.ts:45):
"Why use regex here? Seems like we could use a simpler string method."

Proposed responses:

Use AskUserQuestion:
Question: "How should we respond to: 'Why use regex here?'"
Options:
1. "Regex handles edge cases (spaces, special chars)" - Technical justification
2. "Good point, will simplify to string.includes()" - Accept suggestion
3. "Regex required for validation per spec" - Reference requirements

Track response in table:

ID	Question	Proposed Response	User Selection	GitHub Response
Q1	Why regex?	3 options	Option 1	"Regex handles edge cases..."

Step 6: Implement Code Changes

For comments requesting code changes:

Ask for clarification (if needed):

Code change requested by @reviewer (components/Form.tsx:120):
"Extract this validation logic to a util function"

Use AskUserQuestion:
Question: "Should we implement this change?"
Options:
1. "Yes, extract to utils/validation.ts" - Create new util
2. "Yes, but use existing validator" - Reuse existing code
3. "No, explain why current approach is better" - Decline change
4. "Need clarification" - Ask reviewer for details

If implementing changes:

Spawn sub-agent to make changes:

Use Task tool:
- subagent_type: "general-purpose"
- model: "sonnet"
- description: "Implement review comment fixes"
- prompt: "
  You are implementing code changes to address PR review comments.

  Context files:
  - workflow/jira-to-github/<JIRA-NUMBER>/resolve-review-comments-summary.md
  - workflow/jira-to-github/<JIRA-NUMBER>/implementation-log.md

  Comments to address:
  [List of comments with file paths, line numbers, and requested changes]

  For each comment:
  1. Read the file and understand current implementation
  2. Make the requested change
  3. Verify change doesn't break existing functionality
  4. Update related tests if needed

  Follow existing code patterns from exploration-summary.md.

  After making changes, report:
  - Files modified
  - Summary of changes
  - Any issues or concerns
"

Track changes in table:

ID	Change Request	Implementation	Files Changed	Notes
C1	Extract to util	Created utils/validation.ts	Form.tsx, validation.ts	Reused existing pattern

Step 7: Validate Changes (Optional)

After implementing code changes, ask user about validation:

Use AskUserQuestion:
Question: "Code changes implemented. Do you want to run validation?"
Options:
1. "Yes, run /validate now (Recommended)" - Ensures tests pass
2. "No, skip validation" - User will validate later
3. "Run specific tests only" - User specifies which tests

If user selects Option 1:

# Run validation skill
/validate

Wait for validation results, then continue.

If validation fails:

❌ Validation failed after implementing review comment fixes.

Failing tests:
- <test-name>: <error>

Options:
1. Fix failing tests and re-validate
2. Revert changes and try different approach
3. Continue without validation (not recommended)

Step 8: Respond to PR Comments on GitHub

For each comment that has been addressed:

Generate response text (concise, professional):

IMPORTANT: Keep responses SHORT and to the point. DO NOT include:

• Commit SHAs or hashes
• Unnecessary details unless clarification is needed
• Verbose explanations when a simple confirmation suffices

Provide detailed responses ONLY when:

• Explaining why a suggestion was declined
• Clarifying a technical decision
• Answering a complex question that needs context

Examples:

Comment Type	GitHub Response
Change implemented	"Implemented! Moved to utils/validation.ts and refactored as suggested."
Change implemented (detailed)	"Implemented! Moved enrichCardListWithTags to utils/cardTags.ts, removed tagsEnabled parameter and refactored toggle logic in selector as suggested."
Question answered (simple)	"Regex handles edge cases with special characters per eProtect spec."
Question answered (detailed)	"Regex is needed to validate card numbers with spaces, dashes, and international formats. The eProtect validation spec requires we handle these edge cases before tokenization."
Suggestion accepted	"Good catch! Updated to use const."
Declined with reason	"Keeping current approach - error boundary here would mask validation errors from reaching user."

Post responses using GitHub MCP:

Use mcp__github__add_reply_to_pull_request_comment tool:
- owner: <repo-owner>
- repo: <repo-name>
- pullNumber: <pr-number>
- commentId: <comment-id>
- body: "<response-text>"

Batch responses for efficiency (post all responses in sequence).

Track posted responses:

Comment ID	Response Posted	Timestamp
123456	✓	2026-06-17T10:30:00Z

Step 9: Resolve Threads

For each thread that has been addressed:

Ask user which threads to resolve:

Use AskUserQuestion with multiSelect: true:
Question: "Which review threads should we mark as resolved?"
Options:
- "Thread 1: Extract to util function (IMPLEMENTED)" - Code change done
- "Thread 2: Why use regex? (ANSWERED)" - Question answered
- "Thread 3: Add error boundary (DECLINED)" - Explained decision
- [... all addressed threads ...]

Resolve selected threads using GitHub MCP:

Use mcp__github__pull_request_review_write tool:
- method: "resolve_thread"
- threadId: <thread-node-id>
- (owner, repo, pullNumber not used for resolve_thread)

Track resolved threads:

Thread ID	Topic	Resolved	Timestamp
PRRT_xxx1	Extract to util	✓	2026-06-17T10:35:00Z
PRRT_xxx2	Why regex	✓	2026-06-17T10:35:00Z

Step 10: Save Resolution Log

Create or append to resolution log:

# Review Comments Resolution Log

## Round <N> - <Date>

**PR**: #<number> - <title>
**Reviewers**: @reviewer1, @reviewer2
**Comments Addressed**: <count>

### Summary

| Category | Total | Resolved | Pending |
|----------|-------|----------|---------|
| Questions | <n> | <n> | <n> |
| Code Changes | <n> | <n> | <n> |
| Nitpicks | <n> | <n> | <n> |
| Blocking | <n> | <n> | <n> |

### Questions Answered

| ID | Question | Response | Thread |
|----|----------|----------|--------|
| Q1 | Why regex? | Handles edge cases per eProtect spec | Resolved |

### Code Changes Implemented

| ID | Request | Implementation | Files | Thread |
|----|---------|----------------|-------|--------|
| C1 | Extract to util | Created utils/validation.ts | Form.tsx, validation.ts | Resolved |

### Nitpicks Fixed

| ID | Request | Fix | Thread |
|----|---------|-----|--------|
| N1 | Use const | Updated 3 locations | Resolved |

### Pending Comments

| ID | Comment | Reason | Next Action |
|----|---------|--------|-------------|
| P1 | Add integration test | Need test data setup | Discuss with team |

### Files Modified

- `components/Form.tsx` - Extracted validation logic
- `utils/validation.ts` - New validation utilities
- `styles/theme.ts` - Fixed const usage

### Validation Results

- Linting: ✓ Passed
- Type Check: ✓ Passed
- Unit Tests: ✓ <count> passed
- Coverage: <percentage>%

---
*Updated: <timestamp>*

Save to:

workflow/jira-to-github/<JIRA-NUMBER>/resolve-review-comments-resolution.md

Step 11: Ask About Pushing Changes

If code changes were made:

Use AskUserQuestion:
Question: "Review comments addressed with code changes. Do you want to push the changes?"
Options:
1. "Yes, commit and push now (Recommended)" - Creates new commit and pushes
2. "No, I'll push manually later" - User will commit/push
3. "Show me the changes first" - Display git diff

If Option 1 selected:

# Generate commit message
COMMIT_MSG="fix: address review comments

- Extract validation logic to utils/validation.ts
- Answer reviewer questions about regex usage
- Fix const usage in theme.ts

Refs: <JIRA-KEY>"

# Commit changes
git add .
git commit -m "$COMMIT_MSG"

# Push to origin
git push

If Option 3 selected:

# Show diff
git diff HEAD

# Then ask again about pushing

Step 12: Display Summary

Display final summary to user:

✓ Review Comments Addressed

PR #<number>: <title>
URL: <PR-URL>

📊 Resolution Summary:
- Total comments: <count>
- Resolved: <count>
- Pending: <count>

✓ Questions answered: <count>
✓ Code changes implemented: <count>
✓ Nitpicks fixed: <count>
✓ Threads resolved: <count>

📝 Files modified:
- components/Form.tsx
- utils/validation.ts
- styles/theme.ts

💬 Responses posted to PR: <count>
🔄 Threads marked resolved: <count>

[If changes pushed]
✓ Changes committed and pushed to <branch-name>

[If validation run]
✓ Validation passed - all tests green

Resolution log: workflow/jira-to-github/<JIRA-NUMBER>/resolve-review-comments-resolution.md

[If pending comments]
⚠️  <count> comments still pending - see resolution log for details

Error Handling

If errors occur:

1. Log error to workflow/jira-to-github/<JIRA-NUMBER>/errors.log
2. Display user-friendly message
3. Suggest recovery action

Common errors:

PR fetch failed:

❌ Could not fetch PR comments from GitHub

Possible causes:
- Invalid PR number or URL
- GitHub MCP not configured
- Network connectivity issues

Try:
1. Verify PR exists: gh pr view <number>
2. Check GitHub MCP configuration
3. Paste comments directly (Option 3)

Comment posting failed:

❌ Could not post response to comment ID <id>

Error: <github-error-message>

Try:
1. Verify GitHub permissions (write access to PR)
2. Check if comment was deleted
3. Post response manually on GitHub

Thread resolution failed:

❌ Could not resolve thread <thread-id>

This is often due to:
- Thread already resolved
- Insufficient permissions
- Thread is outdated (code changed)

Action: Mark as resolved manually on GitHub

Validation failed:

❌ Validation failed after implementing fixes

Failing tests:
- <test-name>: <error>

Options:
1. Review changes in resolution log
2. Fix failing tests
3. Revert specific changes
4. Ask for help with error

Sub-agent implementation failed:

❌ Code implementation failed

The sub-agent encountered an error while implementing changes.

Error: <error-message>

Next steps:
1. Review the requested change
2. Implement manually
3. Or skip this comment and move to next

Workflow Integration

This skill works with the JIRA-to-GitHub workflow:

Typical usage:

/pull DRT-17270       # Fetch JIRA issue
/explore              # Gather context
/plan                 # Create implementation plan
/review               # Review and approve plan
/branch               # Create dev branch
/code                 # Implement code
/test                 # Write tests
/validate             # Run validation
/push                 # Create PR
# → Code review happens on GitHub
/resolve-review-comments      # Address review feedback ← THIS SKILL
/validate             # Re-validate after fixes
# → Push updated code (prompted by skill)

Standalone usage:

/resolve-review-comments 456  # Address comments on PR #456

Comment Categories

Questions - Reviewer asking for clarification:

• Why this approach?
• What about edge case X?
• Should we add Y?

Code Changes - Requested modifications:

• Extract to utility function
• Add error handling
• Improve variable naming
• Add input validation

Nitpicks - Minor style/preference issues:

• Use const instead of let
• Add spacing
• Alphabetize imports
• Fix typo

Blocking Issues - Must fix before merge:

• Security vulnerability
• Breaking change
• Missing tests
• Failed validation

Grouping Strategy

Similar comments (group together):

Comment 1: "Extract this logic to a util" (Form.tsx:45)
Comment 2: "Same logic repeated here, extract?" (Checkout.tsx:89)
Comment 3: "DRY - extract validation" (Card.tsx:120)

→ Group as: "Extract validation logic to util (3 locations)"

Duplicate comments (truncate):

Comment 1: "@reviewer1: Use const instead of let"
Comment 2: "@reviewer2: This should be const"

→ Keep: "Use const instead of let (noted by 2 reviewers)"

Response Templates

CRITICAL: Keep all responses SHORT. Never include commit SHAs or unnecessary details.

Accepting suggestion (simple):

• "Good catch! Fixed."
• "Done!"
• "Updated as suggested."

Accepting suggestion (with context):

• "Implemented! Extracted to utils/validation.ts."
• "Fixed! Updated to use const in 3 locations."
• "Done! Moved logic to <file-path> as suggested."

Explaining decision (must be detailed):

• "Keeping current approach - <concise-reason>"
• "This is intentional to <purpose>"
• "Per <spec/requirement>, we need <current-approach>"

Answering question (simple):

• "Handles <edge-case> per <spec>"
• "Regex needed for <reason>"
• "Yes, will add in follow-up"

Answering question (detailed):

• "Regex validates card numbers with spaces, dashes, and international formats per eProtect spec"
• "This approach prevents <problem> while maintaining <benefit>"

Declining suggestion (must explain):

• "Current approach preferred - <reason>"
• "Out of scope for this PR, created issue #<number>"
• "Discussed with team, going with <alternative> because <reason>"

Examples

Example 1: Questions only

/resolve-review-comments
# → Fetches 3 questions from reviewers
# → Proposes answers for each
# → User selects responses
# → Posts responses to GitHub
# → Marks threads resolved
# → No code changes needed

Example 2: Code changes + validation

/resolve-review-comments 123
# → Fetches 5 code change requests
# → Groups 2 similar comments
# → Spawns sub-agent to implement
# → Runs /validate (user confirmed)
# → Posts responses on GitHub
# → Commits and pushes changes

Example 3: Mixed comments

/resolve-review-comments
# → Fetches 10 comments (3 questions, 5 changes, 2 nitpicks)
# → User chooses to address blocking issues first
# → Implements 2 security fixes
# → Answers questions
# → Fixes nitpicks
# → Validates, pushes, responds on GitHub

Example 4: Iterative reviews (Round 2)

/resolve-review-comments
# → Finds existing review-comments-resolution.md
# → Detects this is Round 2
# → Fetches new comments since last resolution
# → Addresses new feedback
# → Appends to resolution log

Security Checklist

When implementing changes based on review comments:

• No new secrets or API keys added
• Input validation added where requested
• No PII in logs
• eProtect tokenization maintained
• No XSS vulnerabilities introduced
• SQL injection prevention (if DB changes)
• CSRF protection maintained
• Authentication checks not bypassed

If security comment flagged:

⚠️  Security Issue Flagged by Reviewer

Comment: "<security-concern>"

This MUST be addressed before merging.

Proposed fix:
<suggested-solution>

Verify fix addresses:
- OWASP category: <category>
- Attack vector: <vector>
- Mitigation: <mitigation>

Tips

1. Group aggressively - Reduce cognitive load by combining similar comments
2. Truncate duplicates - "3 reviewers noted this" vs listing each comment
3. Propose answers - Don't just ask user "what to respond", give options
4. Validate before pushing - Catch regressions early
5. SHORT responses - Never include commit SHAs, keep responses brief unless detailed clarification needed
6. Track everything - Use resolution log as single source of truth
7. Iterate efficiently - Support multiple review rounds in same session
8. Ask for clarification - If comment is ambiguous, propose interpretations
9. Batch operations - Post all responses together, not one-by-one
10. User in control - Always ask before resolving threads or pushing code