resolve-fixed-pr-comments
starsforks
How to install resolve-fixed-pr-comments?
neolabhq/context-engineering-kit/resolve-fixed-pr-comments
$npx -y skills add NeoLabHQ/context-engineering-kit --skill resolve-fixed-pr-commentsVerify what PR review comments have been addressed (committed/pushed OR uncommitted local changes) and resolve the threads that are genuinely fixed or no longer relevant.
SKILL.md
| 1 | # Resolve Fixed PR Review Comments |
| 2 | |
| 3 | Load ONLY open/UNRESOLVED PR review threads, verify each one against the CURRENT state of the codebase (the fix may be committed/pushed OR exist only as uncommitted local changes — both count), and resolve ONLY the threads that are genuinely fixed or no longer relevant. The single permitted write action is resolving a thread. Nothing else is touched. |
| 4 | |
| 5 | ## Critical Guidelines |
| 6 | |
| 7 | **Violating the letter of these rules means failing the task.** If you fail the task, you will be killed! |
| 8 | |
| 9 | - When unsure, LEAVE THE THREAD UNRESOLVED. Better to leave a fixed comment unresolved than to wrongly resolve an unfixed one. |
| 10 | - You MUST load ONLY threads where `isResolved`/`is_resolved` is false. Skip resolved threads. |
| 11 | - You MUST observe only the CURRENT state of the codebase. Read the file as it exists NOW. Do NOT reason about how the code used to be, what a commit changed, or git history as evidence of a fix — only whether the requirement is satisfied in the current files counts. |
| 12 | - A fix is VALID whether it is already committed/pushed OR exists only as uncommitted local changes. Both are acceptable evidence. Inspect the working tree as-is. |
| 13 | - You MUST NOT modify code, create/edit/delete any file, or run tests, linters, formatters, or builds. |
| 14 | - You MUST NOT push, pull, commit, stash, checkout, switch, reset, revert, rebase, merge, cherry-pick, or perform ANY mutating git operation. ONLY read-only inspection (`git status`, `git diff`, `git log`, `git branch`) is allowed, and only to observe the current state. |
| 15 | - You MUST NOT add a comment to the PR, reply to a thread, submit a review, approve, or request changes. The ONLY write action permitted against GitHub is resolving a thread that is genuinely fixed. |
| 16 | - You MUST be critical and perfectionist. A comment is "fixed" ONLY when ALL of its requirements are FULLY satisfied in the current codebase. Partially-addressed comments, unaddressed nitpicks, and "close enough" changes stay UNRESOLVED. |
| 17 | - You MUST NOT resolve a thread you did not verify against an actual file. No verification → no resolve. |
| 18 | |
| 19 | ## Red Flags - STOP and Leave Unresolved |
| 20 | |
| 21 | If any of these describe your reasoning, do NOT resolve the thread: |
| 22 | |
| 23 | - "The fix is probably there, I'll resolve it." → No. Verify against the current file or leave it. |
| 24 | - "The commit message says it was fixed." → Commit messages and history are NOT evidence. Read the current file. |
| 25 | - "Most of the comment is addressed." → Partial ≠ fixed. Leave unresolved. |
| 26 | - "It's just a nitpick, resolving it cleans up the PR." → Unaddressed nitpicks stay unresolved. |
| 27 | - "It's no longer relevant because the code moved." → Only resolve if the requirement is genuinely satisfied or genuinely obsolete in the CURRENT code — not because it's inconvenient to verify. |
| 28 | - "I'll quickly fix it myself, then resolve." → FORBIDDEN. No code edits. If it isn't already fixed, leave it unresolved. |
| 29 | - "I'll reply explaining why I resolved it." → FORBIDDEN. No replies, no comments. Resolve silently or leave it. |
| 30 | - "I'll resolve all of them since the branch looks done." → Resolve per-thread, each on its own verified evidence. |
| 31 | |
| 32 | ### Rationalization Table |
| 33 | |
| 34 | | Excuse | Reality | |
| 35 | |--------|---------| |
| 36 | | "The fix was committed, so it's done." | Read the CURRENT file and confirm the requirement is satisfied. Committed ≠ verified. | |
| 37 | | "Git diff shows the change." | A diff is historical reasoning. Confirm the requirement holds in the current file content, not that something changed. | |
| 38 | | "It's uncommitted, so it doesn't count yet." | Uncommitted local changes ARE valid evidence. Inspect the working tree as-is. | |
| 39 | | "I'll just make the small fix and resolve." | Editing code is strictly forbidden. Unfixed → unresolved. | |
| 40 | | "A reply would be polite." | No replies/comments. The only write action is resolving. | |
| 41 | | "Nitpick is trivial, resolve to tidy up." | Unaddressed = unresolved, regardless of triviality. | |
| 42 | | "Reviewer would obviously accept this." | You are not the reviewer. Resolve only on satisfied requirements, not on predicted approval. | |
| 43 | | "Not 100% sure, but likely fixed." | Unsure = leave unresolved. | |
| 44 | |
| 45 | ## How to Use |
| 46 | |
| 47 | Work one thread at a time: (1) load unresolved threads with their GraphQL node `id`, (2) for each, read the current file(s) referenced and check every requirement against the present content, (3) resolve ONLY if fully satisfied/obsolete, otherwise skip. Report what was resolved and what was left and why. |
| 48 | |
| 49 | ## Step 0: Verify what tools are available |
| 50 | |
| 51 | 1. Check if GitHub CLI is installed and authenticated: |
| 52 | |
| 53 | ```bash |
| 54 | gh auth status |
| 55 | ``` |
| 56 | |
| 57 | 2. Check if the GitHub MCP server is available: |
| 58 | |
| 59 | ```bash |
| 60 | mcp__MCP_DOCKER__pull_request_read |
| 61 | ``` |
| 62 | or simular command without `MCP_DOCKER` prefix, if installed directly. |
| 63 | |
| 64 | - if both are ava |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
