Run all TMDb unit tests (Swift Testing, the TMDb test plan). Use after code changes and before a PR to verify unit tests pass — delegates the run to the tooling-runner agent (Haiku) and returns total/passed/failed counts plus each failure as Suite/test with file:line. For the live-API suite, use /integration-test.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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
testtarget: 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
testtarget scoped toSuiteName/testName. Package directory:<your current working directory, absolute>
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".
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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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.
日本語の概要は準備中です。原文の説明を表示しています。
Implement features and fix bugs test-first, the Canon TDD way (test list → one test → make it pass → refactor → repeat). Use when implementing any new feature, endpoint, model, or method, fixing a bug, or executing a plan — write the test list and a failing test BEFORE production code.
日本語の概要は準備中です。原文の説明を表示しています。
Capture durable, project-specific learnings from the work just done into the knowledge/ base — gotchas, implementation quirks, things looked up or web-searched, live-API behaviours, and design decisions (as ADRs). Use before opening a PR (it runs automatically in /deliver), or any time you've learned something worth remembering. Records only non-obvious, reusable facts; skips anything already in the repo, CLAUDE.md, or git history.
日本語の概要は準備中です。原文の説明を表示しています。
Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub release. Presents the version (with its reasoning) and the full notes for approval and STOPS; nothing is tagged or published until you say go.
日本語の概要は準備中です。原文の説明を表示しています。
Take a plan all the way to a ready-to-merge pull request — review the plan (scaled to risk), implement it test-first, code-review and fix, run the CI gate, open the PR, and watch it green. Use after you have an approved plan (from plan mode, or the Plan agent); pass `issue <n>` to deliver a specific GitHub issue you name, or `next` to take the top startable issue off the project board's Ready column — either way it re-verifies, claims and plans the issue first. Invoking it with a plan already in hand is itself plan approval — it then runs autonomously to a single hard stop: ready-to-merge.
日本語の概要は準備中です。原文の説明を表示しています。
Diagnose a failing CI workflow run (lint, markdown lint, build, or unit tests) — identify which job failed, the cause, and a concrete fix
日本語の概要は準備中です。原文の説明を表示しています。