chore: add agent skills for unit and API e2e tests (CM-968)

.claude/skills/write-api-e2e-tests/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: write-api-e2e-tests
+description: >
+  Write API end-to-end tests. Use when adding or changing API endpoints, or when
+  the user asks for API e2e, smoke, or contract tests.
+allowed-tools: Bash, Read, Glob, Grep, Edit, Write, AskUserQuestion
+---
+
+# Write API end-to-end tests
+
+Write or extend API end-to-end tests.
+
+## When to use
+
+- New or changed API endpoints.
+- User asks for API e2e, smoke, or contract tests.
+- Critical API behaviour needs regression coverage.
+
+## When not to use
+
+- Domain or SQL correctness → use `write-unit-tests`.
+- Temporal, OpenSearch, or other eventual side effects outside the documented API e2e scope.
+- Creating a new testing framework or suite style.
+
+## Source of truth
+
+Read before writing. Follow these ADRs and existing suite structure; do not
+invent a parallel testing style.
+
+- [ADR-0012](docs/adr/0012-api-e2e-test-architecture.md) — runtime, isolation, supported surfaces, scope, and assertions.
+- [ADR-0013](docs/adr/0013-api-e2e-test-suite-design.md) — suite organisation, helpers, and conventions.
+
+Current default entrypoint:
+
+- `.github/scripts/public-api-e2e-tests.sh`
+
+## Workflow
+
+1. Identify the API surface. Default to Public API unless the user specifies otherwise.
+2. Read ADR-0012 and ADR-0013.
+3. Add or extend the appropriate suite and register it if required.
+4. Run the affected suite locally and fix failures until green.
+5. If required fixtures cannot be created through the API, prefer testing supported scenarios and explain any coverage gaps instead of seeding the database directly.
+6. Suggest production testability improvements only when they make the API easier to test, and ask before changing production code.
+
+## Run
+
+Export the environment variables required by the suite entrypoint.
+
+```bash
+bash .github/scripts/public-api-e2e-tests.sh
+```
+
+Refer to ADR-0012 and the suite entrypoint for environment setup, reset behaviour,
+and local development workflows.
+
+## Guardrails
+
+- Keep tests focused on observable API behaviour.
+
+## Output
+
+- Suites and cases added
+- How to re-run
+- Coverage gaps, if any
+- Optional testability suggestions

.claude/skills/write-unit-tests/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: write-unit-tests
+description: >
+  Write focused Vitest unit tests. Use when adding or improving unit tests for
+  business logic, data access, common services, or other server modules.
+allowed-tools: Bash, Read, Glob, Grep, Edit, Write, AskUserQuestion
+---
+
+# Write unit tests
+
+Write focused unit tests that follow the project's testing conventions.
+
+## When to use
+
+- User asks to add or improve unit tests.
+- A change touches high-blast-radius logic (affiliations, merges, identity resolution, timelines, inference).
+- A PR needs confidence in a pure or Postgres-backed function.
+
+## When not to use
+
+- Public or HTTP contract coverage → use `write-api-e2e-tests`.
+- Temporal, Redis, or OpenSearch fixtures (not available yet).
+- Broad "increase coverage %" requests without a clear unit under test.
+
+## Source of truth
+
+Read before writing. Follow these ADRs; do not invent a parallel testing style.
+
+- [ADR-0008](docs/adr/0008-how-we-write-unit-tests.md) — scenarios, `describe` grouping, assertions, mocking, and shared setup.
+- [ADR-0007](docs/adr/0007-test-factory-primitives-and-defaults.md) — factories and defaults.
+
+## Workflow
+
+1. Identify the unit under test (one function or decision path). Colocate tests as `<file>.test.ts`.
+2. Read ADR-0007 and ADR-0008. Skim the nearest existing test in the same area if one exists.
+3. Compose fixtures using `@crowd/test-kit` (`withQx` for Postgres-backed tests; factories and opt-in defaults per ADR-0007).
+4. Write focused scenarios following ADR-0008 (grouping, naming, assertions, and mocking).
+5. Run the affected tests and fix failures until green.
+6. If production code is difficult to test, suggest a small testability seam and ask before changing production code.
+
+## Run
+
+Start the test database when needed:
+
+```bash
+./scripts/cli scaffold up-test
+```
+
+Run a focused test file:
+
+```bash
+pnpm test:server -- path/to/file.test.ts
+```
+
+Optional:
+
+```bash
+pnpm test:changed
+pnpm test:watch -- path/to/file.test.ts
+```
+
+## Guardrails
+
+- Prefer critical behaviours over trivial getters, setters, and thin wrappers.
+- Keep production behaviour unchanged unless the user explicitly asks for a testability improvement.
+
+## Output
+
+- Scenarios covered
+- How to re-run
+- Optional testability suggestions