tdd-workflow
by affaan-mtdd-workflow is a test-first workflow skill for new features, bug fixes, and refactors. It enforces TDD with 80%+ coverage across unit, integration, and E2E tests, plus explicit checkpoints and edge-case validation. Use the tdd-workflow skill when you need a practical guide for Test Automation and more predictable code changes.
This skill scores 74/100, which means it is worth listing for users who want a TDD-enforcing workflow with explicit test-first and coverage guidance, but it is not yet a highly polished install decision page. The repository provides enough real operational detail for agents to use it, though users should expect some gaps in quick-start clarity and implementation support.
- Clear activation intent for common coding tasks like new features, bug fixes, refactors, and API endpoints.
- Concrete workflow rules: tests before code, minimum 80% coverage, and separate unit/integration/E2E coverage guidance.
- Substantial body content with many headings and constraints, giving agents more structure than a generic prompt.
- No install command, support files, scripts, or references, so adoption depends almost entirely on the SKILL.md prose.
- Contains placeholder/test-like signals and no repo/file references, which reduces trust in execution support and edge-case handling.
Overview of tdd-workflow skill
What tdd-workflow does
tdd-workflow is a test-first execution skill for feature work, bug fixes, and refactors. It is designed to help you move from a rough implementation idea to code that is verified by unit, integration, and E2E tests instead of being patched after the fact.
Who should install it
Install the tdd-workflow skill if you want a stricter development loop for app code, APIs, UI changes, or automation-heavy work. It is especially useful when you need predictable coverage, explicit edge-case handling, and a repeatable order of operations for Test Automation work.
Why it stands out
The main value of tdd-workflow is discipline: tests come before code, coverage targets are explicit, and the workflow expects evidence at each stage. That makes it more decision-useful than a generic “write tests” prompt because it pushes the agent to plan, verify, and checkpoint instead of jumping straight to implementation.
How to Use tdd-workflow skill
Install and activate
Use the tdd-workflow install flow for this repo, or add it through your Claude Code skills path if your setup manages skills manually. The important part is that the agent sees the skill before it starts coding, not after a first draft already exists.
Give the skill the right task shape
The tdd-workflow usage pattern works best when your request names the change, the risk, and the expected proof. Weak input: “fix login.” Strong input: “Add password reset validation, cover API and UI error states, and keep the current auth contract unchanged.” The second version gives the skill enough structure to write tests first and choose the right mix of unit, integration, and E2E coverage.
Read these files first
Start with SKILL.md, then inspect the repo’s README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist. For this repo, SKILL.md is the only visible source file, so treat it as the canonical workflow spec and adapt it to the target project’s test stack and constraints.
Follow the workflow in order
Use the skill to define the failing tests first, then implement the smallest code change that makes them pass, then run the next layer of validation. If your repository supports Git checkpoints, preserve a commit after each TDD stage so the evidence trail stays readable and reversible. This matters most when the work spans backend logic, API boundaries, and browser behavior.
tdd-workflow skill FAQ
Is tdd-workflow only for large changes?
No. The tdd-workflow skill is useful for small bug fixes too, especially when the bug is subtle or likely to regress. It is less valuable for trivial copy edits or one-line config changes that do not benefit from staged verification.
Do I need a mature test suite first?
Not necessarily, but you do need enough test tooling to make the workflow real. If a project has no practical unit, integration, or E2E setup, the tdd-workflow guide will still help with process, but the coverage targets may need to be adapted to the repo’s actual test boundaries.
How is this different from a normal prompt?
A normal prompt may ask for code and tests together. tdd-workflow changes the order and the decision rules: tests first, coverage expectations explicit, and validation staged by test type. That usually reduces guesswork when you are doing Test Automation or working across multiple layers of the stack.
Is it beginner-friendly?
Yes, if you are comfortable reading test failures and following a stepwise loop. Beginners benefit from the structure, but they should keep the task narrow and provide clear acceptance criteria; otherwise the workflow can feel strict instead of helpful.
How to Improve tdd-workflow skill
Provide sharper acceptance criteria
The best input to tdd-workflow says what must work, what must not change, and how success will be checked. Include inputs, outputs, failure cases, and any compatibility constraints. For example: “Reject empty email, preserve existing response shape, and cover the browser path plus API error handling.”
Ask for the right test mix
The skill performs better when you specify where risk lives. If the change touches business logic, ask for unit tests first. If it crosses service boundaries, require integration coverage. If the user journey matters, add E2E checks. That prevents the workflow from overusing one test type and missing the real failure mode.
Watch for common failure modes
The most common problem is over-implementing before tests are stable. Another is treating 80%+ coverage as a box to tick instead of a signal to cover edge cases, boundaries, and error paths. If the first pass is too broad, narrow the scope and rerun the tdd-workflow usage loop with one scenario at a time.
Iterate with evidence
After the first output, review which test failed, what behavior was proven, and what remains untested. Then ask for the next smallest increment rather than a full rewrite. For tdd-workflow for Test Automation, this usually means tightening selectors, explicit assertions, and negative-case coverage before expanding to more user flows.