Agent skill

Canon TDD Workflow

by adamayoung in adamayoung/TMDb

Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty.

Apache-2.0Auto-check passedTesting & QA

Install Canon TDD Workflow

skills CLI
$ npx skills add adamayoung/TMDb --skill canon-tdd -a claude-code

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

GitHub CLI
$ gh skill install adamayoung/TMDb canon-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/adamayoung/TMDb.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/canon-tdd .claude/skills/canon-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
canon-tdd
GitHub stars
178
Token cost
~1.3k tokens
SKILL.md length
748 words
Files
1
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty.

  • Works in 5 steps: Start with a test list, and show it.… → No production code before a failing… → One test at a time. Do not convert the… → …
  • Implementing a new endpoint, model or method test-first
  • SKILL.md covers Agent behaviour contract, The five steps, Separate interface from… and Anti-patterns (don't), plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

The skill sets a behavior contract for the agent. Before any production code, it writes the behaviors and edge cases as a test list and shows it to you or states it. It then writes exactly one real, automated test, runs it, and quotes the failure to confirm it fails for the expected reason. Converting the whole list into code up front is ruled out, because the first passing test often changes the design.

For a brand-new API, a compile error is the expected first failure, and the agent adds a minimal stub so the failure becomes a failing assertion. A broken import or unrelated crash is red for the wrong reason, so the test is fixed and re-run. The agent then makes that one test pass with the simplest change, refactors only while everything is green, and adds newly found cases to the list. The method follows Kent Beck's Canon TDD.

When your agent uses it

  • Implementing a new endpoint, model or method test-first
  • Fixing a bug, beginning with a failing test that reproduces it
  • Carrying out a written plan without skipping the tests
  • Refactoring only after the current tests pass

Example prompts

  • “Add a search method for TV shows and follow Canon TDD, starting with the test list.”
  • “Fix the crash when a movie has no release date, and write the failing test first.”
  • “Implement the plan in PLAN.md step by step, one failing test at a time.”

Workflow steps

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

  1. Start with a test list, and show it. Before touching production code,
  2. No production code before a failing test. Write exactly one test,
  3. One test at a time. Do not convert the whole test list into code up front
  4. Refactor only on green, and keep refactoring out of the make-it-pass step.
  5. Repeat until the test list is empty, adding newly-discovered cases to the

What it can do on your machine

Read from SKILL.md and the folder at commit a3f1311. 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

    No scripts in the folder and no shell commands in SKILL.md.

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

  • Network

    Links to these hosts (documentation or services it may open):

    • adam-young.co.uk

    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

Canon TDD Workflow loads about 1.3k tokens when it runs. Until then it costs about 74 tokens; SKILL.md has 748 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~74
When it runs · the whole SKILL.md, loaded when a task matches
~1.3k

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 adamayoung/TMDb at commit a3f1311, republished under its Apache-2.0 licence (© adamayoung). 748 words, ~1,308 tokens.

Download SKILL.mdSave it as .claude/skills/canon-tdd/SKILL.md (or your agent's skills folder).
name
canon-tdd
description
Implement features and fix bugs test-first, the Canon TDD way (test list → one test → make it pass → refactor → repeat). Use when implementing any new feature, endpoint, model, or method, fixing a bug, or executing a plan — write the test list and a failing test BEFORE production code.

Canon TDD

Test-driven development the way Kent Beck describes as "Canon TDD", per https://adam-young.co.uk/blog/canon-tdd/. CLAUDE.md mandates a TDD approach for this package; this skill is the detailed how.

Red-Green-Refactor is the engine. The Test List is the steering wheel.

Agent behaviour contract

The point of this skill: do these by default, without being reminded.

  1. Start with a test list, and show it. Before touching production code, enumerate the behaviours and edge cases as a checklist and confirm it with the user (or state it explicitly). This is the steering wheel — it defines "done".
  2. No production code before a failing test. Write exactly one test, run it, and watch it fail for the right reason. Never write the implementation first and back-fill tests.
  3. One test at a time. Do not convert the whole test list into code up front — the first passing test often forces a design change that affects the rest.
  4. Refactor only on green, and keep refactoring out of the make-it-pass step.
  5. Repeat until the test list is empty, adding newly-discovered cases to the list as you go.

The five steps

  1. Write a test list — every behavioural variant and edge case you can think of, as a plain checklist. Not code yet. It's a living list: add to it whenever implementation reveals a new case.
  2. Write a test — pick the next item and write one real, automated test: setup, invocation, and assertions. Define what the system does and how it's invoked — not how it works inside. Run it; confirm it fails — and state the failure: quote the failing assertion/message and check it is the expected reason. (For brand-new API the first red is normally a compile error — the symbol doesn't exist yet; that is expected. Stub the minimal declaration and re-run so the red becomes the failing assertion.) A compile error in existing code, a missing import, or an unrelated crash is a red for the wrong reason — it proves nothing about the behaviour, so fix the test and re-run until it is red for the right reason.
  3. Make it pass — change the system to satisfy that test with the simplest thing that works. Nothing more; resist solving items still on the list.
  4. Optionally refactor — improve names, structure, and duplication while every test stays green. Skip if there's nothing to improve.
  5. Repeat — next item, until the list is empty.

Separate interface from implementation

A test fixes a decision about the interface (the call shape, inputs, outputs) and should be silent about the internals. Tests that assert on private mechanics break under refactoring and defeat step 4.

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

Anti-patterns (don't)

  • Tests without assertions — a test that invokes but asserts nothing proves nothing.
  • Pre-converting the whole list to code — write one test, learn, then the next. Batching tests locks in design decisions before you've learned anything.
  • Mixing refactor into make-it-pass — keep "make it work" and "make it clean" as separate steps on either side of green.
  • Premature abstraction from duplication — a little duplication across two green tests is fine; abstract when the shape is clear, not at the first repeat.

In this codebase (TMDb)

Apply the loop with the project's tooling and conventions:

  • Framework: Swift Testing — @Suite, @Test, #expect, #require. Never force-unwrap in tests; unwrap optionals with try #require(...).
  • Run tests via the delegated skills, not make directly, so output stays out of context: /test (unit) and /integration-test (live API). Re-run after each red→green and after refactoring.
  • Both layers are required for new behaviour. Unit tests with JSON fixtures AND integration tests against the live API — put both kinds of items on the test list from the start.
  • Models / new endpoints: when the test list involves decoding, the fixture must exercise every decode branch (all N optional appended properties, plus a paired "without appended data" test that asserts they're nil). Use the TMDb MCP server (mcp__tmdb__*) to fetch real API responses for fixtures rather than inventing JSON — see .claude/docs/tmdb-api.md → "Workflow for New Endpoints".
  • Bug fixes: the first item on the list is a test that reproduces the bug (red), then the fix (green) — never fix first.
  • New public API: the test list should include the doc/DocC and README updates as completion items, even though they aren't tests (per the document-swift skill's consistency checklist).

When NOT to use it

Pure refactors with existing coverage, formatting, config/CI edits, and docs-only changes don't start from a new failing test — keep the existing tests green instead. TDD is for new behaviour and bug fixes.

© adamayoung, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/canon-tdd of adamayoung/TMDb.

Open the folder on GitHubat commit a3f1311

Compare with similar skills

Canon TDD Workflow 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.

Canon TDD Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Canon TDD Workflow this skilladamayoung/TMDb178—~1.3kAutomated safety check: PassApache-2.0
Jest Testing PatternsChrisWiles/claude-code-showcase6.1k7 repos~1.5kAutomated safety check: PassNone
Rust TDD Workflowrtk-ai/rtk83k—~753Automated safety check: NotesApache-2.0
TDDpietheinstrengholt/rssmonster56430 repos~906Automated safety check: PassMIT
RTK Filter TDD in Rustrtk-ai/rtk83k—~1.9kAutomated safety check: NotesApache-2.0
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone

Similar skills

  • Jest Testing Patterns

    ChrisWiles/claude-code-showcase

    Jest patterns for React Native style tests: TDD discipline, mock factory functions, module and GraphQL hook mocking, custom render helpers and anti-patterns to avoid.

    6.1k GitHub starsUsed in 7 repos~1.5k tokens
    Testing & QAAuto-check passed
  • Enforces red-green-refactor for Rust work, with idiomatic test patterns, a naming convention and a pre-commit gate of cargo fmt, clippy and test.

    83k GitHub stars~753 tokensUpdated yesterday
    Testing & QAAuto-check: notes
  • TDD

    pietheinstrengholt/rssmonster

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

    564 GitHub starsUsed in 30 repos~906 tokens
    Testing & QAAuto-check passed
  • Enforces red-green-refactor for new RTK output filters in Rust, using real captured fixtures, snapshot tests with insta and token-savings assertions.

    83k GitHub stars~1.9k tokensUpdated yesterday
    Testing & QAAuto-check: notes
  • 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
  • Official

    A skill your agent uses when a user asks to wobble ty constraint ordering, check constraint-set or TDD ordering determinism, test reversed constraint/typevar IDs, or investigate nondeterministic ty…

    50k GitHub stars~838 tokensUpdated today
    Testing & QAAuto-check passed

More from adamayoung/TMDb

All 18 skills in this repo
  • Writes and maintains DocC /// comments for the public API of the TMDb Swift package, following the project's summary patterns and comment structure.

    178 GitHub stars~2.6k tokensUpdated 7 days ago
    Auto-check passed
  • Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to.

    178 GitHub stars~2.7k tokensUpdated 7 days ago
    Auto-check passed
  • Drives an approved plan to completion test-first, deriving a Canon TDD test list, showing it before any code and stopping only when every item is written, passing and green.

    178 GitHub stars~4.5k tokensUpdated 7 days ago
    Auto-check passed
  • TMDb Backlog Triager

    adamayoung/TMDb

    Grooms the Backlog column of a GitHub project board by re-verifying each issue against current main, closing dead ones, promoting actionable ones to Ready and naming the decision the rest need.

    178 GitHub stars~5k tokensUpdated 7 days ago
    Auto-check passed
  • Capture Knowledge

    adamayoung/TMDb

    Records non-obvious lessons from a finished task, such as gotchas, API quirks and design decisions, into a project's knowledge folder before a pull request opens.

    178 GitHub stars~2.3k tokensUpdated 7 days ago
    Auto-check passed
  • Cut Release

    adamayoung/TMDb

    Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub…

    178 GitHub stars~3k tokensUpdated 7 days ago
    Auto-check passed

Categories

Questions about Canon TDD Workflow

What does Canon TDD Workflow do?

Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty. The skill sets a behavior contract for the agent. Before any production code, it writes the behaviors and edge cases as a test list and shows it to you or states it.

When should I use Canon TDD Workflow?

Canon TDD Workflow fits situations like: implementing a new endpoint, model or method test-first; fixing a bug, beginning with a failing test that reproduces it; carrying out a written plan without skipping the tests; refactoring only after the current tests pass.

How do I install Canon TDD Workflow in Claude Code?

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

How do I install Canon TDD Workflow in Codex?

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

Can I use Canon TDD Workflow 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 adamayoung/TMDb --skill canon-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/canon-tdd, .gemini/skills/canon-tdd, .github/skills/canon-tdd and .opencode/skills/canon-tdd in your project.

What does Canon TDD Workflow need to run?

SKILL.md names no scripts, command-line tools or credentials: Canon TDD Workflow is instructions for the agent only.

Does Canon TDD Workflow access the network?

SKILL.md names 1 domain. As links in the text: adam-young.co.uk. This is read from the text; nothing was executed.

Is Canon TDD Workflow 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 Canon TDD Workflow use?

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

How many tokens does Canon TDD Workflow use?

About 1.3k tokens (SKILL.md is roughly 5.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Canon TDD Workflow?

Skills that share tags, products or a category with Canon TDD Workflow: Jest Testing Patterns (ChrisWiles/claude-code-showcase, 6.1k stars), Rust TDD Workflow (rtk-ai/rtk, 83k stars), TDD (pietheinstrengholt/rssmonster, 564 stars) and RTK Filter TDD in Rust (rtk-ai/rtk, 83k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Canon TDD Workflow?

adamayoung (a GitHub user) maintains it in adamayoung/TMDb, which has 178 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 3, 2026.

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