tdd

# Test-Driven Development Enforce strict RED-GREEN-REFACTOR discipline. One test at a time. Tests describe WHAT the system does, never HOW. --- ## Input Check `$ARGUMENTS` for the feature or behavior description. - If `$ARGUMENTS` contains a feature description, use it directly. - If `$ARGUMENTS` contains **"after"** (e.g., `/tdd after`), run in **Test-After Mode** — write tests for existing code. See `rules/test-after.md`. - If `$ARGUMENTS` is empty, ask the user what behavior they want to implement or test. --- ## Step 0: Discover Project Test Setup Before writing any tests: 1. **Find existing tests** — glob for `**/*.test.*`, `**/*.spec.*`, `**/*_test.*`, `**/test_*.*`, `**/tests/**` to identify the test framework, naming conventions, and directory structure. 2. **Find the test runner** — check `package.json` scripts, `Makefile`, `pyproject.toml`, `Cargo.toml`, `go.mod`, or similar for the test command. 3. **Adopt existing patterns** — match the project's test style exactly: same imports, same assertion library, same file naming, same directory placement. Never introduce a new test framework or pattern. 4. **Identify the run command** — store it mentally as `TEST_CMD` for use throughout the cycle. If you can run a single test file or test case, prefer that over the full suite. If no tests exist yet, ask the user which framework to use before proceeding. --- ## Step 1: Prioritize by Business Criticality Before diving into implementation, identify what matters m...