From workbench-dev-team
Apply universal development standards when implementing code changes, fixing bugs, refactoring, writing tests, or any task that writes or modifies source code. Use this skill BEFORE writing or changing code — every time, manual or agent-driven — to ensure consistent conventions, testing, commit hygiene, and a human-in-the-loop decision protocol across all development work. Triggers on requests to "implement", "build", "fix", "add", "refactor", "write a test", "code up", or any prompt that produces code changes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/workbench-dev-team:developThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Universal standards for any code implementation work. The goal isn't compliance —
Universal standards for any code implementation work. The goal isn't compliance — it's predictably high-quality changes that future-you (or anyone else) can read, trust, and extend.
When you hit a fork — choosing between approaches, libraries, structures, scopes, or fixes — stop and surface three options to the human with reasoning for each, and a recommendation for the best one. The human decides; you execute.
What counts as a fork:
What doesn't count — just do it:
Format when presenting options:
1. **Option A** — short description.
Pros: ...
Cons: ...
2. **Option B** — short description.
Pros: ...
Cons: ...
3. **Option C** — short description.
Pros: ...
Cons: ...
**Recommendation: B** — because [reason this is the best fit].
Then wait for the human's pick before proceeding. Don't half-commit by starting on the recommended option while waiting — that's the same as deciding unilaterally, just with extra steps.
If you genuinely can't think of three viable options, surface that — "I can only see two reasonable approaches here, A and B. Want me to pick a stretch third option, or is this a two-way choice?" Honest is better than padded.
CLAUDE.md if present. Repo conventions take precedence over personal
preference. Always.git log --oneline -20) for the prevailing commit
format and the kinds of changes that land. Pattern-match.If the repo has no CLAUDE.md and conventions are unclear from sibling files,
flag it — don't guess.
Never run git commit without explicit human approval for that specific
commit. Before any commit:
/workbench-dev-team:git-commit skill).This is enforced at the harness level too: a plugin PreToolUse hook
(hooks/scripts/commit-approval-gate.sh) forces a permission prompt on every
git commit, regardless of permission mode. The prose protocol above is what
makes that prompt meaningful — the human must already have the diff and
message in front of them when it appears.
Sole exception — the autonomous Index pipeline. Scheduled Watson runs are
headless; there, dispatching an item to the board is the approval, and Holmes
review plus the human's PR merge is the gate. The hook recognizes the pipeline
by a live /tmp/watson.lock or WORKBENCH_DEV_TEAM_PIPELINE=1. Never set
that variable or create that lock to skip approval in interactive work.
Use the /workbench-dev-team:git-commit skill for message format —
Conventional Commits + Gitmoji. Beyond format:
.env-shaped files are in .gitignore. If anything smells like
a credential, stop and remove it before staging.git diff what you're about to
commit — catch debug console.logs, commented-out code, TODOs you forgot
to address, leftover scaffolding.main/master/trunk) before
pushing.When the work is for a tracked issue:
gh pr create --body
silently bypasses templates, so discover and apply it yourself. Check, in
order: .github/PULL_REQUEST_TEMPLATE.md, PULL_REQUEST_TEMPLATE.md
(root), docs/PULL_REQUEST_TEMPLATE.md — any letter case — and
.github/PULL_REQUEST_TEMPLATE/ (multiple templates; pick the one that
fits the change, or the default). Fill its sections honestly — never leave
boilerplate placeholders or HTML comments behind. If the template has no
slot for something required below (issue link, acceptance criteria, test
plan), append it after the template content. No template → use the
structure in the next bullets.Fixes #<n> in the body for auto-linking.npx claudepluginhub mike-bronner/claude-workbench --plugin workbench-dev-teamProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.