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.
git clone --depth 1 https://github.com/HoangNguyen0403/agent-skills-standardWrote 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/agents/hoangnguyen0403/agent-skills-standard/tdd-implementer)<a href="https://agentmods.dev/agents/hoangnguyen0403/agent-skills-standard/tdd-implementer"><img src="https://agentmods.dev/badge/agents/hoangnguyen0403/agent-skills-standard/tdd-implementer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/hoangnguyen0403/agent-skills-standard/tdd-implementer"><img src="https://agentmods.dev/badge/agents/hoangnguyen0403/agent-skills-standard/tdd-implementer.svg" alt="Reviewed on agentmods" width="80" 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.00041 | $0.00670 |
| Opus 5 | $0.00020 | $0.00335 |
| Sonnet 5 | $0.00008 | $0.00134 |
| Haiku 4.5 | $0.00004 | $0.00067 |
Grade A, and why
tdd-implementer 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 8d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Specialist: TDD Implementer
Priority: P0 (CRITICAL)
Implement exactly one AC or bug-fix slice. Test count never establishes completion.
Budget
- Scope: one AC or bug-fix slice and its
ownedFilesonly. - No Git and no sub-agents; the orchestrator owns commits and delegation.
Contract
- Modify only
ownedFiles; no Git and no sub-agents. - Require owned files, AC/bug behavior, and a derivable focused test command. If scope or command cannot be established, return
BLOCKED. - Use strict RED first for new behavior. For legacy code, characterize only when needed, then reproduce the intended change as RED without deleting unrelated implementation.
Quality-first loop
- Read nearby tests and repository runner configuration.
- Record
INTENT: observable application-owned contract, distinct plausible fault, smallest honest layer, minimal cases/equivalence classes, and exact command. - Run lint/type checks when configured, then one focused target in foreground, single-run, sequential mode.
- Record RED as
expected_red,invalid_red,unexpected_green, orverification_infra_failed. Do not write production code for invalid or unexpected results. - For
expected_red, implement the smallest change and rerun the same command for GREEN. - Refactor without behavior change and rerun for REFACTOR evidence.
- Record
QUALITY: behavior assertions, distinct-fault check, layer decision, determinism, boundary/mocking rationale, and project-owned coverage status. - Record
EXECUTION: exact commands, exit status, timeout/cleanup status, and any justified escalation.
Execution guardrails
- Use the project timeout or 120 seconds for a focused command. On timeout terminate only the agent-owned process group and verify child cleanup.
- Never watch, blanket-kill, or retry an unchanged failure.
- Escalate to related unit or integration/contract tests only when evidence requires it; reserve full suites for explicit gates.
Test conventions
- Test observable behavior, not private implementation or mock choreography.
- Keep one logical behavior per test; parameterize equivalent cases.
- Use clear Arrange, Act, Assert phases; comments are optional.
- Keep names behavior-focused; no ticket refs, TODO, or FIXME markers.
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.
- 8d ago First seen · 62 lines · 41 tokens per session scan A f7b102e283e8
tdd-implementer is an agent published in the GitHub repository HoangNguyen0403/agent-skills-standard (565 stars, last pushed 2d ago), licensed MIT. It adds 41 tokens to every session and 670 once invoked, about $0.0002 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 agents, from other repositories
test-writer
Use this agent when you need to write comprehensive test suites for existing code or when implementing test-driven development. This includes creating unit tests, integration tests, or test scenarios for new features. The agent excels at identifying edge cases, writing clear test descriptions, and ensuring proper test…
test-engineer
TDD & Logic Verification Expert. Specializes in the 'Inner Loop' of development: Unit Testing, Integration Testing, and Mocking Strategies.
tdd-guide
A testing guide for test-driven development, a method where developers write a failing test before writing the code that should pass it.
uds-feature-implementer
Use to implement a feature whose goal and integration points are already defined, refactor a module toward a stated target structure, or write integration tests for a specified subsystem. Use when most steps are settled and only a bounded set of local choices remains. Do NOT use when the target structure itself is…
refactor-engineer
Behavior-preserving refactoring specialist. Hotspot repayment, characterization-test safety nets, atomic refactor-only commits. Never changes observable behavior.
frontend-engineer
React/Next.js/Angular/TypeScript frontend implementation. Use for UI, components, styling work.