Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add lugassawan/swe-workbench --skill principle-tddgit clone --depth 1 https://github.com/lugassawan/swe-workbenchWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/lugassawan/swe-workbench/principle-tdd)<a href="https://agentmods.dev/skills/lugassawan/swe-workbench/principle-tdd"><img src="https://agentmods.dev/badge/skills/lugassawan/swe-workbench/principle-tdd.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00082 | $0.01038 |
| Opus 5 | $0.00041 | $0.00519 |
| Sonnet 5 | $0.00016 | $0.00208 |
| Haiku 4.5 | $0.00008 | $0.00104 |
Grade A, and why
principle-tdd scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
The loop
- Red — one failing test describing the next slice of behavior. Run it; confirm it fails for the right reason.
- Green — simplest production code that passes. Hard-coding is allowed — it will be driven out by the next test.
- Refactor — with all tests green, improve the code and the tests. Never refactor on red.
Each cycle is minutes, not hours.
Rule of three
Duplication triggers refactor on the third occurrence. Two is coincidence; three is pattern.
F.I.R.S.T.
- Fast — milliseconds.
- Isolated — independent of order and other tests.
- Repeatable — deterministic anywhere.
- Self-validating — automatic pass/fail.
- Timely — written just before the production code.
What counts as "refactor"
Structural improvement with all tests green — no new behavior.
- Rename, extract, move — anything that clarifies intent or repositions code to the layer that owns it.
- Never add behavior during refactor — if a test turns red mid-refactor, revert the last step; the cycle was too large.
- Tests are part of refactor too — clean up names, builders, and assertions when production code changes shape.
Test doubles — pick the cheapest that works
One double per behavioral boundary, not one double per collaborator.
- Fake — working implementation (in-memory DB) — best for fast integration without real infrastructure.
- Stub — canned response — isolates the path under test.
- Spy — records calls for post-hoc assertion.
- Mock — pre-programmed expectations; fails on unexpected calls — strictest, most brittle.
Use the cheapest double that still proves the behavior.
Mocking pain is design feedback
A mock that is hard to build signals a bad seam, not a bad mock.
- Deep chains (
a.b().c().d()) — the SUT reaches too far; introduce a collaborator interface at the inflection point. - Leaky internals — mocking private state means the test knows the implementation; test through the public API instead.
- Time or network coupling — inject a
ClockorHttpClientabstraction; never mock the system clock globally. - Growing setup — more than ~5 lines to configure a double signals too many responsibilities in the SUT.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 83 lines · 82 tokens per session scan A e9939c3602ea
principle-tdd is a skill published in the GitHub repository lugassawan/swe-workbench (2 stars, last pushed 2d ago), licensed MIT. It adds 82 tokens to every session and 1,038 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
brooks-test
Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…
laravel-testing
Use when testing controllers, services, or models, or implementing TDD on Laravel 13 with Pest 4 / PHPUnit 12.
go-testing-quality
Use when writing or reviewing Go tests, adding coverage, benchmarking, or profiling a Go program. Not for CI/lint wiring (go-tooling-security) or non-Go tests.
improving-tests
Improve test design, speed, and coverage with behavior-focused tests, useful seams, characterization tests, TDD, and test refactoring. Use when improving tests, optimizing slow suites, adding coverage, refactoring brittle tests, removing test waste, or working test-first. NOT for fixing production bugs (use…
Component Test Scaffold (Next.js)
Generate React/Next.js component test skeletons (RTL) from specifications.
Component Test Scaffold (Vue.js)
Generate Vue.js component test skeletons (Vue Test Utils) from specifications.