# Driving Cursor Bugbot > Review Cursor Bugbot PR threads, classify findings, fix real bugs, reply inline, and push updates. - Skill: `socketdev/driving-cursor-bugbot` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add socketdev/driving-cursor-bugbot` - Raw SKILL.md: https://api.skillmd.com/api/skills/socketdev/driving-cursor-bugbot/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: socketdev (https://skillmd.com/u/socketdev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/socketdev/driving-cursor-bugbot --- # 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`](lib/bugbot.mts); the skill keeps only the AI judgment (classify each finding) and the human-stop inline. ## Script ```bash # List Bugbot findings as JSON ({ id, path, line, body, commitId }). node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts inventory # Candidate "already fixed" findings: each finding + later commits touching its file. node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts already-fixed # Threaded reply on one inline comment; auto-resolves on fixed/already-fixed/false-positive, # leaves wont-fix open. State ∈ {fixed, already-fixed, false-positive, wont-fix}. node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts reply "" # Sweep a PR's Bugbot threads and resolve every one that already has an author reply. node .claude/skills/fleet/driving-cursor-bugbot/lib/bugbot.mts resolve ``` 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 ` | Full audit-and-fix on one PR (default). | | `/driving-cursor-bugbot check ` | List Bugbot findings, classify them — don't fix or reply. | | `/driving-cursor-bugbot reply ` | Single reply where `` is `fixed` / `false-positive` / `wont-fix`. Auto-resolves on `fixed` / `false-positive`; leaves open for `wont-fix`. | | `/driving-cursor-bugbot resolve ` | Sweep open Bugbot threads with author replies and resolve them. | | `/driving-cursor-bugbot scope ` | 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//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`](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//comments//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(): address Bugbot finding on :`. - **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.