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/rtk-ai/rtk/rtk-tddnpx skills add rtk-ai/rtk --skill rtk-tddgit clone --depth 1 https://github.com/rtk-ai/rtkWrote 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/rtk-ai/rtk/rtk-tdd)<a href="https://agentmods.dev/skills/rtk-ai/rtk/rtk-tdd"><img src="https://agentmods.dev/badge/skills/rtk-ai/rtk/rtk-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 | $0.00061 | $0.00783 |
| Opus 5 | $0.00030 | $0.00392 |
| Sonnet 5 | $0.00012 | $0.00157 |
| Haiku 4.5 | $0.00006 | $0.00078 |
Grade A, and why
rtk-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 4d 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Rust TDD Workflow
Three Laws of TDD
- Do NOT write production code without a failing test
- Write only enough test to fail (including compilation failure)
- Write only enough production code to pass the failing test
Cycle: RED (test fails) -> GREEN (minimum to pass) -> REFACTOR (cleanup, cargo test)
Red-Green-Refactor Steps
1. Write test in #[cfg(test)] mod tests of the SAME file
2. cargo test MODULE::tests::test_name -- must FAIL (red)
3. Implement the minimum in the function
4. cargo test MODULE::tests::test_name -- must PASS (green)
5. Refactor if needed, re-run cargo test (still green)
6. cargo fmt && cargo clippy --all-targets && cargo test (final gate)
Never skip step 2. If the test passes immediately, it tests nothing.
Idiomatic Rust Test Patterns
| Pattern | Usage | When |
|---|---|---|
| Arrange-Act-Assert | Base structure for every test | Always |
assert_eq! / assert! |
Direct comparison / booleans | Deterministic values |
assert!(result.is_err()) |
Error path testing | Invalid inputs |
Result<()> return type |
Tests with ? operator |
Fallible functions |
#[should_panic] |
Expected panic | Invariants, preconditions |
tempfile::NamedTempFile |
File/I/O tests | Filesystem-dependent code |
Patterns by Code Type
| Code Type | Test Pattern | Example |
|---|---|---|
| Pure function (str -> str) | Input literal -> assert output | assert_eq!(truncate("hello", 3), "...") |
| Parsing/filtering | Raw string -> filter -> contains/not-contains | assert!(filter(raw).contains("expected")) |
| Validation/security | Boundary inputs -> assert bool | assert!(!is_valid("../etc/passwd")) |
| Error handling | Bad input -> is_err() |
assert!(parse("garbage").is_err()) |
| Struct/enum roundtrip | Construct -> serialize -> deserialize -> eq | assert_eq!(from_str(to_str(x)), x) |
Naming Convention
test_{function}_{scenario}
test_{function}_{input_type}
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.
- 4d ago First seen · 86 lines · 61 tokens per session scan A 82b156358322
rtk-tdd is a skill published in the GitHub repository rtk-ai/rtk (78,131 stars, last pushed 2d ago), licensed Apache-2.0. It adds 61 tokens to every session and 783 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-30.
Other skills, from other repositories
rtk-tdd
Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
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.
hns-moaiadk-patterns
Skill "hns-moaiadk-patterns" from modu-ai/moai-adk, covering moai-adk-go domain patterns, architecture quick reference, key source paths, pipeline specialist delegation map and template-first build cycle.
hns-oss-docs-i18n-rules
HARD i18n rules digest for the oss-docs harness specialists working on moai-adk-go README 4-locale set and the docs-site (adk.mo.ai.kr). Covers the canonical-locale chains, the 4-locale same-PR obligation, Mermaid TD-only, the no-emoji + icon-shortcode rule, emphasis-marker spacing, the URL blacklist, version SSOT…
verify
Self-healing verification loop (test → clippy → fmt).
linked-intent-dev
Guide for linked-intent development (LID). Consult for ALL code changes. Walks changes through a mode-aware six-phase workflow (HLD → LLD → EARS → intent-narrowing edge audit → tests-first → code) with mandatory stops between each phase. Bugs walk the arrow like any other change — no short-circuit. Enforces cascade…