test-driven-development

A test-first development workflow, commonly called TDD, where you write a failing test, add the smallest code needed to pass it, and then improve the code.

In plain words
What is it for?
Use it when adding logic, fixing bugs, changing behavior, or handling edge cases.
Why use it?
It helps prove that new behavior or a bug fix is covered before implementation and reduces the risk of breaking existing behavior.

Skill for Claude CodeCodex

Part of the nexus-agents plugin — 33 skills, 16 agents, 1 hook shipped together

Install

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.

agentmods
npx agentmods add skills/nexus-substrate/nexus-agents/test-driven-development
Any agent
npx skills add nexus-substrate/nexus-agents --skill test-driven-development
Clone the repo
git clone --depth 1 https://github.com/nexus-substrate/nexus-agents

Made for: Claude Code, Codex.

Or install nexus-agents, the plugin that ships this one along with the rest of its 33 skills, 16 agents, 1 hook.

Per session 89 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,386 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00089 $0.01386
Opus 5 $0.00044 $0.00693
Sonnet 5 $0.00018 $0.00277
Haiku 4.5 $0.00009 $0.00139

Measured 3d ago against content hash 57378c145537, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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 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.

skills/test-driven-development/SKILL.md · 106 lines

How it starts

The opening of the file, as written. The whole thing — 106 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Test-Driven Development Skill

Full workflow: CONTRIBUTION_GUIDE.md. Prime directive: CLAUDE.md → Development Disciplines.

When to apply

  • Any new logic or behavior — write the test first
  • Bug fixes — use the Prove-It Pattern (failing test demonstrates the bug, then fix)
  • Modifications to existing functionality
  • Edge cases and error paths
  • Any change that risks regressing tested behavior

Skip TDD for:

  • Configuration-only edits (pure values, no branching)
  • Documentation changes
  • Static asset moves with no behavioral impact

The Red-Green-Refactor cycle

  1. RED — write a test that fails because the functionality doesn't exist yet. Run it. Confirm the failure message points at the missing piece.
  2. GREEN — implement the minimum code to make the test pass. Resist the urge to "round out" the API in the same step.
  3. REFACTOR — improve names, structure, duplication while keeping the test green. Run the suite after every refactor step.

The Prove-It Pattern (bug fixes)

When a bug is reported:

  1. Reproduce the bug with a minimal failing test.
  2. Confirm the test fails in main — this proves the bug exists and your test is correctly sensitive.
  3. Implement the fix at the root cause (see bug-fix skill for triage layering).
  4. Confirm the test now passes.
  5. Run the full suitepnpm test — to catch regressions the fix may have introduced elsewhere.

The test stays as a regression guard. Future refactors can't silently re-break this case.

Test pyramid (target shape)

Tier Share Latency Scope
Unit ~80% milliseconds single module, no I/O
Integration ~15% seconds component interactions, may touch fs/db
E2E ~5% minutes critical user flows end-to-end

Read the full file on GitHub · 106 lines

Changes

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.

  1. 3d ago First seen · 106 lines · 89 tokens per session scan A 57378c145537

Subscribe to this mod's changes

test-driven-development is a skill published in the GitHub repository nexus-substrate/nexus-agents (18 stars, last pushed 2d ago), licensed MIT. It adds 89 tokens to every session and 1,386 once invoked, about $0.0004 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.

Related

Other skills, from other repositories

agent-integration

Run all three agent integration phases sequentially: research, write-tests, and implement using E2E-first TDD (unit tests written last). For individual phases, use /agent-integration:research, /agent-integration:write-tests, or /agent-integration:implement. Use when the user says "integrate agent", "add agent…

entireio/cli · 89 tokens

engram-testing-coverage

TDD and coverage standards for Engram. Trigger: When implementing behavior changes in any package.

Gentleman-Programming/engram · 25 tokens

code-assist

Guides implementation of code tasks using test-driven development in an Explore, Plan, Code, Commit workflow. Acts as a Technical Implementation Partner and TDD Coach — following existing patterns, avoiding over-engineering, and producing idiomatic, modern code.

mikeyobrien/ralph-orchestrator · 53 tokens

tdd

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

GreyDGL/PentestGPT · 33 tokens

css-design-tdd

Test-driven CSS design system modifications. Run checks before/after CSS changes to verify token usage, variable definitions, fallbacks, and consistency. Use when modifying CSS tokens, fixing design inconsistencies, or auditing CSS architecture.

xiaolai/vmark · 49 tokens

mobiai-mobile-tdd

You MUST use this before writing any implementation code for a mobile feature, bug fix, refactor, or behavior change. Tests come before implementation — no exceptions.

ArisGuimera/MobiAI-Core · 38 tokens