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 Cristhianzl/claude-skills-czl --skill developing-features-tddgit clone --depth 1 https://github.com/Cristhianzl/claude-skills-czlWrote 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/cristhianzl/claude-skills-czl/developing-features-tdd)<a href="https://agentmods.dev/skills/cristhianzl/claude-skills-czl/developing-features-tdd"><img src="https://agentmods.dev/badge/skills/cristhianzl/claude-skills-czl/developing-features-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/cristhianzl/claude-skills-czl/developing-features-tdd"><img src="https://agentmods.dev/badge/skills/cristhianzl/claude-skills-czl/developing-features-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.00106 | $0.03736 |
| Opus 5 | $0.00053 | $0.01868 |
| Sonnet 5 | $0.00021 | $0.00747 |
| Haiku 4.5 | $0.00011 | $0.00374 |
Grade A, and why
developing-features-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 12d 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 — 278 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Developing Features with TDD
Test-driven feature development. Every observable behavior is driven by a failing test that goes RED → GREEN, with architecture planned before the first test is written.
Never write production code for a new feature before proving its expected behavior with a failing test.
Read first (always)
List learnings/ and read every file relevant to the current feature. Project-specific test conventions, framework quirks, or constraints live there and override the defaults in this SKILL.md. If a learning conflicts with this file, the learning wins — mention it to the user.
Tradeoff — when to apply, when to lighten up
Apply the full nine-phase cycle for production features the user explicitly asks to build with TDD, or for code paths where regressions are expensive (payments, auth, data integrity, AI runtime, public APIs).
Lighten the formality for one-off scripts, throwaway exploration, prototypes the user has labeled as such, or features under 30 lines of production code. Still write at least one happy-path test and one adversarial test — but skip the explicit Phase 2 design document.
Best practices — inherited from developing-features (this skill changes only the how)
Every engineering standard in developing-features applies here in full and unchanged. TDD changes how you implement (test-first: RED → GREEN → REFACTOR), not what "good" means — it never relaxes or replaces these:
- The pre-implementation security check, the reuse ladder (existing code → stdlib → platform → installed dep → only then new code), the trade-off priority (correctness → simplicity → testability → performance → reuse), and the core code-quality rules: SOLID, DRY/KISS/YAGNI/Law of Demeter, file-structure hard limits, intention-revealing naming, immutability, no global state, strong typing, guard clauses, complexity ≤ 10 / nesting ≤ 4, and no-WHAT-comments.
- Error handling, security, observability, data layer & scale (pooling, indexes, no-N+1, pagination), and platform-agnostic rules.
- Their full detail lives in
developing-features/references/{security,solid,pragmatic-principles,file-structure,observability,data-layer}.md— read them as needed.
What ships with it
5 files 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.
- 12d ago First seen · 278 lines · 106 tokens per session scan A 019a1a204cf7
developing-features-tdd is a skill published in the GitHub repository Cristhianzl/claude-skills-czl (5 stars, last pushed 2d ago), licensed MIT. It adds 106 tokens to every session and 3,736 once invoked, about $0.0005 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
test-driven-development
Implement a feature or bugfix test-first using the red-green-refactor cycle — write a failing test, watch it fail, write the minimal code to pass, then clean up. Works in any language or test runner. Use when building new behaviour or fixing a bug and you want the test to actually prove the code works.
tdd
A test-driven development workflow, where a test is written and shown to fail before the smallest implementation is added, then the code is improved. TDD is a way to use tests to guide software changes.
agent-evaluation
Use when testing skills, commands, or agents for quality. Use after creating new skills, before deploying agents, or when debugging inconsistent agent behavior. Triggers on "evaluate", "test quality", "is this skill working", or QA of AI workflows.
tdd
Apply when adding new behavior or fixing a bug. Red-green-refactor cycle, test-first discipline, when TDD doesn't pay.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
kotlin-testing
Kotlin testing patterns with Kotest, MockK, coroutine testing, property-based testing, and Kover coverage. Follows TDD methodology with idiomatic Kotlin practices.