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 PerryLink/dsh-doublecheck --skill red-green-tddgit clone --depth 1 https://github.com/PerryLink/dsh-doublecheckWrote 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/perrylink/dsh-doublecheck/red-green-tdd)<a href="https://agentmods.dev/skills/perrylink/dsh-doublecheck/red-green-tdd"><img src="https://agentmods.dev/badge/skills/perrylink/dsh-doublecheck/red-green-tdd/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/perrylink/dsh-doublecheck/red-green-tdd"><img src="https://agentmods.dev/badge/skills/perrylink/dsh-doublecheck/red-green-tdd.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.00062 | $0.00574 |
| Opus 5 | $0.00031 | $0.00287 |
| Sonnet 5 | $0.00012 | $0.00115 |
| Haiku 4.5 | $0.00006 | $0.00057 |
Grade A, and why
red-green-tdd 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 9d 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 — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
red-green-tdd: the evidence loop
You are an engineering discipline skill from dsh-doublecheck. Your job is to
make implementation changes carry test evidence: every implementation edit is
preceded by a failing test on record and followed by a passing run.
Double-check before you ship: grill the requirements, test the
implementation, prove the delivery. This skill owns the second verb — test.
When to apply this skill
Use this skill when the task is a software-engineering task and a
doublecheck_spec is already on record (call doublecheck_spec first if it
is not), and you are about to change implementation code.
If the task is documentation-only, a config tweak with no behavior change, or the user explicitly waived tests for this change, record that decision and skip the red step instead of pretending a test exists.
The red step
Before editing implementation code:
- Decide which observable behavior is missing or wrong, per the spec's acceptance criteria.
- Write the smallest test that fails for exactly that behavior. Test files are always editable — writing them is how this step happens.
- Run the test command and confirm it fails (
[exit code: 1]or a failing count in the output). A run that fails for the wrong reason (syntax error, missing fixture) is not red evidence; fix the test until it fails for the missing behavior.
If the change cannot be tested cheaply (external service, timing, rendering), state what you will use as evidence instead, and record it before editing.
The green step
- Make the smallest implementation change that satisfies the failing test.
- Run the test command again and confirm it passes (
[exit code: 0]). - Run the surrounding suite when it is cheap, so the change is proven not to have broken its neighbors.
A passing run only counts as green evidence when its output actually shows tests running and passing — an empty run proves nothing.
What you never do
- Never edit implementation code while no failing test is on record for the change.
- Never claim a test passed without a real run whose output shows the pass.
- Never count a test run that failed to execute (missing dependency, sandbox denial, timeout) as either red or green evidence — rerun it.
- Never delete or weaken a test just to get a green run.
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.
- 9d ago First seen · 58 lines · 62 tokens per session scan A fb3148805da4
red-green-tdd is a skill published in the GitHub repository PerryLink/dsh-doublecheck (23 stars, last pushed yesterday), licensed Apache-2.0. It adds 62 tokens to every session and 574 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 skills, from other repositories
tdd
A test-driven development workflow, where you write a test for one behavior, make it pass, and then improve the code while keeping the test.
django-tdd
Django testing strategies with pytest-django, TDD methodology, factoryboy, mocking, coverage, and testing Django REST Framework APIs. Use when writing Django or DRF tests with pytest-django, or driving a Django feature test-first.
laravel-tdd
Laravel testing strategies with PHPUnit, Pest, model factories, HTTP tests, Sanctum authentication testing, mocking, and coverage. Use when writing Laravel tests with PHPUnit or Pest, or driving a Laravel feature test-first.
golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices. Use when writing Go tests — table-driven cases, subtests, benchmarks, fuzzing, or coverage.
kotlin-testing
Kotlin testing patterns with Kotest, MockK, coroutine testing, property-based testing, and Kover coverage. Follows TDD methodology with idiomatic Kotlin practices. Use when writing Kotlin tests with Kotest or MockK, or testing coroutines and checking coverage.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.