tdd

Invoke the tdd skill with a unit of work description, and it walks through red-green-refactor phases with hard stops. It writes one failing test first, adds minimal implementation code, then refactors, committing after each phase.

Each phase gets its own commit with a strict prefix convention: test(red): for the failing test, feat(green): for the implementation, and refactor: for cleanup. Only relevant files are staged per phase, and squashing is deferred until after QA approval.

The skill detects Swift (swift test), Node (npm test), Go (go test), Python (pytest), Rust (cargo test), and Java (Maven or Gradle) via marker files like Package.swift, package.json, go.mod, or Cargo.toml, then uses the matching build and test commands.

The cycle stops immediately. A passing test means either the feature already exists or the test does not actually cover the new behavior, so you must fix the test or confirm the feature exists before proceeding.

No. If no test runner is detected, the skill stops and provides setup suggestions per language, such as adding pytest for Python or a test script in package.json for Node. It will not proceed without a working test runner.

The pre-flight step runs the full suite to establish a baseline. If tests already fail, the cycle stops because you cannot distinguish new failures from pre-existing ones, so the existing failures must be fixed first.