feat(tdd-criteria): v0.3.0 — test-quality reference adapted from mattpocock tdd (MIT)

- new 'Test quality' section: good-test definition, pre-agreed seams, anti-patterns
  (implementation-coupled / tautological / horizontal slicing), rules of the loop
- provenance noted inline (adapted-from mattpocock/skills tdd)
- our WHEN-policy (8-question algorithm, carve-outs, anti-loophole) unchanged
- lint: 0/0; dist rebuilt; ~/.claude/skills synced

skills/tdd-criteria/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: tdd-criteria
 author: ours
-version: 0.2.0
+version: 0.3.0
 description: >
   TDD by default with four bright-line carve-outs. Applies before any code
   change. Triggers: "TDD", "test-driven", "следуй TDD", "use TDD",
@@ -54,6 +54,24 @@ Walk through in order. First «yes» determines mode. All «no» → TDD by defa
 
 In all four, recovery cost from silent deletion is high. The test is the only artefact that makes deletion visible.
 
+## Test quality (what makes a test worth keeping)
+
+> Adapted from `mattpocock/skills` `tdd` (MIT) — the HOW of the red-green loop, kept as a reference to consult during the loop, not after.
+
+**A good test verifies behavior through public interfaces, not implementation details.** Code can change entirely; tests shouldn't. A good test reads like a specification — «user can checkout with valid cart» tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.
+
+**Seams — where tests go.** A seam is the public boundary you test at. Tests live at seams, never against internals. Before writing any test, write down the seams under test and confirm them with the user — no test is written at an unconfirmed seam. You can't test everything; agreeing seams up front lands testing effort on critical paths instead of every edge case.
+
+**Anti-patterns:**
+- *Implementation-coupled* — mocks internal collaborators, tests private methods, or verifies through a side channel. Tell: the test breaks on refactor while behavior hasn't changed.
+- *Tautological* — the assertion recomputes the expected value the way the code does (`expect(add(a,b)).toBe(a+b)`), so it passes by construction. Expected values must come from an independent source of truth — known-good literal, worked example, spec.
+- *Horizontal slicing* — all tests first, then all implementation. Bulk tests verify imagined behavior and commit you to test structure before you understand the implementation. Work in vertical slices: one test → one implementation → repeat, each test a tracer bullet.
+
+**Rules of the loop:**
+- Red before green — failing test first, then only enough code to pass. No speculative features.
+- One slice at a time — one seam, one test, one minimal implementation per cycle.
+- Refactoring is not part of the loop — it belongs to review (consistent with our refactoring carve-out above), not the red→green cycle.
+
 ## Permissive carve-outs (skip + marker required)
 
 | # | Category | Trigger | Marker |