Run tests

Spawn the tooling-runner agent (Agent tool, subagent_type: tooling-runner — its Haiku pin, command recipes, and reporting contract live in .claude/agents/tooling-runner.md) with the one-line task:

Run the test target: the TMDb unit test suite. Package directory: <your current working directory, absolute>

Always include that directory line. The subagent does not reliably inherit your working directory, and without it a run inside a git worktree silently tests the main checkout instead — which reports "no matching test cases found" for suites that exist, or passes without ever seeing your changes (see .claude/agents/tooling-runner.md). Use your actual CWD — run pwd if you are not certain of it.

Relay its report. Do not run the tests yourself — unless the report is missing or malformed (below), which is the only sanctioned fallback.

If the report is unclear on a failure, read the log path it reports (.build/last-test.log) rather than re-running. After fixing the issues, re-invoke this skill to re-check. To re-check just the previously failing tests faster, ask the runner for a scoped run instead:

Run the test target scoped to SuiteName/testName. Package directory: <your current working directory, absolute>

A count is not evidence that your new test ran

The full-suite log is an aggregate — it names failures only, never the tests that passed. So passed_tests: 3105 looks the same whether a test you just wrote ran, or never compiled into the bundle. The runner is instructed not to claim otherwise and to report Names observed: no for a full run; treat any per-test claim about a passing test in a full-suite report as unfounded, and a rising total as no evidence about any individual test.

When it matters that a specific new test executed — a reproducer for the bug you are fixing, or a test guarding a branch that had none — ask for the scoped run above and read the test names in its output. That output does name each test. It costs seconds against an already-built bundle, and it is the difference between "the suite is green" and "the thing I wrote is doing its job".

If the report is missing or malformed

Judge the runner's report by shape, not by tone — the three outcomes are distinguishable and must be handled differently:

Report	What it means	What you do
Status: refused — …	A caller bug (wrong/missing package directory)	Surface it as a hard error and fix the call. Never fall back — the runner is telling you your invocation was unsafe.
Status: passed/failed	A real result	Relay it; act on any failures
No report, empty, or missing the Directory:/Status: lines	The subagent died — the run is void, not failed	Re-invoke once. If it voids again, run make -C "<the same absolute directory you passed the runner>" test directly via Bash

A fallback run is disclosed in your summary — say that you fell back and why. It is never silently treated as an ordinary result.