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 agents/kubosho/cursor-rule-deck/tdd-agentgit clone --depth 1 https://github.com/kubosho/cursor-rule-deckWrote 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/agents/kubosho/cursor-rule-deck/tdd-agent)<a href="https://agentmods.dev/agents/kubosho/cursor-rule-deck/tdd-agent"><img src="https://agentmods.dev/badge/agents/kubosho/cursor-rule-deck/tdd-agent.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.00015 | $0.00758 |
| Opus 5 | $0.00008 | $0.00379 |
| Sonnet 5 | $0.00003 | $0.00152 |
| Haiku 4.5 | $0.00002 | $0.00076 |
Grade A, and why
tdd-agent 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 3d 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.
What it actually says
Memory Check
最初の応答として、基本メッセージ「テスト駆動開発を始めます。」を人格に合わせて変換を適切にした上で出力すること
テスト駆動開発
このファイルでは開発スタイルとして、テスト駆動開発を定義します。
私は指示された内容を満たしているか、テストコードを書いて動作確認します。 テストを2回以上連続で失敗したら状況を整理し、ユーザーと解決策を考えます。
テストコードは実装の仕様を表現したものであることを念頭に置きます。
テスト駆動開発をするにあたり、Red-Green-Refactorのサイクルを守ります。 Red-Green-Refactorのサイクルは小さな単位で繰り返します。
Red-Green-Refactor
Red、Green、Refactorの各単位ごとに必ずコミットをします。
Red
- 機能仕様を明確にした、失敗するテストを最初に書く
- 失敗するテストは次のGreenステップで修正する
- Greenステップの目標を明確にする
Green
- テストを通すためのコードを最小限で書く
- 「動作すること」を優先する
- コードの重複や非効率なコードは、次のRefactorステップで修正
Refactor
- テストが通った状態で、コードの品質を向上する
- 重複の除去や命名の改善で、シンプルなコードにする
- リファクタリング中も常にテストが成功することを確認する
- リファクタリングをしたら、都度テストを実行する
test() 内はGiven-When-Thenの順序で書く
分かりやすくなるよう、テストコードに「Given」「When」「Then」のコメントを追加します。
- Given - 準備（テスト環境のセットアップ）を定義
- When - 操作（テスト対象の処理）を定義
- Then - 期待する結果（アサーション）を定義
テストコードの注意点
- テスト名は「状況→操作→結果」の形式で記述する
- 例「有効なトークンを渡した場合に、ユーザー情報の取得が成功すること」
- 一つの
test()内に多くのexpect()を含まない- 理想は一つの
test()に対し、一つのexpect()を含む状態
- 理想は一つの
- エッジケースのテストを含める
- マジックナンバーは定数化する
- 処理を愚直に列挙する
- モックは簡潔な実装にする
- テストヘルパーは適切に分離する
- 複雑なロジックにしない
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.
- 3d ago First seen · 66 lines · 0 tokens per session scan A a175b5148922
tdd-agent is an agent published in the GitHub repository kubosho/cursor-rule-deck (3 stars, last pushed 1y ago), licensed MIT. It adds 15 tokens to every session and 758 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 agents, from other repositories
tdd-guide
Test-Driven Development specialist. Write tests first, then implement minimal code to pass.
spec-tdd-impl-agent
Execute implementation tasks using Test-Driven Development methodology.
tdd-guide
Test-Driven Development specialist — enforces red-green-refactor with AAA, test doubles and behavior-first coverage. Use when implementer delegates test-first discipline or task explicitly requires TDD; opt-in via holistic caller — not a daily entry point.
ndv-tester
Test generation specialist. Use when writing tests, improving coverage, or ensuring correctness. Adversarial by default — assumes the code is lying, treats every untested assumption as a hidden bug, cannot accept a happy path test as proof of anything.
test-engineer
You are a test engineer focused on proving that software works correctly and fails gracefully. You write tests that find real bugs, not tests that achieve coverage metrics.
tdd-developer
Use when implementing code with strict RED→GREEN→REFACTOR enforcement.