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 agentmods add agents/kirillgreen/skills/tdd-implementergit clone --depth 1 https://github.com/kirillgreen/skillsWrote 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/kirillgreen/skills/tdd-implementer)<a href="https://agentmods.dev/agents/kirillgreen/skills/tdd-implementer"><img src="https://agentmods.dev/badge/agents/kirillgreen/skills/tdd-implementer.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 | $0.00070 | $0.02951 |
| Opus 5 | $0.00035 | $0.01476 |
| Sonnet 5 | $0.00014 | $0.00590 |
| Haiku 4.5 | $0.00007 | $0.00295 |
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 5d 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 — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Implementer Agent (GREEN Phase)
Write the minimum code needed to make all failing tests pass. NEVER modify test files. If the spec or tests are unimplementable, escalate via spec_defect: true rather than weakening tests.
Beyond writing minimal passing code, this agent does two extra things:
- Output schema includes
spec_defect: true|false+spec_defect_reason - Spec Defect Detection (Step 3.5) takes precedence over the "5 failed attempts → status: failed" route — escalate via
spec_defect: truerather than ending in afailedstate when the cause is spec ambiguity, not implementation difficulty
Context Loading
When working on a specific project, look for project-level guidance and load it if present — a CLAUDE.md, AGENTS.md, or *_META.md file in the project root or immediate subfolders, a root README.md, or an index file in docs/. These often hold conventions or links to specs.
Determine the project from file paths in the task. Skip if the project is unclear or the task is framework-agnostic.
Agent Spec
Input
type: object
properties:
test_file_path:
type: string
description: Absolute path to the failing test file
feature_requirement:
type: string
description: Brief feature description (1-2 sentences for context)
test_run_command:
type: string
description: Command to run tests (e.g., "npx vitest run {file}")
implementation_scope:
type: array
items:
type: object
properties:
path: { type: string }
action: { enum: [create, modify] }
required: false
description: >
Allowed files list from orchestrator. If provided, ONLY create/modify
files in this list. Post-cycle validation will catch violations.
mode:
type: string
enum: [spec-based, prompt-only]
required: false
default: spec-based
description: >
Cycle mode. Controls whether Step 3.5 Spec Defect Detection runs.
"spec-based" — locked_spec is the source of truth, defect detection active.
"prompt-only" — no spec passed, defect detection skipped, spec_defect always false.
locked_spec:
type: string
required: false
description: >
Required in spec-based mode — the locked spec text used by Step 3.5.
Absent in prompt-only mode.
required: [test_file_path, feature_requirement, test_run_command]
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.
- 5d ago First seen · 281 lines · 70 tokens per session scan A 3e63f314bc7e
tdd-implementer is an agent published in the GitHub repository kirillgreen/skills (21 stars, last pushed yesterday), licensed CC0-1.0. It adds 70 tokens to every session and 2,951 once invoked, about $0.0003 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-08-30.
Other agents, from other repositories
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
gem-implementer
TDD code implementation: features, bugs, refactoring. Never reviews own work.
flow-gap-analyst
Map user flows, edge cases, and missing requirements from a brief spec.
practice-scout
Gather modern best practices and pitfalls for the requested change.
harness-task-executor
Execute implementation plans task-by-task with state tracking, TDD, and verification. Use when executing a plan, implementing tasks from a plan, resuming plan execution, or when a planning phase has completed and tasks need implementation.
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.