test-driven-development

name	test-driven-development
description	Repo-local TDD workflow for Zoolanding implementation work. Use before behavior-changing Angular, tooling, or sibling-Lambda code changes. Skip as the default path for draft JSON, content-only, and docs-only edits.
user-invocable	true

Test-Driven Development

Write the failing proof first, then write the smallest code that makes it pass.

Default Scope In This Repo

Use this for:

• Angular services, route logic, and runtime behavior
• local tooling and authoring sync code
• sibling-Lambda behavior changes
• regressions that can be pinned to a reproducible command or route contract

Do not treat this as the default path for:

• draft JSON edits
• content-only changes
• docs-only changes

Workflow

1. Define the failing proof first.

   • Add or update the narrowest test that demonstrates the intended behavior change.
   • If the area lacks an automated harness, create the smallest reproducible command or fixture before implementation.

2. Verify the proof fails for the right reason.

   • Confirm the failure matches the missing or broken behavior.
   • Fix the test if it fails for setup noise instead of the intended reason.

3. Write the minimal implementation.

   • Change only the code needed to satisfy the failing proof.
   • Avoid speculative helpers and unrelated cleanup.

4. Re-run the narrow proof.

   • Confirm the targeted test or reproduction now passes.

5. Run the smallest adjacent regression check.

   • Add one nearby test or focused verification step when the change could break adjacent behavior.

6. Refactor only after green.

   • Keep behavior unchanged while improving structure.

Repo-Specific Guidance

• Pair this skill with karpathy-guidelines for scope control.
• For draft-affecting UI behavior, automated proof does not replace the required desktop and mobile browser QA closeout.