| name | driving-cursor-bugbot |
| description | Review Cursor Bugbot PR threads, classify findings, fix real bugs, reply inline, and push updates. |
| user-invocable | true |
| allowed-tools | Read, Edit, Write, Grep, Glob, AskUserQuestion, Bash(node:*), Bash(gh:*), Bash(git:*), Bash(pnpm run:*), Bash(rg:*), Bash(grep:*) |
| model | claude-sonnet-4-6 |
| context | fork |
| metadata | {"internal":true} |
driving-cursor-bugbot
Drives the Cursor Bugbot fix-and-respond loop end-to-end. The canonical flow every PR author should run after Bugbot posts findings.
Why a skill
Cursor Bugbot's review surface is easy to mis-handle:
- Replies must thread on the inline review-comment, not as a detached PR comment. A detached
gh pr comment doesn't mark the thread resolved and the bot doesn't see it as a response.
- Findings stale after fixes land. Bugbot reviews a specific commit SHA. When you push a fix, the comment still references the old commit; the thread stays open until you reply marking it resolved.
- Stale findings vs. live bugs vs. false positives all read the same on the API surface. Triaging needs a process, not vibes.
- Scope creep on PRs. CLAUDE.md mandates "When adding commits to an OPEN PR, update the PR title and description to match the new scope." Easy to forget when you're heads-down fixing Bugbot findings.
This skill makes all of the above mechanical. The gh/GraphQL plumbing (inventory, threaded reply, conditional resolveReviewThread, the already-fixed git-log scan) lives in lib/bugbot.mts; the skill keeps only the AI judgment (classify each finding) and the human-stop inline.
Script
node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts inventory <PR#>
node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts already-fixed <PR#>
node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts reply <comment-id> <state> "<body>"
node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts resolve <PR#>
The script resolves owner/repo from gh repo view, so it works in any fleet checkout. gh is the only auth surface (keychain token, never in argv). Use it for the plumbing; do the classification (real / already-fixed / false-positive / wont-fix) and write each reply body yourself.
Modes
| Invocation | What it does |
|---|
/driving-cursor-bugbot <PR#> | Full audit-and-fix on one PR (default). |
/driving-cursor-bugbot check <PR#> | List Bugbot findings, classify them — don't fix or reply. |
/driving-cursor-bugbot reply <comment-id> <state> | Single reply where <state> is fixed / false-positive / wont-fix. Auto-resolves on fixed / false-positive; leaves open for wont-fix. |
/driving-cursor-bugbot resolve <PR#> | Sweep open Bugbot threads with author replies and resolve them. |
/driving-cursor-bugbot scope <PR#> | Re-evaluate the PR title and body against the actual commits and rewrite when out of step. |
Phases
| # | Phase | Outcome |
|---|
| 1 | Inventory | List Bugbot findings via gh api .../pulls/<PR#>/comments. Capture id, path, line, body. |
| 2 | Classify | Sort each finding into real / already-fixed / false-positive / wont-fix. |
| 3 | Fix | Implement fixes for real findings. Propagate to canonical (socket-wheelhouse/template/) when the file is fleet-shared. One commit per finding. |
| 4 | Reply + resolve | Reply on each inline thread (NOT detached); resolve on fixed / already-fixed / false-positive; leave wont-fix open. |
| 5 | Title + body realignment | Per CLAUDE.md, update PR title / body when scope shifted. Use gh pr edit. |
| 6 | Push | git push. Bugbot re-reviews; loop back to phase 1 if new findings. |
API surface, GraphQL queries, and reply templates in reference.md.
Classification rubric
| Bucket | Meaning | Action |
|---|
real | Live bug, reproducible against current PR HEAD. | Fix the code, push, reply with the fix commit SHA. |
already-fixed | Bugbot reviewed an old commit; later commit on the same PR fixed it. | Reply citing the existing fix commit SHA. No new code. |
false-positive | Bugbot misread the code (hash length miscount, regex backtracking false-flag, JSDoc-example mistaken for runtime code). Often confirmed by Bugbot Autofix reply on the same thread. | Reply explaining why; cite a counter-example or the autofix verdict. |
wont-fix | Real but out of scope (would re-open resolved arguments, blocked on upstream change, intentional design choice). | Reply with rationale + link to follow-up issue. Don't auto-close — reviewer decides. |
To check already-fixed: read git log on the PR branch since the comment's commit_id and look for a commit that touches the file at that line.
Hard requirements
- Reply on the inline thread, never a detached PR comment. (
gh api .../pulls/<PR#>/comments/<id>/replies, not gh pr comment.)
- Reply first, resolve second. Resolving without a written reply leaves future readers blind.
- One commit per
real finding. Don't bundle. Conventional Commits: fix(<scope>): address Bugbot finding on <file>:<line>.
- Push after each fix; reply with the new commit SHA. The reply cites the SHA, so the SHA must already be pushed.
- Propagate canonical fixes. When the file lives under
.claude/hooks/, .claude/skills/, or .git-hooks/, fix at socket-wheelhouse/template/ first, then sync to consumers. Drifting fleet copies is the larger bug.
- Never run on a draft PR. A draft is explicit WIP, not a review target.
inventory() calls assertNotDraft() and throws before any fetch/reply/push, so every mode refuses a draft.
When to use
- After
gh pr create: Bugbot reviews most PRs within ~1 minute.
- After pushing a Bugbot-related fix: confirms the new HEAD didn't introduce new findings.
- Before merging: sweep open Bugbot threads. CLAUDE.md merge protocol depends on threads being resolved (replied to, not necessarily approved).
Success criteria
- Every Bugbot finding has a reply on its inline thread.
- Every
real finding has a corresponding fix commit on the PR branch.
- Every reply that closes the matter (
fixed / already-fixed / false-positive) is followed by resolveReviewThread. wont-fix threads stay open.
- PR title and body match the actual commits.
- PR branch is pushed.
