Dev Debugger Plugin

Bug-ticket workflow for development repos. Capture bugs into the repo itself, dispatch specialist remediation agents, document fixes privately, and ship releases — all through Claude Code.

For system/runtime debugging (boot logs, crash diagnosis, slowdowns, deployment inspection) see the companion plugin os-debugging-plugin. This plugin is scoped to code/app bug workflows in development repos.

Commands

• /capture-bug — capture one or more bugs from the current repo into standardized reports under planning/bugs/to-resolve/ inside the repo. Sequential per-repo IDs, optional screenshots, optional hand-off to bug-manager.
• /patch — quick path for trivial fixes (typos, off-by-ones, obvious null-checks). Skips the full pipeline and dispatches patcher directly.

Agents

Orchestrator + specialist sub-agents:

• bug-manager — the orchestrator. Reads a bug report, triages complexity, and dispatches sub-agents in sequence. Handles verification, commits, and the post-fix release protocol.
• reproducer — attempts to reproduce the bug from its steps and reports observed failure mode. Read-only on source.
• diagnoser — locates root cause with file_path:line_number evidence. Read-only on source.
• patcher — makes the minimal code fix and verifies. Can also be invoked directly via /patch.
• fix-documenter — after a successful fix, writes a private (gitignored) post-mortem note to planning/bugs/resolved/BUG-XXXX-notes.md covering root cause, false leads, watch-list, and lessons.

Triage rules the bug-manager applies:

• Trivial → straight to patcher → fix-documenter
• Moderate → reproducer → diagnoser → patcher → fix-documenter
• Complex → same as moderate, with loop-back on verification failure

Where bug reports live

Bug reports are stored inside the target repository — not in a central location. This keeps bugs versioned alongside the code they concern.

<repo>/planning/bugs/
├── to-resolve/
│   ├── BUG-0001.md
│   ├── BUG-0002.md
│   └── screenshots/
└── resolved/
    ├── BUG-0000.md
    └── BUG-0000-notes.md     (private, gitignored by default)

On the first /capture-bug invocation in a repo, the command asks whether to commit planning/bugs/ (tracked in git, useful for team visibility) or gitignore it (local only, for public repos that shouldn't expose internal bug tracking). The private *-notes.md files written by fix-documenter are always gitignored regardless.

Each report uses YAML frontmatter (id, repo, status, severity, screenshots) and a standardized body (summary, repro steps, expected/actual, environment, remediation checklist).

Post-fix release protocol

After bug-manager verifies a fix, it follows the repo's release conventions:

• Local desktop apps (e.g. .deb): build → install → smoke-test (with user confirmation) → version bump → push → GitHub release. Prefers repo-specific release skills (/release, build-and-push-debian, create-package-release) when present.
• Library/CLI on a registry: test → patch-version bump → push → registry publish → release.
• Pure source: push; tag/release if convention calls for it.
• Private repos: stop after local verify + push.

Installation

claude plugins install danielrosehill/dev-debugger-plugin

Restart Claude Code after installation.

License

MIT