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 chipfighter/coding-discipline --skill tddgit clone --depth 1 https://github.com/chipfighter/coding-disciplineWrote 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/chipfighter/coding-discipline/tdd)<a href="https://agentmods.dev/skills/chipfighter/coding-discipline/tdd"><img src="https://agentmods.dev/badge/skills/chipfighter/coding-discipline/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/chipfighter/coding-discipline/tdd"><img src="https://agentmods.dev/badge/skills/chipfighter/coding-discipline/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.00085 | $0.00828 |
| Opus 5.5 | $0.00034 | $0.00331 |
| Sonnet 5.5 | $0.00017 | $0.00166 |
| Haiku 4.5 | $0.00009 | $0.00083 |
Grade A, and why
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 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.
How it starts
The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Hard rule: write no implementation code without a test that failed first. Did you just write the implementation in this turn without delivering it? Remove it and restart from the test—do not keep it as a "reference" or look at it while adding tests. But never delete the user's existing code or someone else's workspace changes: when working with an existing implementation, add tests that record and protect its current behavior before making the smallest change.
Excuses to stop as soon as they appear
| What you tell yourself | Reality |
|---|---|
| "Write the implementation first and add tests later." | Tests written afterward to match the implementation only prove that "the code does what it does," not that it is correct. |
| "Keep this as a reference; do not really remove it." | The time is already spent; it is a sunk cost. If you keep it, you will shape the tests around it. Remove it (only if you wrote it this turn; never delete the user's existing code). |
| "It is too simple to be worth testing." | "Simple" means an assumption you have not stated, which is exactly where failures happen. |
Red → Green → Refactor
- Red: write the smallest failing test for one behavior. Give it a name that says what it tests, and test real code rather than mocks (use mocks only when unavoidable).
- Verify red (you must run it): watch it fail, specifically because the behavior is not implemented yet—not because of a typo, bad import, or syntax error.
- It passes immediately = you are testing behavior that already exists. The test has no value; rewrite it.
- The program errors instead of failing an assertion = fix the error and rerun until it "fails correctly."
- Green: write the minimum code needed to make it pass. Do not slip in features that are not needed yet or change anything else.
- Verify green (you must run it): the test passes, every other test still passes, and the output is clean (no errors or warnings). If it fails, change the code, not the test.
- Refactor: only after everything is green—remove duplication, improve names, extract functions. Keep the suite green throughout and add no new behavior.
- For the next behavior, return to red.
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 First seen · 40 lines · 85 tokens per session scan A 61b6b0727f0f
tdd is a skill published in the GitHub repository chipfighter/coding-discipline (25 stars, last pushed 1mo ago), licensed MIT. It adds 85 tokens to every session and 828 once invoked, about $0.0003 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-31.
Other skills, from other repositories
ccc-e2e
Pre-release assessment that fans out via $ccc-fleet into up to three isolated workers (QA audit, unit tests, Playwright E2E) running $ccc-testing lanes, then writes a severity-ranked PASS or FAIL verdict. Use when about to tag a release, after a large merge, or asking is this ready.
ccc-testing
Testing domain router: picks the lane for TDD, E2E, visual regression, load testing, QA, regression checks, evals or verification and runs test-writing work in an isolated worktree. Use when the user asks to write tests, plan a test strategy, or test, verify or load-test a change.
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.
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…
plan-pipeline-execute
Execute a validated plan: worktree isolation, TDD scaffolding, level-based parallel agents, quality gate with smoke test, PR creation and merge. Handles everything through to merged PR.
agent-test-generator
Specialist subagent: Generates comprehensive test suites using TDD patterns. Use only when the user explicitly asks for tests, improved coverage, or test-first development.