windbg-mcp: Skill for Claude Code

Working a review round

Both review bots comment per commit, and a round of findings can land after a reply to the previous round. Before calling a review done, re-check with the head SHA: gh api --paginate repos/<owner>/<repo>/pulls/<n>/comments --jq '.[] | select(.original_commit_id=="<sha>")' — with --paginate, since a busy PR's comments span pages and the first page is exactly where the older rounds are.

They also circle the same topic, and contradict each other and themselves across rounds. A bot reviews this diff without the argument that produced it, so the same seam comes back round after round from a different angle — and a finding framed as "fresh evidence relative to the prior comment" may be the same claim, or may be genuinely new. Three shapes seen across the four PRs behind FOLLOWUPS.md item 34 (#189 to #192), all from the same reviewer:

• Against code that no longer exists. One round argued about a teardown task the previous commit had deleted. Check which commit a comment is anchored to before acting on it.
• Round-tripping a decision. Successive rounds drove a check out of Lease::admit and then asked for it back. Both were right about different properties, and only reading the code settled which — the review text alone could not.
• Right about the fact, wrong about the remedy. "The SCM will not deliver a control code to a StartPending service" was correct (ERROR_SERVICE_CANNOT_ACCEPT_CTRL — measured, by holding a real service there with an address not on the host). Its proposed fix was a new IPC channel; the right fix was a message that stopped claiming otherwise.

So: verify the fact against the current code, then decide the remedy yourself. A correct finding does not make its suggested fix correct, and a confident one is not evidence of anything. Measuring beats arguing whenever the claim is about behaviour: most of these were settled in one experiment.

Declining is a normal outcome, and where the reason goes depends on whether the decline shaped a change. If you are committing anyway — you took the fact and rejected the remedy — the reason belongs in that commit message, because the next round will raise it again against code that by then looks deliberate, and nothing else will record why it is the way it is. If nothing changed, there is nothing to attach a reason to and nothing to protect: repeating the decline next round costs a sentence, so tell whoever is driving the work and leave it there. Do not manufacture a commit, and do not argue with the bot in a reply — neither is read by the round that follows.

A finding about prose is acted on only if the prose is wrong, or inconsistent with the code. Everything else — rewording, hedging, "consider splitting this rule across the three files that state it" — is declined, which by the rule above means no commit and no reply: nothing changed. Say it to whoever is driving the work, in one line, so the count of what was waved through stays visible to them rather than only to you.

The rule exists because the review pressure here is almost entirely on sentences: across #196, #198 and #199, every bot finding was about one, and none was about the code those PRs changed. Most of that pressure pushes toward making correct sentences longer, which is churn and costs a CI round each time. What the rule still catches, all from those three PRs:

• Wrong. A config documented as .markdownlint-cli2.jsonc; the file is .markdownlint.jsonc. And a skill saying --set-listen-client-tools <name> changes a client's surface, when with no --tools beside it that command clears the spec — an operator following it removes the restriction they meant to change.
• Inconsistent with the code. A refusal telling every caller to run a service-only command, when a foreground listener's clients come from the environment. And "a change reaches a client when it next connects", which describes one MCP revision while the listener's factory identifies a sessionless client on every request. Neither sentence is false on its face; both produce the wrong action.
• Inconsistent with its own cited source. A list of the three handoff files, contradicted by one of the PRs named as its origin.