Implementer Tdd And Quality

---
name: implementer-tdd-and-quality
description:
  "Use when writing tests, running tests, hitting a quality gate, or before
  reporting a task done. Loads project-specific test and quality discipline that
  complements superpowers:test-driven-development."
# source: claude-plugin/skills/implementer-tdd-and-quality/SKILL.md
---

## Implementer: TDD and Quality

This skill **complements** `superpowers:test-driven-development` — it does not
restate the red-green-refactor discipline, the iron law on watching tests fail,
or any other content from that skill. Layer this content on top of those
universals: the rules below capture project-specific Go conventions and
quality-gate practice.

### Run the race or concurrency check your project configures

**Why:** Code with significant concurrent state (goroutines, threads, async
tasks) can pass a plain test run and still fail under the language's race or
concurrency checker, sometimes with silent data corruption that takes hours to
track down later.

**How to apply:** Read `.thrum/gate-config.json` (the `per_landing` entries of
kind `race`, or the commands your project documents) and run the race or
concurrency check it names on the packages you touched. Never report tests
passing without having run it, when your project has one. If your project has
none, say so in your report. (Go example:
`go test -race ./internal/<pkg>/... -count=1`.)

### Scope test runs to packages you touched

**Why:** Running the entire test tree on every iteration of a fix-test loop is
wasteful — most packages weren't touched and their tests will pass identically
every iteration. Scoping speeds the inner loop without sacrificing correctness;
the full tree gets one final run before reporting done.

**How to apply:** During the inner fix-test loop, run only the affected packages
with a test selector (Go example:
`go test -race ./internal/<pkg>/... -run <TestName>`). Once the scoped tests
pass and you're ready to report done, run the whole-lane test command from
`.thrum/gate-config.json` (`per_landing`, or `full_fallback` when selection
cannot run) once to confirm nothing else broke.

### Use `t.TempDir()` for filesystem fixtures — never hardcoded paths

**Why:** Hardcoded absolute paths (especially the implementer's home directory)
only work on one machine. A test that bakes in a literal path like `<repo-root>`
passes locally and fails everywhere else — the fix is usually as small as
swapping in `t.TempDir()`. The same pattern shows up with `os.UserHomeDir()`
results being baked into expected values.

**How to apply:** Any test that creates a temporary directory, writes files, or
needs an isolated git repo must use `t.TempDir()`. It is cleaned up
automatically and is unique per test run. If you need a git repo, initialize it
in the temp dir: `cmd := exec.Command("git", "init", t.TempDir())`. For fixtures
comparing paths, capture the temp dir into a variable and reference it in
expected values — never hardcode.

### Run the static checks before reporting

**Why:** Static analysis (a vet pass, a type check, a linter) catches a class of
bugs that compile but are wrong: unreachable code, suspicious conversions,
malformed format arguments. Code that fails the checks gets caught in CI or by
review; running them locally catches it pre-commit when the fix is one line.

**How to apply:** Before reporting done, run the lint and static-check commands
from `.thrum/gate-config.json` (`per_landing` kinds `lint`, plus
`structural_checks`), or the commands your project documents. All should pass
clean. Run a check in its read-only form, never a fix mode that rewrites tracked
files (the `write_capable_targets` there). If a finding looks like a false
positive, prefer a small annotation or refactor to silencing the warning. (Go
example: `go vet ./...`.)

### Two-stage self-review before pinging the coordinator

**Why:** A self-review pass before the coordinator's dual review reduces total
review round-trips. Self-review is not ceremony; it pre-pays the cost of issues
that would otherwise come back as findings.

**How to apply:** At task close, before sending DONE:

1. **Spec compliance pass.** Read each acceptance criterion from the task
   description. For every test case the spec mentions, verify it exists in the
   test file. For every behavior change the spec specifies, verify it's
   implemented and tested.
2. **Code quality pass.** Read your full diff
   (`git --no-pager diff <base>...HEAD`). Watch for: hardcoded paths,
   `os.UserHomeDir` baked into tests, inline `exec.Command` calls that should
   use `safecmd`, swallowed errors, missing `slog` calls on recoverable
   failures.
3. **Primitive ledger pass.** If this diff adds I/O or SQL under a hot root
   (`Handle*`/tick/sweeper/`SyncApplier`/boot — see `.thrum/hotpath-gate.json`'s
   `lenses.existing_primitive_bypass.hot_root_indicators`), confirm you have a
   ledger row: raw op -> callee package searched -> primitive adopted, or none
   exists + bounded cost formula (frequency x production cardinality, at
   production scale). Include it in your DONE report.
   - Before writing a raw read-in-loop, `db.Query`-in-loop,
     `COUNT(DISTINCT ...)`, or a second transaction or pool acquisition per
     logical unit under a hot root, search the callee package for an existing
     targeted, cached, covering or batch primitive.

Fix what you find before sending the ping.

### Project-specific rules (already loaded)

Load the $thrum:project-rules-protocol skill and follow it.

If you accumulate a new rule mid-session (the user corrects you), capture it via
the Memory section of your role preamble — it references the `thrum-memory`
skill for the canonical `thrum memory create` shape.