developing-features-tddlisted

# Developing Features with TDD Test-driven feature development. Every observable behavior is driven by a failing test that goes RED → GREEN, with architecture planned before the first test is written. > **Never write production code for a new feature before proving its expected behavior with a failing test.** ## Read first (always) List `learnings/` and read every file relevant to the current feature. Project-specific test conventions, framework quirks, or constraints live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user. ## Tradeoff — when to apply, when to lighten up Apply the full nine-phase cycle for **production features** the user explicitly asks to build with TDD, or for code paths where regressions are expensive (payments, auth, data integrity, AI runtime, public APIs). Lighten the formality for one-off scripts, throwaway exploration, prototypes the user has labeled as such, or features under 30 lines of production code. Still write at least one happy-path test and one adversarial test — but skip the explicit Phase 2 design document. ## Best practices — inherited from `developing-features` (this skill changes only the *how*) Every engineering standard in `developing-features` applies here **in full and unchanged**. TDD changes *how* you implement (test-first: RED → GREEN → REFACTOR), not *what* "good" means — it never relaxes or replaces these: - The **pre-implementation