From workbench
Use when implementing any feature, bugfix, refactor, or behavior change before writing implementation code. Enforces test-first RED-GREEN-REFACTOR discipline.
npx claudepluginhub pgoell/pgoell-claude-tools --plugin workbenchThis skill uses the workspace's default tool permissions.
Use this skill before implementation work. It governs each small implementation chunk until the change is complete.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Use this skill before implementation work. It governs each small implementation chunk until the change is complete.
Write the test first. Watch it fail for the expected reason. Write the smallest code that makes it pass. Refactor only after green.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
If implementation code was written before the test, delete that implementation and restart from the test. Do not keep it as reference material.
Use for:
Exceptions require an explicit user decision:
Write the smallest test that expresses one expected behavior.
Requirements:
Run the narrowest useful test command.
Confirm:
If the test passes immediately, it does not prove the new behavior. Fix the test before writing implementation code.
Write only the implementation needed for the failing test.
Do not add:
Run the narrow test again and confirm it passes. Then run the relevant broader test command for the touched area.
If the test fails, fix implementation code first. Only change the test if the expected behavior is wrong.
After green only:
Keep the same tests green after every refactor.
| Quality | Good | Bad |
|---|---|---|
| Minimal | One behavior. | A test name with "and" covering multiple behaviors. |
| Clear | Name states the expected behavior. | test1 or works. |
| Behavior-focused | Exercises public behavior. | Checks private implementation details. |
| Repeatable | Runs without manual state. | Depends on local setup not created by the test. |
| Excuse | Response |
|---|---|
| "Too simple to test." | Simple code still breaks. Write the small test. |
| "I'll test after." | Tests written after implementation can pass without proving they catch the missing behavior. |
| "I already manually tested it." | Manual checks are not repeatable regression coverage. |
| "The existing code has no tests." | Add the narrowest test around the behavior you are changing. |
| "Keeping the code as reference is harmless." | Reference code biases the test. Delete it and restart test-first. |
| "TDD is slowing me down." | Debugging untested behavior is usually slower than proving it incrementally. |
Stop and restart the chunk if any of these happen:
When executing a Workbench implementation plan, this skill is invoked as workbench:test-driven-development:
If a chunk is too large to test first, split the chunk. Hard-to-test behavior is usually underspecified or poorly isolated.
Use the test runner documented by the project. In this repository, prefer deterministic filesystem checks for skill structure and run the frontmatter lint after changing any SKILL.md.