test-architectlisted

# test-architect — tests that would catch the bug ## When to use this skill Trigger when the user wants tests for specific code. Strong signals: - "write tests for `<file or function>`" - "cover this with tests" - "add unit tests" - "I need tests for this" - A function pasted with no further context Do *not* trigger for: e2e/browser flows (use `browser-qa`), test infrastructure setup, or when the user only wants you to fix a failing test (just fix it). ## The output contract Tests that: 1. **Run** — `npm test`, `pytest`, `go test`, etc., all green on the new file. 2. **Match the codebase** — same framework, same test file location, same naming convention as the existing tests. 3. **Cover the contract**, not the implementation — happy path, failure modes, boundary values, empty/null inputs. 4. **Fail when behavior breaks** — every assertion would detect a real regression, not just confirm the code ran. 5. **Are independent** — no test depends on the order or state of another. ## Workflow ### 1 — Detect the test stack Inspect the repo first: - Which framework? Look at `package.json` (`jest`, `vitest`, `mocha`), `pyproject.toml` / `pytest.ini`, `go.mod`, `Cargo.toml`. - Where do tests live? `__tests__/`, `test/`, `*.test.ts` next to source, `*_test.go`? - What conventions? `describe/it` vs `test()`, AAA vs given/when/then, fixture style, mocking library. Match what's there. Don't introduce a new framework just because you prefer it. ### 2 — Read the function like an