TMDb: Skill for Claude Code

Implement Plan

Turn the current plan into working, tested code — strictly test-first. This skill is the wrapper that ties three things together: the plan (what to build), the canon-tdd skill (how to build it), and a single finishing condition — the test list is empty (when to stop). It does not invent its own TDD rules; it delegates the discipline to canon-tdd and adds plan-awareness, the finishing goal, and the project's specialist skills.

Red-Green-Refactor is the engine. The test list is the steering wheel. This skill keeps the wheel on screen and drives until the list is empty.

Agent Behaviour Contract

These are non-negotiable. Do them by default, without being reminded.

1. Canon TDD is mandatory — invoke the canon-tdd skill. No production code before a failing test. One test at a time. Refactor only on green. This skill exists to enforce that loop against the plan; do not freelance an implementation-first approach.
2. Show the test list before any code — and every time it changes. Print the Canon TDD test list as a checklist before the first edit, and re-print it whenever you add, remove, reword, or check off an item (see Keep the test list visible).
3. The finishing condition is an empty test list. "Done" means every item on the list has a written, passing test and the full suite is green — nothing less. Pair this with the /goal command for autonomous cross-turn iteration (see Set the finishing goal). Exactly three kinds of item are exempt, because canon-tdd puts them on the list and no test can assert them: the /// doc comment, the DocC catalog entry, and the README.md update. They are done when make build-docs passes and the README is in sync — not when a test covers them. Nothing else is exempt; don't reclassify a behavioural item into this set.
4. Reach for the right specialist skill. Use swift-testing-expert when writing/structuring tests and swift-concurrency for anything touching tasks, actors, @MainActor, Sendable, or data races — don't hand-roll what those skills know.
5. Document every public declaration — no exceptions. Documenting it is part of "make it pass". Every public protocol, class, struct, enum, actor, model, property, initializer, method, subscript, and typealias you add or change MUST carry an accurate /// doc comment, and the DocC catalog must stay in sync (see Document every public declaration). This is mandatory, not optional — make build-docs runs warnings-as-errors, so an undocumented public symbol is a build failure.
6. Expect Swift files to change after you write them. A PostToolUse hook runs swiftlint --fix + swiftformat on every .swift file you Edit/Write, so the on-disk content can differ from what you wrote (see The lint/format hook).
7. Commit at logical checkpoints — always green. Like a human engineer, commit when a cohesive increment is complete and the code is in a good state, and never commit a red or half-finished tree (see Commit at logical points). This keeps the work committed as you go, so a downstream review sees real history rather than an empty diff.
8. Finish with the completion checklist. Before declaring done, run /test and /integration-test — both REQUIRED to pass per CLAUDE.md — plus /lint, and make build-docs whenever public API changed.