addyosmani/agent-skills is a collection of reusable workflows, quality checks, commands, and other instructions that guide AI coding agents through software development. It is for developers who want agents to follow consistent engineering practices, and the catalogue entries are its packaged skills, commands, agents, plugins, instructions, and hooks.
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 skills add addyosmani/agent-skills --skill test-driven-developmentgit clone --depth 1 https://github.com/addyosmani/agent-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/addyosmani/agent-skills/test-driven-development)<a href="https://agentmods.dev/skills/addyosmani/agent-skills/test-driven-development"><img src="https://agentmods.dev/badge/skills/addyosmani/agent-skills/test-driven-development/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/addyosmani/agent-skills/test-driven-development"><img src="https://agentmods.dev/badge/skills/addyosmani/agent-skills/test-driven-development.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 378 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00092 | $0.03763 |
| Opus 5.5 | $0.00037 | $0.01505 |
| Sonnet 5.5 | $0.00018 | $0.00753 |
| Haiku 4.5 | $0.00009 | $0.00376 |
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 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.
Copies of this mod
8 near-identical copies found in the catalogue:
- test-driven-development — 100% identical, 4 lines differ
- test-driven-development — 98% identical, 9 lines differ
- test-driven-development — 98% identical, 1 lines differ
- test-driven-development — 97% identical, 0 lines differ
- addyosmani-tdd — 88% identical, 28 lines differ
- test-driven-development — 88% identical, 72 lines differ
- test-driven-development — 86% identical, 32 lines differ
- test-driven-development — 84% identical, 21 lines differ
How it starts
The opening of the file, as written. The whole thing — 399 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Overview
Write a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof — "seems right" is not done. A codebase with good tests is an AI agent's superpower; a codebase without tests is a liability.
When to Use
- Implementing any new logic or behavior
- Fixing any bug (the Prove-It Pattern)
- Modifying existing functionality
- Adding edge case handling
- Any change that could break existing behavior
When NOT to use: Pure configuration changes, documentation updates, or static content changes that have no behavioral impact.
Related: For browser-based changes, combine TDD with runtime verification using Chrome DevTools MCP — see the Browser Testing section below.
Discover the Stack First
The TDD cycle is universal; the commands are not. Before writing the first test, discover how this repository tests, and use its commands for every RED, GREEN, and verification step:
- Language and build system —
package.json,pom.xml/build.gradle,pyproject.toml,go.mod,Cargo.toml,Gemfile, aMakefile - Checked-in wrappers — prefer
./gradlew,./mvnw,make test, or a repo script over globally installed tools - Test framework and configuration — and how it runs a single focused test vs the full suite
- Existing conventions — where tests live, how files are named, what patterns neighboring tests follow
- Documented commands — README, CONTRIBUTING, and CI workflows show the commands that actually gate merges
Run the repository's focused-test command during the loop and its full-suite command before completion. Never assume a default like npm test — a Gradle, Cargo, or pytest project has its own equivalent.
The examples below use TypeScript for illustration; the workflow is identical in any language once you've discovered the project's own tooling.
The TDD Cycle
RED GREEN REFACTOR
Write a test Write minimal code Clean up the
that fails ──→ to make it pass ──→ implementation ──→ (repeat)
│ │ │
▼ ▼ ▼
Test FAILS Test PASSES Tests still PASS
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 Changed · +35 tokens per session a3aa6ba95638
- 1mo ago Changed · +7 tokens per session 7c0c6ac057c1
- 1mo ago First seen · 399 lines · 50 tokens per session scan A 440fb3c9b76f
test-driven-development is a skill published in the GitHub repository addyosmani/agent-skills (108,203 stars, last pushed 6d ago), licensed MIT. It adds 92 tokens to every session and 3,763 once invoked, about $0.0004 per session on Opus 5.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
constraint-driven-development
A development method for writing a project's quality standards as a lasting, checkable contract. It can cover areas such as test coverage, security, performance, accessibility, and architecture.
test-driven-development
Instructions for test-driven development, or TDD: writing a failing test first, then the smallest code that makes it pass, followed by cleanup.
tdd
Test-driven development, from unit to end-to-end tests. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration or end-to-end tests (Playwright, Cypress). Don't use to backfill tests on existing code (/refactor) or diagnose an unknown bug (/debug).
test-driven-development
Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.
test-driven-development
Drives development with tests via Red-Green-Refactor and the Prove-It pattern, with hard rules against weakening assertions or faking green suites. Use when implementing any logic, fixing any bug, or changing any behavior. Triggers on "add a feature", "fix this bug", "write tests", or any task where done must be…
spec-driven-development
Creates specs before coding, with hard rules against silently filled assumptions and untestable success criteria. Use when starting a new project, feature, or significant change and no specification exists yet. Triggers on "build me", "create a", "add a feature", or any requirement vague enough to need interpretation.