Skills-compatible agents / Engineering
Test-Driven Development
Builds features through small test-first steps at agreed public interfaces, rather than testing private implementation details.
316,504 repository stars · checked 2026-11-06. Count applies to mattpocock/skills, not this individual skill.
Guide by IDAKIM Digital. Source review: . Original explanation based on the linked publisher sources.
What it does
The selected TDD skill is one workflow in Matt Pocock’s engineering collection. It concentrates on tests that describe observable behavior and survive internal refactors. The source explicitly asks the user and agent to agree the test boundaries before writing tests. Its current version keeps the red/green implementation cycle distinct from a later review/refactoring stage.
When to use it
- A feature needs behavior-level tests before implementation.
- A bug needs a regression case through the supported interface.
- Existing tests break whenever internal code is reorganized.
Step-by-step workflow
- Read project conventions, domain vocabulary and architectural decisions.
- Propose the public interfaces to test, including what each boundary catches and misses; confirm them with the user.
- Write one test with an independently known expected result and observe it fail for the intended reason.
- Implement only the behavior needed for that test, then repeat with the next useful case.
- Keep implementation review and refactoring separate; rerun the behavior checks afterwards.
Example request
Use tdd for our shipping-cost calculator. First propose and confirm the public test boundary. Cover a normal domestic order, the free-shipping threshold and an unsupported destination. Work one failing test and minimal implementation at a time. Use known expected amounts from our policy; do not reproduce the implementation formula inside assertions.
Worked example
For a free-shipping threshold, the expected amount must come from the policy. A test that calculates its expectation using the same formula as the implementation can repeat the same bug. A public-interface test should keep passing when the calculation is moved to a different internal helper.
What you get
Behavior-level tests and the minimal implementation needed to satisfy each agreed case.
How to evaluate the result
- Confirm the requested artifact or behavior is actually delivered, with evidence appropriate to this workflow.
- Repeat the example on your own inputs and check the stated limits; repository popularity is not an execution test.
- Verify important facts, permissions and failure paths before adopting the result.
What you need
A repository with a runnable test setup, requirements and an agreed public test boundary.
Setup and activation
Follow the publisher README for your specific client and preserve the complete selected skill folder, including companion references and scripts. Claude Code, Codex and other hosts may use different plugin or Agent Skills installation paths. This guide does not establish that every host has the same tools. Security-scan the exact version before installation; this website installs or executes nothing.
Limits and considerations
This skill’s current workflow deliberately requests agreement on test seams. It is not a drop-in mandate to test every function, and it does not replace requirement discovery. Companion reference files explain testing and mocking choices.
Related workflows
- Use a task-specific validation workflow to check the final result.
- Review companion scripts and references before adding this skill to an agent.
License and reuse
MIT at repository level; inspect per-file terms and separately licensed assets before reuse.
Further reading
Read the original source
Publisher: mattpocock/skills
Source reviewed: 2026-11-06
Source reviewed; not installed, executed or security-scanned for this directory. These example requests were written by IDAKIM Digital. Upstream content can change.