changes

.config/opencode/skills/test-driven-development/SKILL.md

@@ -1,77 +1,36 @@
 ---
 name: test-driven-development
-description: Enforce test-first development for features and bug fixes — no production
-  code before a failing test
+description: Apply red-green-refactor by default for code changes, with narrowly defined exceptions and explicit alternate verification
 permalink: opencode-config/skills/test-driven-development/skill
 ---
 
-# Test-Driven Development (TDD)
+# Test-Driven Development
 
-## When to Use
+Use this skill for all code changes unless a narrow exception applies.
 
-Use this skill when implementing behavior changes:
-- New features
-- Bug fixes
-- Refactors that alter behavior
+## Default Cycle
 
-If the work introduces or changes production behavior, TDD applies.
+1. Red: add or identify a test that fails for the target behavior.
+2. Green: implement the minimal code change to make the test pass.
+3. Refactor: improve structure while keeping tests green.
+4. Re-run focused and relevant regression tests.
 
-## Core Rule
+## Narrow Exceptions
 
-```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
-```
+Allowed exceptions only:
 
-If production code was written first, delete or revert it and restart from a failing test.
+- docs-only changes
+- config-only changes
+- pure refactors with provably unchanged behavior
+- repos without a reliable automated test harness
 
-## Red → Green → Refactor Loop
+When using an exception, state:
 
-### 1) RED: Write one failing test
-- Write one small test that expresses the next expected behavior.
-- Prefer clear test names describing observable behavior.
-- Use real behavior paths where practical; mock only when isolation is required.
+- why TDD was not practical
+- what alternative verification was used
 
-### 2) Verify RED (mandatory)
-Run the new test and confirm:
-- It fails (not just errors)
-- It fails for the expected reason
-- It fails because behavior is missing, not because the test is broken
+## Role Expectations
 
-If it passes immediately, the test is not proving the new behavior. Fix the test first.
-
-### 3) GREEN: Add minimal production code
-- Implement only enough code to make the failing test pass.
-- Do not add extra features, abstractions, or speculative options.
-
-### 4) Verify GREEN (mandatory)
-Run the test suite scope needed for confidence:
-- New test passes
-- Related tests still pass
-
-If failures appear, fix production code first unless requirements changed.
-
-### 5) REFACTOR
-- Improve names, remove duplication, and simplify structure.
-- Keep behavior unchanged.
-- Keep tests green throughout.
-
-Repeat for the next behavior.
-
-## Quality Checks Before Completion
-
-- [ ] Each behavior change has a test that failed before implementation
-- [ ] New tests failed for the expected reason first
-- [ ] Production code was added only after RED was observed
-- [ ] Tests now pass cleanly
-- [ ] Edge cases for changed behavior are covered
-
-## Practical Guardrails
-
-- "I'll write tests after" is not TDD.
-- Manual verification does not replace automated failing-then-passing tests.
-- If a test is hard to write, treat it as design feedback and simplify interfaces.
-- Keep test intent focused on behavior, not internals.
-
-## Related Reference
-
-For common mistakes around mocks and test design, see [testing-anti-patterns](./testing-anti-patterns.md).
+- Planner: specify tasks and verification that preserve red-green-refactor intent.
+- Builder/Coder: follow TDD during implementation or explicitly invoke a valid exception.
+- Tester/Reviewer: verify that TDD evidence (or justified exception) is present.