workbench

Plugin workbench from marketplace j0hanz-marketplace in j0hanz/j0hanz-marketplace. Commands read from the repo's manifest — today.

Skills (24)

• architecture-audit

  Repo-wide architecture audit. Use when asked to find structural debt or to judge whether a repo's shape still holds. Not for one branch's diff (qc).

• bug-hunt

  Hunt bugs in code just written. Use when asked to review code for bugs, when correctness or security is in doubt before shipping, or after an agent produced work. Not for reproducing a reported symptom (diagnose) or maintainability (qc).

• clean-code

  Readability pass over code that already works. Use when asked to tidy code or review a diff for readability, or when code smells are named. Not for correctness defects (bug-hunt) or branch-wide structure (qc).

• diagnose

  Debug a bug whose cause is unknown. Use on a flaky test, a production-only crash, a wrong result on one input, or any symptom that must be reproduced before fixing. Not for static review of written code (bug-hunt).

• frontier

  Break work too big for one session into a ticket map. Use when the path from a loose idea to done is unclear, or to resume a map. Not for one-session changes (write-plan) or approaches not yet generated (ideation).

• grilling

  Grill the user on every decision only they can make. Use when asked to grill, or when a task needs the user's own judgement. Not for facts a source can answer (research) or options not yet generated (ideation).

• handoff

  Compact this session into a file the next one starts cold from — live state, dead ends, and the command it runs first.

• ideation

  Brainstorm candidate approaches to an open problem. Use when no options are on the table yet, or when a lone approach has never faced a rival. Not for picking among options already on the table (grilling).

• init

  Bootstrap a repo's Claude Code context — a root CLAUDE.md, and the decision on whether hooks or skills earn a place; hook candidates surface from session history and memory.

• plan-hunt

  Hunt a written plan for dead steps. Use once write-plan has written a plan and before run-plan executes it, or when a plan looks executable but is suspect. Not for hunting code (bug-hunt).

• prototype

  Prototype the open question with a spike, a cheap rough artifact to react to. Use when "how should it look or behave" has stalled in abstract talk. Not for decisions a question alone settles (grilling).

• qc

  Review a whole branch diff for maintainability. Use once a branch's changes have landed and the question is whether the shape holds — layering, indirection, duplication. Not for correctness or security defects (bug-hunt) or readability inside a function (clean-code).

• refactor

  Refactor without changing behavior. Use when asked to restructure, extract, move, or split code, or when a review hands over a structural fix. Not for readability (clean-code) or adding behavior (write-plan, tdd).

• research

  Research a question in primary sources. Use when it needs sources, not the user — how a library behaves, what a spec requires, where something lives in this repo. Not for user decisions (grilling) or failures to reproduce (diagnose).

• run-plan

  Execute a written plan. Use when handed a plan file, or resuming one mid-flight. Not for writing the plan (write-plan) or reviewing a suspect one (plan-hunt).

• spec-hunt

  Hunt a written spec for gaps a cold executor would hit. Use once a spec is written, before write-plan builds on it, or when a spec looks complete but is suspect. Not for plans (plan-hunt) or code (bug-hunt).

• tdd

  Build behavior test-first. Use when a step adds behavior, when adding tests to existing code, or when deciding what to mock or whether a test earns its place. Not for planning the build (write-plan) or spec sign-off (verify-specs).

• verify-specs

  Verify a built system against its spec, with a verdict per requirement ID. Use when a change lands against a spec, or before signing one off. Not for writing requirements (write-specs).

• write-adr

  Record a settled decision as an ADR. Use when the decision will outlive the effort that made it. Not for behavior a change must deliver (write-specs), or decisions not yet settled (grilling).

• write-hooks

  Write or audit a Claude Code or Copilot CLI hook. Use when something should run automatically on an event, or a hook misfires or never fires. Not for the skill carrying it (write-skills) or the plugin manifest and catalog.

• write-plan

  Write an implementation plan. Use when the behavior is settled and how to build or fix it is open — a pinned cause, settled spec, hunt finding, or review comment. Not for deciding the behavior (write-specs) or multi-session work (frontier).

• write-qa

  Write coverage-mapped QA deliverables. Use when asked for a test plan, manual test cases, a regression suite, or a bug report. Not for automated tests (tdd) or hunting bugs in code (bug-hunt).

• write-skills

  Write, fix, or audit a skill's frontmatter, trigger description, and body. Use when a skill is asked for, never fires, or fires at the wrong moment. Not for a hook (write-hooks) or the plugin manifest and catalog.

• write-specs

  Spec a feature's observable behavior. Use when asked for requirements, when a request says what the system should do but not how, or to capture what a built system already guarantees. Not for how to build it (write-plan).

Hooks (6)

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/brief.mjs"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/gate.mjs"

• SessionStart

  node "${CLAUDE_PLUGIN_ROOT}/hooks/brief.mjs"

• UserPromptSubmit

  node "${CLAUDE_PLUGIN_ROOT}/hooks/brief.mjs"

• UserPromptExpansion

  node "${CLAUDE_PLUGIN_ROOT}/hooks/brief.mjs"

• Stop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/stale.mjs"

Similar plugins