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/duthaho/claudekit/test-firstnpx skills add duthaho/claudekit --skill test-firstgit clone --depth 1 https://github.com/duthaho/claudekitWrote 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/duthaho/claudekit/test-first)<a href="https://agentmods.dev/skills/duthaho/claudekit/test-first"><img src="https://agentmods.dev/badge/skills/duthaho/claudekit/test-first.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.00106 | $0.02457 |
| Opus 5 | $0.00053 | $0.01229 |
| Sonnet 5 | $0.00021 | $0.00491 |
| Haiku 4.5 | $0.00011 | $0.00246 |
Grade A, and why
test-first 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 5d 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 — 182 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test First
Overview
Red-green-refactor TDD with strict evidence requirements. The skill exists because the most common testing failure isn't missing tests — it's tests written after the code, designed to pass against the implementation rather than to specify it. Test-first inverts the order: a failing test asserts the desired behavior, the smallest implementation makes it pass, and refactoring runs with the test as a safety net. Each step produces test runner output that goes into the PR. The skill is for engineers shipping production code — not a TDD evangelism doc.
When to Use
- Implementing a new feature with a testable surface (function, endpoint, CLI command, UI behavior with a test harness)
- Fixing a bug — the regression test is the test you write first
- Refactoring code that has incomplete test coverage; tests come before the refactor
- Onboarding to legacy code where you need to characterize behavior before changing it
When NOT to Use
- Pure UX/visual work with no behavioral assertion (use visual review instead)
- Exploratory spike work where the goal is learning, not shipping (mark spike branches and write tests when promoting to mainline)
- Writing a one-off script that runs once and is discarded
Process
Step 1: Pick the smallest testable behavior
Goal: Identify one observable behavior to assert, smaller than the task.
Inputs: A task from your plan with an Acceptance: line.
Actions:
- Read the acceptance criterion. Extract one specific input/output pair you could write as a test.
- If the criterion is too broad ("handles user signup correctly"), narrow it to one case: "user signup with a duplicate email returns 409."
- Name the test in a sentence form:
it <verb>s <subject> when <condition>.
Output: A test name and a one-line description of the input/output pair.
Step 2: Write the failing test (RED)
Goal: A test that currently fails for the right reason.
Inputs: The test name from Step 1.
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.
- 5d ago First seen · 182 lines · 106 tokens per session scan A 4e0c6c0ef698
test-first is a skill published in the GitHub repository duthaho/claudekit (97 stars, last pushed 1mo ago), licensed MIT. It adds 106 tokens to every session and 2,457 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-30.
Other skills, from other repositories
implement
TDD implementation (RED→GREEN→REFACTOR) → verify → review.
plan-pipeline-execute
Execute a validated plan: worktree isolation, TDD scaffolding, level-based parallel agents, quality gate with smoke test, PR creation and merge. Handles everything through to merged PR.
tdd-workflow
Enforce practical Test-Driven Development for code changes in Go services. Use for new features, bug fixes, refactors, API changes, and new modules. Requires Red-Green-Refactor evidence, defect-hypothesis-driven tests, killer cases, and coverage gates (line + risk-path).
tdd
Workflow Phase 6 — TDD coordinator. Decides the scenario recipe and the implementation contract in main context, writes them to a state file, seeds per-worker tasks (scenario, implement, verify-tick, design-ui-tick) into the TaskList, and yields with harnessstate continue so the harness invokes each worker as its own…
implement
Write the production code that makes a pre-decided set of failing tests pass, within an explicit writeset, following an explicit behavior contract. Used by /tdd Step 3 and by /swarm-dispatch workers. The caller has already decided architecture, naming, file layout, and abstraction boundaries — this skill executes that…
scenario
Write executable failing tests from a recipe handed to you by the main context. Used by /tdd Step 2 and ad-hoc when a phase needs tests-first to drive implementation. Decisions about which scenarios to cover, which categories matter, and which fixtures to use are made by the caller — this skill executes that recipe…