update skills

.agents/skills/tdd/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: tdd
-description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
+description: Build or fix behavior test-first through red-green-refactor. Use when the user requests TDD or test-first development, not merely any integration-test task.
 ---
 
 # Test-Driven Development
 
-TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
+TDD is the red → green → refactor loop. Use behavior-level tests to guide small changes; choose checks proportional to the task.
 
 When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
 
@@ -19,11 +19,9 @@ See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking g
 
 A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
 
-**Test only at pre-agreed seams.** 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 the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
+Reuse established test boundaries and any seams already agreed with the user. Choose a seam that exercises the actual behavior, including persistence or integration contracts where those are the subject of the test. State a new choice briefly; ask only if it introduces a consequential design trade-off that cannot be inferred from the request and code.
 
-Ask: "What's the public interface, and which seams should we test?"
-
-When the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — use the `/codebase-design` skill for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
+Prioritize critical paths, failure modes, and complex logic; do not block routine tests on repeated seam approval.
 
 ## Anti-patterns
 
@@ -35,4 +33,4 @@ When the shape of that interface is itself in question — how deep the module i
 
 - **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add 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 the review stage (see the `code-review` skill), not the red → green implementation cycle.
+- **Refactor while green.** Simplify the changed code and tests without changing behavior, then rerun the checks. Keep unrelated redesign outside the task.