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/yinqd3/workbuddy-skills/test-driven-developmentnpx skills add yinqd3/workbuddy-skills --skill test-driven-developmentgit clone --depth 1 https://github.com/yinqd3/workbuddy-skillsWrote 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/yinqd3/workbuddy-skills/test-driven-development)<a href="https://agentmods.dev/skills/yinqd3/workbuddy-skills/test-driven-development"><img src="https://agentmods.dev/badge/skills/yinqd3/workbuddy-skills/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.1 | $0.00053 | $0.01281 |
| Opus 5 | $0.00026 | $0.00641 |
| Sonnet 5 | $0.00011 | $0.00256 |
| Haiku 4.5 | $0.00005 | $0.00128 |
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 6d 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 — 180 lines — stays where its author put it; the contents beside it link to each section on GitHub.
测试驱动开发（TDD）
核心原则
先写测试，看它失败，写最少代码让它通过。
如果你没看到测试失败，你就不知道它是否测试了正确的东西。
铁律
没有先看到失败的测试 = 没有生产代码
先写代码再写测试？删掉，重新来。
- 不要保留做"参考"
- 不要在写测试时"改编"它
- 不要看它
- 删除就是删除
何时使用
永远：
- 新功能
- Bug 修复
- 重构
- 行为变更
例外（需要人类伙伴确认）：
- 一次性原型
- 自动生成的代码
- 配置文件
"就这一次跳过 TDD 吧"？停。那是合理化借口。
红-绿-重构循环
RED — 写失败测试
写一个最小测试展示应该发生什么。
好的测试：
def test_retries_failed_operations_three_times():
attempts = 0
def operation():
nonlocal attempts
attempts += 1
if attempts < 3:
raise Exception("fail")
return "success"
result = retry(operation)
assert result == "success"
assert attempts == 3
清晰命名，测试真实行为，只测一件事
差的测试：
def test_retry():
mock = Mock(side_effect=[Exception, Exception, "success"])
retry(mock)
assert mock.call_count == 3
模糊命名，测 mock 不是测代码
要求：
- 一个行为一个测试
- 清晰的描述性名称
- 测试真实代码（非必要不用 mock）
验证 RED — 看它失败
强制步骤，不可跳过。
pytest tests/path/test.py::test_name -v
确认：
- 测试失败（不是报错）
- 失败信息符合预期
- 失败原因 = 功能缺失，不是拼写错误
测试直接通过？ 你在测已有行为，修正测试。
GREEN — 最少代码
写最简单的代码让测试通过。不要：
- 加测试不需要的选项
- 重构其他代码
- "改进"超过测试要求的范围
验证 GREEN — 看它通过
强制步骤。
pytest tests/path/test.py::test_name -v
确认：
- 目标测试通过
- 所有其他测试仍然通过
- 输出干净（无错误、无警告）
REFACTOR — 清理
只在绿色之后：
- 消除重复
- 改进命名
- 提取辅助函数
保持测试绿色，不要添加行为。
重复
下一个失败测试 → 下一个功能。
好测试的标准
| 品质 | 好的 | 差的 |
|---|---|---|
| 最小 | 一件事。名字里有"和"？拆开。 | test_validates_email_and_domain() |
| 清晰 | 名字描述行为 | test1、test_works |
| 展示意图 | 展示期望的 API | 隐藏代码应该做什么 |
为什么顺序重要
"我先写代码再补测试来验证"
事后写的测试立刻通过。立刻通过什么也证明不了：
- 可能测了错的东西
- 可能测了实现而非行为
- 可能漏了边界情况
- 你从来没见过它抓到 bug
常见借口粉碎
| 借口 | 现实 |
|---|---|
| "太简单不用测" | 简单代码也会坏。写测试只花 30 秒。 |
| "我稍后补测试" | 测试立即通过证明不了任何事。 |
| "我已经手动测过了" | 临时的 ≠ 系统性的。没有记录，无法重跑。 |
| "删掉 X 小时工作太浪费" | 沉没成本谬误。保留未验证代码 = 技术债。 |
| "TDD 太死板，实际点" | TDD 就是实际的：提交前找到 bug（比事后调试快）。 |
| "保留做参考，先写测试" | 你会改编它。那就是测试后补。删除就是删除。 |
红灯 — 停，重来
以下任何情况出现，意味着跳过 TDD：
- 测试之前写了代码
- 代码后补的测试
- 测试立即通过
- 解释不了测试为什么失败
- "我稍后加测试"
- 合理化"就这一次"
- "我已经手动测过了"
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.
- 6d ago First seen · 180 lines · 53 tokens per session scan A c5aca467879b
test-driven-development is a skill published in the GitHub repository yinqd3/workbuddy-skills (6 stars, last pushed 3mo ago), licensed MIT. It adds 53 tokens to every session and 1,281 once invoked, about $0.0003 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
Use when implementing any feature or bugfix, before writing implementation code.
results-report
This skill should be used when the user asks to "write an experiment report", "summarize experimental results", "do experiment retrospection", "write a results report", "写实验总结报告", "写实验复盘", or mentions turning completed experiment artifacts into a structured, decision-oriented research report. It assumes strict…
testing-agents-with-subagents
Test agents via subagents: known inputs, captured outputs, verification.
tdd
TDD with red-green-refactor loop and vertical slices. Triggers: TDD, test-first, red-green-refactor, test driving development.
triage-issue
Bug triage: explores codebase for root cause, files GitHub issue with TDD fix plan. Triggers: triage, investigate bug, fix plan, root cause, file issue, bug report.
test-driven-development
RED-GREEN-REFACTOR cycle with strict phase gates for TDD.