Agent skill

TDD

by Asymmetric-al in Asymmetric-al/core

Test-driven development for substantive feature, bug-fix, and behavior-changing work.

AGPL-3.0Auto-check passedTesting & QA

Install TDD

skills CLI
$ npx skills add Asymmetric-al/core --skill tdd -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Asymmetric-al/core tdd --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Asymmetric-al/core.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/tdd .claude/skills/tdd && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
tdd
GitHub stars
381
Token cost
~1.6k tokens
SKILL.md length
862 words
Files
5 (incl. references)
Skills in repo
43
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Test-driven development for substantive feature, bug-fix, and behavior-changing work.

  • Works in 8 steps: Understand the expected behavior from… → Inspect current implementation and… → Add or update a test that expresses the… → …
  • The user mentions TDD
  • SKILL.md covers This repository…, What a good test is, Seams: where tests go and Anti-patterns, plus 1 more section
  • Calls bun

What it does

TDD is an agent skill from Asymmetric-al/core. Test-driven development for substantive feature, bug-fix, and behavior-changing work. Use automatically when implementing features, fixing bugs, or changing behavior (red → green → refactor). Also use when the user mentions TDD, /tdd, /TDD, or red-green-refactor. Do not use for documentation-only, formatting-only, exact generated-mirror, or provenance-only changes.

Its SKILL.md is about 1.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 6 other files, including reference files (for example `agents/openai.yaml`, `mocking.md` and `references/upstream.md`).

It sits in Testing & QA, covering Test-driven development. The repository describes itself as: A high-performance, enterprise-grade Next.js 16 application for mission-focused non-profit organizations. Built for high impact teams. The licence is AGPL-3.0.

When your agent uses it

  • The user mentions TDD
  • Red-green-refactor
  • Documentation-only
  • Formatting-only

Example prompts

  • “/tdd”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Understand the expected behavior from the request, existing tests, and
  2. Inspect current implementation and tests. Use an established public seam
  3. Add or update a test that expresses the desired behavior or reproduces the
  4. Run it and confirm it fails for the expected reason when that is meaningful.
  5. Make the smallest correct implementation change.
  6. Run the focused test until it is green.
  7. Refactor where justified while tests remain green. Refactoring is part
  8. Run broader relevant validation. Verify runtime or browser behavior when the

What it can do on your machine

Read from SKILL.md and the folder at commit c30c8ff. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bun

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

TDD loads about 1.6k tokens when it runs, and up to ~1.9k if it reads all its reference files. Until then it costs about 93 tokens; SKILL.md has 862 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~93
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Asymmetric-al/core at commit c30c8ff, republished under its AGPL-3.0 licence (© Asymmetric-al). 862 words, ~1,555 tokens.

Download SKILL.mdSave it as .claude/skills/tdd/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
tdd
description
Test-driven development for substantive feature, bug-fix, and behavior-changing work. Use automatically when implementing features, fixing bugs, or changing behavior (red → green → refactor). Also use when the user mentions TDD, /tdd, /TDD, or red-green-refactor. Do not use for documentation-only, formatting-only, exact generated-mirror, or provenance-only changes.

This repository (Asymmetric-al/core)

These repo-owned sections are intentionally kept on top of the vendored Matt Pocock TDD skill. If upstream refreshes replace this file, reconcile this overlay before running bun run skills:sync.

TDD is the default workflow for substantive Core implementation. Do not wait for the user to type /tdd or /TDD. /tdd and /TDD resolve to this same workflow.

Triggers
  • Implementing a feature, bug fix, or behavior-changing refactor.
  • The user mentions TDD, /tdd, /TDD, or red-green-refactor.
  • Changing executable behavior, types, migrations, RLS, or generated-file contracts.

Do not invent an artificial RED test for documentation-only edits, formatting-only edits, exact generated-mirror updates, or provenance-only metadata.

Workflow
  1. Understand the expected behavior from the request, existing tests, and nearest public or architectural seam.
  2. Inspect current implementation and tests. Use an established public seam without waiting for the user to approve an obvious seam.
  3. Add or update a test that expresses the desired behavior or reproduces the bug.
  4. Run it and confirm it fails for the expected reason when that is meaningful.
  5. Make the smallest correct implementation change.
  6. Run the focused test until it is green.
  7. Refactor where justified while tests remain green. Refactoring is part of Core's loop after green.
  8. Run broader relevant validation. Verify runtime or browser behavior when the change is user-visible.

Prefer characterization tests before changing poorly understood legacy behavior. Prefer tests that prove behavior at a stable seam over implementation-coupled tests.

Checklist
  • Substantive behavior change used TDD (or a documented exception)
  • /tdd and /TDD were treated as this same workflow
  • Established seams were used without blocking on user approval
  • Refactor happened only after green, if at all
  • Docs/format/mirror/provenance work did not invent a fake RED test

The vendored Matt Pocock body below is kept for provenance. These lines are non-operative in Core and must not override the overlay:

  • "Refactoring is not part of the loop."
  • "Test only at pre-agreed seams" / confirm seams with the user before writing a test.
  • "No production code without a failing test first" for documentation-only, formatting-only, exact generated-mirror, or provenance-only work.

Test-Driven Development

TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.

When exploring the codebase, read CONTEXT.md (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.

What a good test is

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure.

See tests.md for examples and mocking.md for mocking guidelines.

Show full SKILL.md (379 more words)Show less

Seams: where tests go

A seam is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.

Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.

Ask: "What's the public interface, and which seams should we test?"

When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), call the Skill tool with "codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.

Anti-patterns

  • Implementation-coupled: mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
  • Tautological: the assertion recomputes the expected value the way the code does (expect(add(a, b)).toBe(a + b), a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, the spec.
  • Horizontal slicing: writing all tests first, then all implementation. Bulk tests verify imagined behavior: you test the shape of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in vertical slices instead: one test → one implementation → repeat, each test a tracer bullet that responds to what the last cycle taught you.

Rules of the loop

  • Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
  • One slice at a time. One seam, one test, one minimal implementation per cycle.
  • Refactoring is not part of the loop. It belongs to the review stage (see the code-review skill), not the red → green implementation cycle.

© Asymmetric-al, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files (references) in .agents/skills/tdd of Asymmetric-al/core.

  • SKILL.md
  • agents/openai.yaml
  • mocking.md
  • references/upstream.md
  • tests.md

Open the folder on GitHubat commit c30c8ff

Compare with similar skills

TDD next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

TDD compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
TDD this skillAsymmetric-al/core381—~1.6kAutomated safety check: PassAGPL-3.0
TDDpietheinstrengholt/rssmonster56430 repos~906Automated safety check: PassMIT
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone
TDDsanity-io/sanity6.4k20 repos~1kAutomated safety check: PassMIT
Test Driven Developmentfarm-fe/farm5.6k51 repos~2.5kAutomated safety check: PassMIT
Tapd Story PipelineTencentBlueKing/bk-bcs840—~2.6kAutomated safety check: PassCustom licence

Similar skills

  • TDD

    pietheinstrengholt/rssmonster

    Test-driven development. An agent skill from pietheinstrengholt/rssmonster.

    564 GitHub starsUsed in 30 repos~906 tokens
    Testing & QAAuto-check passed
  • TDD Workflow

    hellangleZ/burn-in-cceverywhere-ralph

    A skill your agent uses when writing new features, fixing bugs, or refactoring code.

    112 GitHub starsUsed in 11 repos~2.4k tokens
    Testing & QAAuto-check passed
  • TDD

    sanity-io/sanity

    Official

    Test-driven development with red-green-refactor loop. An agent skill from sanity-io/sanity.

    6.4k GitHub starsUsed in 20 repos~1k tokens
    Testing & QAAuto-check passed
  • A skill your agent uses when implementing any feature or bugfix, before writing implementation code

    5.6k GitHub starsUsed in 51 repos~2.5k tokens
    Testing & QAAuto-check passed
  • Tapd Story Pipeline

    TencentBlueKing/bk-bcs

    单需求实现流水线——把一个 TAPD 需求从零推进到代码提交。自动串联技术澄清、 开发计划、任务拆分、TDD 实现、架构/安全校验、代码提交六个阶段。

    840 GitHub stars~2.6k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Absolute Init

    maddhruv/absolute

    One-time setup for absolute: interview how you want it to behave (output style, autonomy, TDD strictness, spec dir, families) + detect the stack once, then write .absolute.config.json (project…

    219 GitHub starsUsed in 1 repo~3k tokens
    Testing & QAAuto-check passed

More from Asymmetric-al/core

All 43 skills in this repo
  • Idempotency Handling

    Asymmetric-al/core

    Implement idempotency keys and handling to ensure operations can be safely retried without duplicate effects.

    381 GitHub stars~867 tokensUpdated today
    Auto-check passed
  • Accessibility Review

    Asymmetric-al/core

    Audit and fix accessibility in Core UI. An agent skill from Asymmetric-al/core.

    381 GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Agent Email Inbox

    Asymmetric-al/core

    A skill your agent uses when building any system where email content triggers actions — AI agent inboxes, automated support handlers, email-to-task pipelines, or any workflow processing untrusted…

    381 GitHub stars~4.1k tokensUpdated today
    Auto-check: notes
  • Components Build

    Asymmetric-al/core

    Build modern, composable, and accessible React UI components following the components.build specification.

    381 GitHub stars~2.1k tokensUpdated today
    Auto-check passed
  • Create Agent

    Asymmetric-al/core

    Guides a one-question-at-a-time design interview, captures alignment in agent/EVE-BRIEF.md, then scaffolds and implements a runnable eve agent with verbose teaching comments.

    381 GitHub stars~2.6k tokensUpdated today
    Auto-check: notes
  • Emil Design Engineering

    Asymmetric-al/core

    Design engineering principles and patterns for building polished, accessible web interfaces.

    381 GitHub stars~1.4k tokensUpdated today
    Auto-check passed

Categories

Questions about TDD

What does TDD do?

Test-driven development for substantive feature, bug-fix, and behavior-changing work. TDD is an agent skill from Asymmetric-al/core. Test-driven development for substantive feature, bug-fix, and behavior-changing work.

When should I use TDD?

TDD fits situations like: the user mentions TDD; red-green-refactor; documentation-only; formatting-only.

How do I install TDD in Claude Code?

Run `npx skills add Asymmetric-al/core --skill tdd -a claude-code`. Or copy the skill folder (.agents/skills/tdd in Asymmetric-al/core) into .claude/skills/tdd in your project. Claude Code loads it when a task matches its description.

How do I install TDD in Codex?

Run `npx skills add Asymmetric-al/core --skill tdd -a codex`. Or copy the skill folder (.agents/skills/tdd in Asymmetric-al/core) into .agents/skills/tdd in your project. Codex loads it when a task matches its description.

Can I use TDD in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Asymmetric-al/core --skill tdd -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/tdd, .gemini/skills/tdd, .github/skills/tdd and .opencode/skills/tdd in your project.

What does TDD need to run?

Going by SKILL.md and its folder, TDD needs the command-line tools its instructions call (bun).

Does TDD access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is TDD safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does TDD use?

TDD is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does TDD use?

About 1.6k tokens (SKILL.md is roughly 6.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 313 tokens, read only when the agent opens those files.

What are the alternatives to TDD?

Skills that share tags, products or a category with TDD: TDD (pietheinstrengholt/rssmonster, 564 stars), TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars), TDD (sanity-io/sanity, 6.4k stars) and Test Driven Development (farm-fe/farm, 5.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains TDD?

Asymmetric-al (a GitHub organization) maintains it in Asymmetric-al/core, which has 381 GitHub stars. The repository holds 43 skills in this directory. The repository was last updated on October 9, 2026.

Source: Asymmetric-al/core on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.