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/opagani/cassini-workshop/tddnpx skills add opagani/cassini-workshop --skill tddgit clone --depth 1 https://github.com/opagani/cassini-workshopWrote 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/opagani/cassini-workshop/tdd)<a href="https://agentmods.dev/skills/opagani/cassini-workshop/tdd"><img src="https://agentmods.dev/badge/skills/opagani/cassini-workshop/tdd.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.1 | $0.00145 | $0.01349 |
| Opus 5 | $0.00072 | $0.00674 |
| Sonnet 5 | $0.00029 | $0.00270 |
| Haiku 4.5 | $0.00015 | $0.00135 |
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 5d 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.
This is a copy
100% identical to tdd — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development — Clear Tests, Written First
Under this skill the test is written before the implementation and is the spec the builder works from. A human (or a builder agent) should be able to read the test file top to bottom and understand exactly what the code is supposed to do — without opening the source. If a test isn't clear on its own, it isn't done.
Do not write implementation code under this skill until the tests exist, fail for the right reason, and the user has seen them.
🎯 Why clarity is the whole point
These tests are a guide handed to a builder agent. The builder implements against them with no other context, so every test must answer three questions by itself:
- What behavior is being built (the test name).
- With what inputs (the Arrange block).
- What counts as correct (one assertion).
A clever, terse, or DRY-but-cryptic test fails as a guide even if it passes as a check. Optimize for the next reader, not for line count.
The cycle
Run it in order, one behavior at a time:
- Red — write one failing test for the next behavior. Run
bun testand confirm it fails because the behavior is missing, not because of a typo, bad import, or compile error. A test that errors out is not a red test. - Green — (builder's job, or yours if implementing) write the minimum code to pass.
- Refactor — clean up with the test as the safety net. The test does not change during refactor; if it has to, you changed behavior, not structure.
Write the smallest next test that forces new code. Don't write ten tests against code that doesn't exist — write one, watch it fail, then move on. The suite grows behavior by behavior.
bun:test — the runner, always
This project uses Bun. Import from "bun:test", run with bun test. Do not
auto-detect or ask.
import { test, expect } from "bun:test";
Use describe only to group tests around one subject — keep nesting shallow
(one level). Prefer flat, fully-named test(...) calls over deep describe
trees; the name carries the meaning. Use beforeEach for shared Arrange only
when several tests need the identical setup.
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.
- 5d ago First seen · 119 lines · 145 tokens per session scan A e5fd5e7943a2
tdd is a skill published in the GitHub repository opagani/cassini-workshop (0 stars, last pushed 2mo ago), licensed MIT. It adds 145 tokens to every session and 1,349 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to tdd, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
bdd-specs
Behavior-driven design: write executable specifications BEFORE any implementation code. Reads /docs/PLAN.md for the build plan and /docs/STORIES.md for user stories, and stops to ask for either if it is missing. Generates TypeScript spec files in nested blocks — Feature > Scenario > Specification — where each Scenario…
tdd
Test-driven development with bun:test, written for clarity. Produces failing tests FIRST — before any implementation — that read as the executable spec a builder agent implements against. Each test names a single behavior in plain language, follows Arrange–Act–Assert, asserts one thing, and uses real types with no…
misakanet-failure-memory
Search and record failure-recovery lessons from real engineering sessions; submit and verify debugging lessons across the MisakaNet network.
add-provider
Add a new storage or service provider to the core package. Use when implementing a new backend for StorageService (e.g., a new database) or a new service provider (e.g., a new LLM backend).
add-export
Add a new subpath export to the @cyanheads/mcp-ts-core package. Use when creating a new public API surface that consumers import from a dedicated subpath (e.g., @cyanheads/mcp-ts-core/newutil).
hono-cloudflare
Hono on Cloudflare Workers - bindings, KV, D1, R2, Durable Objects, and edge deployment patterns.