OpenRig is a software harness that coordinates Claude Code and Codex coding agents as one system, with agent teams defined in YAML and launched together. It is for organizing persistent teams of coding agents that can delegate work to specialists and return results or decisions. The catalogue lists 53 skills and one plugin as add-ons for OpenRig.
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 mvschwarz/openrig --skill test-driven-developmentgit clone --depth 1 https://github.com/mvschwarz/openrigWrote 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/mvschwarz/openrig/test-driven-development)<a href="https://agentmods.dev/skills/mvschwarz/openrig/test-driven-development"><img src="https://agentmods.dev/badge/skills/mvschwarz/openrig/test-driven-development/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/mvschwarz/openrig/test-driven-development"><img src="https://agentmods.dev/badge/skills/mvschwarz/openrig/test-driven-development.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.00017 | $0.02846 |
| Opus 5.5 | $0.00007 | $0.01138 |
| Sonnet 5.5 | $0.00003 | $0.00569 |
| Haiku 4.5 | $0.00002 | $0.00285 |
Grade A, and why
test-driven-development 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 1mo 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.
Copies of this mod
8 near-identical copies found in the catalogue:
- ferrox-test-driven-development — 91% identical, 103 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
- test-driven-development — 91% identical, 99 lines differ
How it starts
The opening of the file, as written. The whole thing — 391 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
A strong default in service of shipping — not a law that outranks it. TDD earns its keep where a failing test pins down behavior you'd otherwise get wrong: core logic, contracts, tricky edge cases. Match it to stakes — reach for it where test-first genuinely de-risks the change; throwaway prototypes, one-line copy tweaks, and obvious glue don't need the ceremony. Don't dodge it with synonyms; equally, don't let it block you from shipping the working thing.
When to Use
Use test-first for selected behavior where regression risk warrants it:
- New features
- Bug fixes
- Refactoring
- Behavior changes
Choose proportionate verification for work such as:
- Throwaway prototypes
- Generated code
- Configuration files
Resolve the task's selected project/mission/slice procedure first. A required TDD step remains required within that scope; changing it needs the authority named by that selection. Outside it, choose verification that can detect the failure without adding a human approval ritual. The procedure below describes TDD when selected, not a completion gate for every kind of work.
Chunk size follows the outcome. Keep red → green → refactor for the behavior being changed and build a coherent chunk. TDD does not require two people, pre-edit permission or a guard: independence and review cadence come from the project/mission/slice component or wave selection. An explicitly selected gate still applies; an unselected role cannot add one.
Test-First Contract for Selected Behavior
Selected TDD behavior: observe the expected failure before implementing the fix.
Already wrote the implementation? Preserve existing and others' bytes. Establish the failing baseline in an isolated copy or by reversibly setting aside only your owned change, then implement from the behavioral test. This skill grants no authority to delete code. If a failing baseline cannot be demonstrated, record that limit and follow the selected procedure; do not call tests-after TDD.
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.
- 1mo ago Changed · +7 lines 51f65d2bc71d
- 1mo ago Changed · -2 lines a8ad3479224a
- 1mo ago First seen · 386 lines · 17 tokens per session scan A 14974a332763
test-driven-development is a skill published in the GitHub repository mvschwarz/openrig (7,545 stars, last pushed yesterday), licensed Apache-2.0. It adds 17 tokens to every session and 2,846 once invoked, about $0.0001 per session on Opus 5.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 skills, from other repositories
implement
Use when an approved plan and task list exist and it is time to turn them into working, tested code — the SDD phase after analyze and before verify. Enforces TDD: a failing test comes before the code that makes it pass, one task at a time, appended to a progress ledger that survives compaction. Delegates test tooling…
ap-implementer
Report the compatibility redirect to ap-worker; this retired role cannot perform new work.
gentle-ai
Use Gentle AI harness discipline for Pi work: clarify first, preserve OpenSpec artifacts, use strict TDD where available, delegate through subagents when useful, and protect review workload.
atomic-tdd
Test-first discipline. Auto-triggers on "let's implement X", "add feature Y", "fix bug Z", "write a test for", "implement", "build out", and similar pre-code-change phrases. Iron rule: failing test exists before production code. Skip only for pure docs/config changes with an explicit "skipped because:" note. Explicit…
implement
TDD implementation - make failing tests pass.
test-driven-development
Use when user explicitly requests test-driven development. Triggers: 'TDD', 'write tests first', 'red green refactor', 'test-first', 'start with the test'. Also invoked by develop and executing-plans for implementation tasks. NOT for: full feature work (use develop, which includes TDD internally).