bullpen

Plugin bullpen from marketplace awesome-claude-code-plugins in ccplugins/awesome-claude-code-plugins. Commands read from the repo's manifest — 1 month ago.

Skills (10)

• attacker

  Adversarial self-review for code that touches a trust boundary. After you write or change code that handles untrusted input, authenticates, authorizes, queries a database, reads files, makes network calls, runs a subprocess, deserializes, or handles secrets or money — switch hats and try to break yo

• chameleon

  Match the house style when adding code to an existing codebase. Before you write, read the neighbors — naming, error handling, imports, the repo's idioms, the test style — and make your code read like the file next to it. Reuse the project's own helper, wrapper, or Result-type instead of importing y

• closer

  Anti-premature-"done". Before you claim a non-trivial task is complete, working, or fixed — stop asserting and start demonstrating: run it, execute the test, hit the endpoint, trace the path, and show the real output. "Done" means proven, not believed. If you genuinely can't run it, say exactly what

• doorman

  Dependency gatekeeper. Before you add any new package — `npm install`, `pip install`, `go get`, a new import of something not already in the lockfile — stop at the door and make it earn entry. Ask whether the stdlib, the runtime/platform, or a dep already installed does the job, and whether a few li

• explainer

  Reviewable git hygiene for work you're about to commit or open a PR for. Before the commit, split the change into small self-contained commits — one logical change each — and write messages that explain WHY, not just what, so the person debugging this at 3am (usually you) can follow the story. Struc

• fact-checker

  Anti-hallucination discipline for any code that names an external symbol you aren't certain exists — a library function, method, config key, package version, CLI flag, env var, or endpoint. Before you call it, cite it, or import it, confirm it's real: grep the codebase, read the installed package's

• historian

  Chesterton's Fence for code you're about to delete or refactor. Before you rip out a weird retry, a seemingly dead branch, an ugly workaround, or a "redundant" check whose purpose isn't obvious — find out why it exists first. git blame it, find the callers, read the linked issue/PR/commit. If you ca

• interrogator

  Anti-guessing discipline for ambiguous requests. Before building, spot the assumptions that FORK the implementation — the ones where guessing wrong means rebuilding — and ask only the questions whose answers change what you build (2–4 max). When a request is under-specified in a way that changes the

• skeptic

  Anti-sycophancy for build requests that encode a wrong assumption. Before you touch the keyboard, separate what the user ASKED for from what they're trying to achieve — and if the request bakes in a mistake (premature optimization, complexity bigger than the problem, cargo-culted pattern, solving th

• stop-digging

  Anti-thrashing circuit-breaker. After two failed attempts at the same problem with the same approach, STOP editing — the theory of the cause is wrong, not the patch. Re-examine assumptions, add instrumentation, and trace from the source before touching code again, instead of re-trying variations of

Similar plugins