harness/plugins/work-manager/common/skills/review-fix-comments/SKILL.md
Read agent-review comments via MCP tools and/or GitHub PR review comments, fix each one in the code, and mark as applied. Use when user says "fix comments", "apply comments", or "resolve comments".
npx skillsauth add popoffvg/dotfiles review-fix-commentsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fix comments from local agent-review and/or GitHub PR reviews.
Collect from both sources, merge into a single work list.
comment_list(status: "pending") to get all pending comments.comment_get(id).Detect current PR: run gh pr view --json number,url,baseRefName --jq '.number'. Skip if no PR.
Fetch the review diff (revdiff):
gh pr diff --name-only # list changed files
gh pr diff # full diff
Fetch unresolved review comments:
gh api graphql -f query='
query($owner:String!, $repo:String!, $pr:Int!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$pr) {
reviewThreads(first:100) {
nodes {
isResolved
comments(first:10) {
nodes { body path line databaseId author { login } }
}
}
}
}
}
}' -f owner=OWNER -f repo=REPO -F pr=NUMBER
Extract owner and repo from gh repo view --json owner,name.
Filter to isResolved: false. Map to common format:
absPath = workspace root + pathline = comment line (diff-relative — resolve via revdiff)text = comment bodysource = "github"GitHub review comments reference line numbers in the diff, not in the current file.
Algorithm:
@@ -old,len +new,len @@).+ and context lines).+ and context lines (skip - lines).text to narrow down.Never blindly trust the line number from a review comment.
Group related comments with the same fix pattern across files. Plan one consistent strategy.
For each pending comment:
absPathline (1-based)text — it describes what to fixcomment_update_status(id, status: "applied")comment_update_status(id, status: "failed", lastError: "reason"); GitHub → note in summarySummary: Print counts of applied, failed, skipped — by source (local / GitHub).
.vscode/agent-comments.json directly — use comment_list, comment_get, comment_update_status MCP toolslastError)fileHash mismatch, warn but still attemptabsPath doesn't exist → comment_update_status(id, status: "failed", lastError: "file not found")gh unavailabletools
Improve a whole CLAUDE.local.md — the private, per-project rules captured from user corrections. Wraps each conditional rule in a <task-relevant> block so it only surfaces for matching work, merges duplicates, generalizes one-off facts, drops stale entries, and routes raw project facts to engram. Use when the user says "improve claude.local", "clean up the local rules", "claude.local is bloated", or after the Stop hook has appended many rules.
testing
WM pipeline and conventions shared across all phases. Agents must read this before spec, impl, or verify work.
development
One entry point for spec writing, implementation, and bug fixing. Default is new (write spec → grill loop → produce notes → author TODO bodies). Other subcommands: verify (audit), revise (sync to shipped), prototype (settle a decision), code-map (diagram), impl (execute one TODO), fix (analyze cause, correct thoughts, fix behavior), help (this page). Invoke as /code <subcommand>.
development
Red-Green-Refactor cycle for bug fixes. Before fixing a bug, first write a failing test that reproduces it (Red), then make the minimal change to pass (Green), then clean up the code (Refactor). Use on any bug fix, error correction, failing test repair, or when user says "fix this bug".