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 skills/mzored/superpowers-cc-to-codex/test-driven-development-codexnpx skills add mzored/superpowers-cc-to-codex --skill test-driven-development-codexgit clone --depth 1 https://github.com/mzored/superpowers-cc-to-codexWrote 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/mzored/superpowers-cc-to-codex/test-driven-development-codex)<a href="https://agentmods.dev/skills/mzored/superpowers-cc-to-codex/test-driven-development-codex"><img src="https://agentmods.dev/badge/skills/mzored/superpowers-cc-to-codex/test-driven-development-codex.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.00035 | $0.01102 |
| Opus 5 | $0.00017 | $0.00551 |
| Sonnet 5 | $0.00007 | $0.00220 |
| Haiku 4.5 | $0.00003 | $0.00110 |
Grade A, and why
test-driven-development-codex 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Keep Claude in the main thread for user interaction and task acceptance.
Call the codex_implement MCP tool with promptTemplate: "tdd" for TDD-disciplined implementation. Use codex_resume for fix loops if TDD discipline is violated.
Reference testing-anti-patterns.md when reviewing Codex output for testing quality.
Overview
Tests written after code prove nothing — passing tests don't confirm they test the right thing.
Core principle: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
Announce at start: "I'm using the test-driven-development skill to implement this with strict red-green-refactor discipline."
The Iron Law
If you didn't watch the test fail, you don't know if it tests the right thing.
If Codex returns implementation without red-green evidence, reject it and resume with TDD enforcement.
When to Use
- Any implementation task where test coverage is critical
- New features, bug fixes, refactors where behavior must be verified
- When the user explicitly requests TDD methodology
Workflow
Step 1: Verify Task Readiness
- Task has clear acceptance criteria
- Test framework is identified (check existing test files)
- Codex CLI is available
If acceptance criteria are unclear, ask the user before dispatching.
Step 2: Call codex_implement with TDD Prompt Template
Call the codex_implement MCP tool with promptTemplate: "tdd":
{
"tool": "codex_implement",
"arguments": {
"taskId": "task-17",
"promptTemplate": "tdd",
"prompt": "Implement the requested behavior with strict red-green-refactor discipline. Write the failing test first, then the minimal production change, then refactor only if the tests still pass.",
"workspaceRoot": "/absolute/path/to/your/repo"
}
}
What ships with it
2 files 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 · 130 lines · 35 tokens per session scan A fbaa4cb56d48
test-driven-development-codex is a skill published in the GitHub repository mzored/superpowers-cc-to-codex (7 stars, last pushed 4mo ago), licensed MIT. It adds 35 tokens to every session and 1,102 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-08-31.
Other skills, from other repositories
linked-intent-dev
Guide for linked-intent development (LID). Consult for ALL code changes. Walks changes through a mode-aware six-phase workflow (HLD → LLD → EARS → intent-narrowing edge audit → tests-first → code) with mandatory stops between each phase. Bugs walk the arrow like any other change — no short-circuit. Enforces cascade…
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
execute
Execute the next available tracked task with TDD, pre-commit validation, PR workflow, AI code review, and issue tracker bridge sync. Primary execution interface for multi-session feature work.
workflows-driven-development
Dynamic build workflow: plans a goal into tasks, builds each test-first, and reviews every step.
tdd
Use before implementation when behavior can be verified by automated tests and regression coverage has clear value. For bugs with an unknown root cause, use systematic-debugging first, then return for red-green. Follow red-green-refactor—write a failing test first, add only enough code to pass it, then refactor. Do…