Use this skill when the user wants you to read and act on inline code review comments.
-
Fetch open comments:
get_review_comments() // all open comments
get_review_comments({ scope: 'line' }) // only line-level
get_review_comments({ scope: 'view' }) // only architectural / review-level
get_review_comments({ viewSource: 'tool-call' }) // only tool-call comments
get_review_comments({ toolCallId: "..." }) // one tool call's comments
get_review_comments({ viewSource: 'git-range', fromRef: 'main', toRef: 'HEAD' })
get_review_comments({ viewSource: 'browse' })
get_review_comments({ file: "src/foo.ts" }) // any anchor targets this file
get_review_comments({ status: "resolved" })
Each comment includes id, scope, anchors[], viewContext, body, status, replies. For scope line, each anchor additionally carries startLine / endLine / anchorText / sourceLines (the lines the reviewer pointed at). Tool-call comments additionally include a compact toolCall summary.
-
Understand the scope (optional):
get_tool_calls() // all captured tool calls
get_tool_calls({ file: "src/foo.ts" }) // calls on one file
get_tool_calls({ status: "complete" }) // pending | complete | orphan
-
Apply fixes — approach depends on scope:
- line — Read
sourceLines / anchorText to see exactly what the reviewer pointed at. side: "after" / "current" lines may still be at the same line numbers in the current file, but not guaranteed — the file can have drifted since the snapshot was taken. Use Read to confirm before editing. side: "before" references the file as it was before your edit ran (tool-call) or at the fromRef (git-range); the comment is usually asking you to revert or alter something you introduced.
- file — The reviewer wants a change somewhere in this file. Read the current file, identify what the comment implies, and decide the minimal scope of the edit yourself.
- multi-file — The reviewer wants a coherent change across the listed files. Read all of them first, plan the change (extract a helper? rename a symbol? fix the same bug pattern in each?), then edit.
- view — No file is pinned. Plan the change: may involve creating new files, adding tests, or a larger refactor. Consider asking the user for confirmation on scope before a big change.
-
Verify your fix before declaring it done. Closing the "I think I fixed it" gap is the whole point — never mark_resolved on faith. Run the project's standard check / test / lint:
- Detect the command from manifests at the project root:
package.json scripts (typecheck / test / lint), Cargo.toml → cargo check + cargo test (+ cargo clippy if the repo uses it), pyproject.toml → pytest / mypy / ruff, go.mod → go build ./... && go test ./.... Check for a Makefile. If you can't pick one confidently, ask the user once ("What's the verify command for this project?") and reuse the answer for the rest of the session.
- Scope the run to what you touched when possible (
cargo test -p foo, pytest path/to/test.py, npx tsc --noEmit -p tsconfig.json). Whole-suite is fine if narrowing is unclear — don't skip because it's slow.
- On pass → step 5.
- On failure →
reply_to_comment with a one-line summary plus the relevant failure snippet, leave the comment open (do not mark_resolved), and move on to other comments. The user will triage.
- Skip verify only when the change cannot affect runtime (
.md-only edits, removing dead comments). When in doubt, run it.
-
Reply on the thread explaining what you changed:
reply_to_comment({ id: "<comment-id>", body: "Extracted into helper `fooBar()`." })
Keep replies short. The body is rendered as GitHub-flavored Markdown in the browser, so use:
Reviewer comments and earlier replies are also Markdown — fenced code blocks in the body are usually suggestions, not literal text to copy unless the surrounding prose says so.
-
Mark resolved after the fix is verified and replied:
mark_resolved({ id: "<comment-id>" })
-
Generate a summary prompt (optional):
get_export_prompt({ mode: "report" })
