tdd-workflowlisted

# TDD Workflow ## Purpose Use this skill for production feature work, confirmed bug fixes, and refactors where tests should guide the change. The core rule is one observable behavior at a time: ```text RED: write one failing behavior test GREEN: write the smallest production change that passes it REFACTOR: clean up only while green ``` Do not use this skill to find an unknown root cause. Use `diagnose` first, then return here once the failing behavior is understood. Do not use it for disposable design learning; use `prototype` first. ## Test Through Public Behavior Prefer tests that exercise the public interface a caller or user actually depends on. Good tests: - describe what the system does, not how internals are arranged - survive internal refactors - use project vocabulary from existing docs and code - fail for a reason that would matter to a user, caller, or maintainer Avoid tests that lock down private methods, incidental data shapes, internal collaborators, or implementation order. If a refactor breaks the test while behavior is unchanged, the test was too coupled. Read `references/tests.md` and `references/mocking.md` when choosing seams or mocks. ## Workflow ### 1. Confirm The Slice Before editing production code: - identify the public interface or user flow being changed - list the first behavior to prove - inspect nearby tests and project conventions - name any design uncertainty that should be prototyped first If the user asked for a broad feature,