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/majiayu000/spellbook/test-driven-developmentnpx skills add majiayu000/spellbook --skill test-driven-developmentgit clone --depth 1 https://github.com/majiayu000/spellbookWrote 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/majiayu000/spellbook/test-driven-development)<a href="https://agentmods.dev/skills/majiayu000/spellbook/test-driven-development"><img src="https://agentmods.dev/badge/skills/majiayu000/spellbook/test-driven-development.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.00040 | $0.00720 |
| Opus 5 | $0.00020 | $0.00360 |
| Sonnet 5 | $0.00008 | $0.00144 |
| Haiku 4.5 | $0.00004 | $0.00072 |
Grade A, and why
test-driven-development 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 yesterday.
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 — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development (TDD)
From obra/superpowers
Core Principle
Write tests before implementation. Watch them fail. Write minimal code to pass.
THE IRON LAW: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
When to Apply TDD
- New features
- Bug fixes
- Refactoring
- Any behavior changes
The Red-Green-Refactor Cycle
RED: Write a Failing Test
- Write ONE minimal test demonstrating desired behavior
- Use clear, descriptive test names
- Use real code, avoid unnecessary mocks
- Test should fail for the RIGHT reason
# Verify RED
- Run the test
- Confirm it fails
- Confirm failure is NOT due to syntax errors
- Confirm you're not testing existing functionality
GREEN: Make It Pass
- Write the SIMPLEST code that makes the test pass
- Don't add extra features
- Don't optimize yet
- Just make it work
# Verify GREEN
- Run all tests
- Confirm new test passes
- Confirm no other tests broke
REFACTOR: Clean Up
- Improve code quality while keeping tests green
- Remove duplication
- Improve naming
- Extract helpers if needed
- Run tests after each change
Why This Order Matters
Tests written AFTER implementation:
- Pass immediately (proves nothing)
- You never see them fail
- Cannot verify they test what matters
- Manual testing is NOT a substitute
Common Rationalizations to REJECT
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code still breaks |
| "I'll write tests after" | Post-implementation tests pass immediately |
| "Already manually tested" | Manual testing lacks systematic rigor |
| "Deleting work is wasteful" | Unverified code is technical debt |
| "Keep as reference" | You'll adapt it; that's testing-after |
Red Flags Requiring RESTART
If any of these occur, DELETE the code and start over:
- Writing code before tests
- Tests passing immediately on first run
- Rationalizing "just this once"
- Planning to "test later"
- Keeping pre-written code "as reference"
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.
- yesterday First seen · 118 lines · 40 tokens per session scan A 407001e8c9a2
test-driven-development is a skill published in the GitHub repository majiayu000/spellbook (265 stars, last pushed today), licensed MIT. It adds 40 tokens to every session and 720 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
Pair Programming
AI-assisted pair programming with multiple modes (driver/navigator/switch), real-time verification, quality monitoring, and comprehensive testing. Supports TDD, debugging, refactoring, and learning sessions. Features automatic role switching, continuous code review, security scanning, and performance optimization with…
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.
cao-session-management
Interact with CAO (CLI Agent Orchestrator) — launch multi-agent sessions, check status, send follow-up instructions, unblock stuck terminals, or shut down sessions. Use when working with CAO sessions in any capacity.
session-share
Share Claude Code sessions between developers. Use when user mentions "share session", "export session", "import session", "send session to", "continue from colleague", or needs to (1) export current session to file, (2) import session from another developer, (3) hand off work context. Enables private, secure session…
workflow
Skill "workflow" from zhinkgit/embeddedskills, covering workflow 编排层, 命令, 配置说明, 配置结构 and 参数解析顺序.
testing-principles
Language-agnostic testing principles including TDD, test quality, coverage standards, and test design patterns. Use when writing tests, designing test strategies, or reviewing test quality.