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/acendas/shipyard/tdd-cyclenpx skills add Acendas/shipyard --skill tdd-cyclegit clone --depth 1 https://github.com/Acendas/shipyardWrote 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/acendas/shipyard/tdd-cycle)<a href="https://agentmods.dev/skills/acendas/shipyard/tdd-cycle"><img src="https://agentmods.dev/badge/skills/acendas/shipyard/tdd-cycle.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.00017 | $0.01653 |
| Opus 5 | $0.00009 | $0.00826 |
| Sonnet 5 | $0.00003 | $0.00331 |
| Haiku 4.5 | $0.00002 | $0.00165 |
Grade A, and why
tdd-cycle 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 — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
TDD Cycle
Write the test first. Watch it fail. Write minimum code to pass. Then refactor.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When This Applies
Always:
- Sprint task implementation (
kind: feature) - Bug fix and hotfix work
/ship-quickchanges that touch production code- Refactors that change observable behavior
Hard exceptions (still follow the spirit; check with the user before deviating):
kind: researchtasks — no code commit; output is a findings dockind: operationaltasks — deliverable is captured run output, not new test+code- Throwaway prototypes the user explicitly marked as such
- Generated code (the generator should have its own tests)
- Pure config files
If you find yourself thinking "skip TDD just this once" for any other reason — stop. That is rationalization. Apply the cycle.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
If you wrote code before the test:
- Delete it. Start over from the test.
- Don't keep it as "reference" — subconscious work-backwards from it is hard to avoid.
- Don't "adapt" it while writing the test.
- Don't peek at it.
- Implement fresh from the test you just wrote.
Period.
The Cycle
RED → GREEN → REFACTOR → repeat
RED — Write a failing test
- Read the acceptance scenarios in the task file's
## Acceptance Criteriaand the parent feature's## Technical Notes. The test must exercise at least one scenario. - Write the test. Place it in the correct test file with proper imports and assertions. The assertion should encode the behavior the scenario describes, not the implementation.
- Run the test. Watch it fail.
- Fail must be for the right reason. "ImportError: module not found" or "function not defined" is the expected failure mode for a fresh feature. A pass on the first run means the test isn't testing what you think — fix the test before proceeding.
- Per
ship-execute's wave-boundary policy, test execution defers to the wave boundary (scoped) and sprint completion (full) — but the test still gets written first. The deferred-execution policy never excuses skipping the write-test-before-code discipline. The per-task acceptance probe runs inside the task and is the wiring-proof signal; the deferred suite is the unit-level proof.
- Capture the failure output (the last 10 lines and exit code). You'll paste this into the commit body.
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 · 139 lines · 17 tokens per session scan A a998127bce07
tdd-cycle is a skill published in the GitHub repository Acendas/shipyard (2 stars, last pushed 22d ago), licensed MIT. It adds 17 tokens to every session and 1,653 once invoked, about $0.0001 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
tdd-rust
TDD workflow for RTK filter development. Red-Green-Refactor with Rust idioms. Real fixtures, token savings assertions, snapshot tests with insta. Auto-triggers on new filter implementation.
rtk-tdd
Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
old-coder
Evidence-first development — surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work ("reliable", "TDD", "prove it works", "I won't read the…
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…
tdd-test-engineer
Use for test-first development, regression tests, flaky test debugging, coverage gaps, test strategy, CI failures, or converting bugs into minimal reproducible tests.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Enforces red-green-refactor cycle with strict rules.