Compile the TMDb package AND all test targets (without running the tests) to catch test-code compile errors. Use after changing tests or shared code to check everything still builds — delegates to the tooling-runner agent (Haiku) and returns a concise pass/fail + errors-as-file:line summary. Differs from /build, which compiles only the library; to run the tests, use /test.
Scanned 9/20/2026
Install to Claude Code
npx -y skills add adamayoung/TMDb --skill build-for-testing --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Build For Testing?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/adamayoung-build-for-testing)More formats (shields.io, HTML) on the badges page.
---
name: build-for-testing
description: Compile the TMDb package AND all test targets (without running the tests) to catch test-code compile errors. Use after changing tests or shared code to check everything still builds — delegates to the tooling-runner agent (Haiku) and returns a concise pass/fail + errors-as-file:line summary. Differs from /build, which compiles only the library; to run the tests, use /test.
---
# Build for testing
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 `build-for-testing` target: compile the TMDb package and all test
> targets.
> 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
builds the main checkout instead (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 build 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-build-tests.log`) — or, inside Xcode, refresh diagnostics on
the flagged files — rather than re-running. After fixing the issues,
re-invoke this skill to re-check (a fresh subagent will rebuild).
## 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>" build-tests` 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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!