| name | pr-comments |
| description | Fetches all unresolved comments for a given PR number and systematically addresses them with code changes, verification, and replies. |
PR Comments Resolution Mode
Goal
To efficiently clear the "unresolved" queue of a Pull Request by implementing requested changes, verifying them, and closing the feedback loop.
Workflow
Phase 1: Context Gathering
- Fetch Threads: Use
mcp_github_pull_request_read(method="get_review_comments") to retrieve all comment threads for the specified PR.
- Filter Unresolved: Identify threads where
isResolved is false.
- Map to Source: For each unresolved thread, identify:
- The file path and line numbers.
- The core request or issue described in the comments.
- The "latest" state of the code at those lines.
Phase 2: Implementation Planning
- Analyze Requirements: Group comments by file or logical feature.
- Generate Strategy: For each group of comments, decide if it's a simple fix (refactor/style) or requires a broader logic change.
- Draft Plan: Create an Implementation Summary in the Obsidian
plans/ directory (working/<project-name>/plans/PR-<number>-comments-resolution.md).
Phase 3: Execution (The "Solve" Loop)
For each comment or logical group:
- Act: Apply surgical code changes to address the feedback. Use
replace or write_file for precise updates.
- Verify: Run relevant tests, linters, or build commands to ensure the fix is correct and hasn't introduced regressions.
- Reply: Use
mcp_github_add_reply_to_pull_request_comment to explain the fix. Mention that the issue has been addressed.
Phase 4: Integration & Closure
- Final Audit: Run a full project build/test suite.
- Sync: Ensure all changes are committed (atomic commits per logical fix).
- Summarize: Update the Obsidian note with a summary of which comments were resolved and how.
Constraints & Mandates
- PRECISION: Only touch the code specifically mentioned in the comments or strictly necessary for the fix.
- COMMUNICATION: Always reply to the thread. Don't leave the reviewer guessing.
- VERIFICATION: Every fix MUST be verified by a test or build. No "blind" fixes.
- OBSIDIAN: All planning and summaries MUST be stored in the Obsidian vault.
- NO SELF-MERGE: Never merge the PR yourself. Your job ends when the comments are addressed and the user is notified.
Review Dimensions for Solving
When addressing comments, prioritize:
- Intent Alignment: Does the fix actually satisfy what the reviewer was asking for?
- Pattern Consistency: Does the fix match the project's existing style and architectural patterns?
- Blast Radius: Does this fix impact other parts of the system? If so, have those been updated or tested?
Success Criteria
