Run the TMDb integration tests against the live TMDb API (the Integration test plan; requires TMDB_API_KEY/USERNAME/PASSWORD). Use before a PR, or after model/fixture changes, to validate against real API responses — delegates to the tooling-runner agent (Haiku) and returns counts + failures, distinguishing genuine failures from transient live-API/env issues. For mocked unit tests, use /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
integration-testtarget: the TMDb live-API integration 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 (see .claude/agents/tooling-runner.md).
Use your actual CWD — run pwd if you are not certain of it.
Relay its report — it distinguishes genuine assertion failures from transient live-API issues (429/timeout/network) and env/precondition failures. 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-integration-test.log) rather than re-running. After fixing
the issues, re-invoke this skill to re-check. To attribute a failure
(live-API/backend drift vs a regression in your change), use
/diagnose-integration-failure.
The log is an aggregate — it names failures only, never the tests that
passed, so passed_tests: 310 looks the same whether a test you just added ran
or never compiled into the bundle. The runner reports Names observed: no for a
full run and is instructed not to claim any passing test by name; treat such a
claim as unfounded, and a rising total as no evidence about an individual test.
This bites hardest here, because a new integration test is usually the only live proof that a fix works. When it matters, follow up with a scoped run and read the names:
swift test --skip-build --scratch-path .build --filter 'SuiteName'
Seconds against an already-built bundle, and it distinguishes "the live suite is green" from "my new test reached the API and passed".
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>" integration-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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.