afk-tddlisted

# Skill: afk-tdd Test-driven development tuned for unattended AFK runs. ## Philosophy Tests verify **behavior through public interfaces**, not implementation. A good test reads like a specification. A test that breaks on internal refactors is testing the wrong thing — fix the test, not the code. ## Anti-pattern: horizontal slicing **Do not** write all tests first then all implementation. That produces tests written against imagined behavior. Instead, **vertical slice**: ``` WRONG (horizontal): RED: t1, t2, t3, t4, t5 GREEN: i1, i2, i3, i4, i5 RIGHT (vertical): RED→GREEN: t1 → i1 RED→GREEN: t2 → i2 … ``` ## Workflow ### 1. Plan the test surface (≤ 5 minutes of thinking) Before writing any code, list 3–7 behaviors that matter for the issue's acceptance criteria. Think *behaviors*, not implementation steps. Identify which deserve tests vs. which are visual-only smoke. You may **not** interrupt the developer mid-AFK-run to confirm. Pick sensibly; the reviewer agent and the human PR reviewer will catch overreach. If you find yourself unsure between two materially different test surfaces, emit `<promise>BLOCKED</promise>` and let the developer resolve it. ### 2. Tracer bullet Write **one** test that confirms one behavior: ``` RED: write test → run it → must fail for the right reason GREEN: write minimal code → run test → passes ``` This proves the path is wired. Commit (`AFK: red→green: <behavior> (issue #N)`). ### 3. Incremental loop For each remaini