feat: add verification and debugging workflow skills

.config/opencode/skills/test-driven-development/testing-anti-patterns.md

@@ -0,0 +1,83 @@
+---
+title: testing-anti-patterns
+type: note
+permalink: opencode-config/skills/test-driven-development/testing-anti-patterns
+---
+
+# Testing Anti-Patterns
+
+Use this reference when writing/changing tests, introducing mocks, or considering test-only production APIs.
+
+## Core Principle
+
+Test real behavior, not mock behavior.
+
+Mocks are isolation tools, not the subject under test.
+
+## Anti-Pattern 1: Testing mock existence instead of behavior
+
+**Problem:** Assertions only prove a mock rendered or was called, not that business behavior is correct.
+
+**Fix:** Assert observable behavior of the unit/system under test. If possible, avoid mocking the component being validated.
+
+Gate check before assertions on mocked elements:
+- Am I validating system behavior or only that a mock exists?
+- If only mock existence, rewrite the test.
+
+## Anti-Pattern 2: Adding test-only methods to production code
+
+**Problem:** Production classes gain methods used only by tests (cleanup hooks, debug helpers), polluting real APIs.
+
+**Fix:** Move test-only setup/cleanup into test utilities or fixtures.
+
+Gate check before adding a production method:
+- Is this method needed in production behavior?
+- Is this resource lifecycle actually owned by this class?
+- If not, keep it out of production code.
+
+## Anti-Pattern 3: Mocking without understanding dependencies
+
+**Problem:** High-level mocks remove side effects the test depends on, causing false positives/negatives.
+
+**Fix:** Understand dependency flow first, then mock the lowest-cost external boundary while preserving needed behavior.
+
+Gate check before adding a mock:
+1. What side effects does the real method perform?
+2. Which side effects does this test rely on?
+3. Can I mock a lower-level boundary instead?
+
+If unsure, run against real implementation first, then add minimal mocking.
+
+## Anti-Pattern 4: Incomplete mock structures
+
+**Problem:** Mocks include only fields used immediately, omitting fields consumed downstream.
+
+**Fix:** Mirror complete response/object shapes used in real flows.
+
+Gate check for mocked data:
+- Does this mock match the real schema/shape fully enough for downstream consumers?
+- If uncertain, include the full documented structure.
+
+## Anti-Pattern 5: Treating tests as a follow-up phase
+
+**Problem:** "Implementation complete, tests later" breaks TDD and reduces confidence.
+
+**Fix:** Keep tests inside the implementation loop:
+1. Write failing test
+2. Implement minimum code
+3. Re-run tests
+4. Refactor safely
+
+## Quick Red Flags
+
+- Assertions target `*-mock` markers rather than behavior outcomes
+- Methods exist only for tests in production classes
+- Mock setup dominates test logic
+- You cannot explain why each mock is necessary
+- Tests are written only after code "already works"
+
+## Bottom Line
+
+If a test does not fail first for the intended reason, it is not validating the behavior change reliably.
+
+Keep TDD strict: failing test first, then minimal code.