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 helmedeiros/clean-code-skills --skill tdd-red-green-refactorgit clone --depth 1 https://github.com/helmedeiros/clean-code-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/skills/helmedeiros/clean-code-skills/tdd-red-green-refactor)<a href="https://agentmods.dev/skills/helmedeiros/clean-code-skills/tdd-red-green-refactor"><img src="https://agentmods.dev/badge/skills/helmedeiros/clean-code-skills/tdd-red-green-refactor/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/skills/helmedeiros/clean-code-skills/tdd-red-green-refactor"><img src="https://agentmods.dev/badge/skills/helmedeiros/clean-code-skills/tdd-red-green-refactor.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.00050 | $0.00733 |
| Opus 5 | $0.00025 | $0.00367 |
| Sonnet 5 | $0.00010 | $0.00147 |
| Haiku 4.5 | $0.00005 | $0.00073 |
Grade A, and why
tdd-red-green-refactor 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 10d 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 — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD: Red-Green-Refactor Cycle
Guide the development process through the disciplined red-green-refactor cycle to produce well-tested, well-designed code in small, confident increments.
When This Skill Applies
- Starting a new feature or behavior from scratch
- The user mentions TDD, red-green-refactor, or test-driven development
- Building production code incrementally with automated tests
- The user wants to ensure every line of code is justified by a failing test
Core Principle
Write a failing test first (Red), make it pass with the simplest possible implementation (Green), then improve the design without changing behavior (Refactor). Each cycle should take minutes, not hours. Never skip a phase — the discipline of the cycle is what produces both correctness and clean design.
Workflow
Step 1: Red — Write a Failing Test
Write a single, focused test that describes the next small increment of desired behavior. Run the test suite and confirm it fails for the expected reason. The failure message should clearly indicate what is missing.
Step 2: Green — Make It Pass
Write the minimum amount of production code to make the failing test pass. Resist the urge to write more than necessary. Hard-code values if that is the simplest path. The goal is a green test suite, not elegant code.
Step 3: Refactor — Improve the Design
With all tests green, improve the code's structure. Remove duplication, extract methods, rename for clarity, simplify conditionals. Run tests after every change to confirm behavior is preserved. Stop when the code clearly expresses its intent.
Step 4: Repeat
Pick the next small behavior increment and return to Step 1. Let the tests drive the design forward one assertion at a time.
Detection / Indicators
- Production code written before any test exists
- Large batches of code written between test runs
- Tests that pass on the first run (they were not written first)
- Refactoring skipped because "it works"
- Tests that test implementation details instead of behavior
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.
- 10d ago First seen · 63 lines · 50 tokens per session scan A ed8b6df837ae
tdd-red-green-refactor is a skill published in the GitHub repository helmedeiros/clean-code-skills (2 stars, last pushed 6mo ago), licensed MIT. It adds 50 tokens to every session and 733 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-31.
Other skills, from other repositories
maven
Always load this skill when a pom.xml file exists in the project, when creating or editing a pom.xml, or when setting up Maven project structure in a new project. It provides Maven-specific conventions for running tests, building, managing dependencies, and project structure.
nested-fixture-pattern
This skill should be used when working on Java projects with JUnit tests that have layered preconditions, expensive shared setup (servers, databases, provisioned users), or complex scenario trees. Trigger phrases include "nested fixture", "fixture pattern", "scenario tree", "layered test setup", or when the user is…
app
This skill should be used when the user asks to "calculate code mass", "measure code complexity with APP", "compare implementations using APP", "apply Absolute Priority Premise", "use mass calculations", or during TDD refactor phases when comparing alternative implementations. Based on Micah Martin's work.
clean-code
This skill should be used when the user asks to "refactor code", "review code quality", "apply clean code principles", "check for code smells", "improve code design", "do a clean code review", "apply SOLID principles", "fix naming", "reduce complexity", or when performing the refactor phase of a TDD cycle.
tdd
This skill should be used when the user asks to "add a feature using TDD", "fix a bug with TDD", "do TDD", "red-green-refactor", "write a failing test first", "use test-driven development", "start TDD", "test first approach", "TDD loop", "TDD cycle", or mentions TDD workflow, baby steps, guessing game, or…
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first.