Borrowing it
Nothing to install: this file belongs to adamayoung/TMDb. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/adamayoung/TMDb/main/.claude/skills/integration-test/SKILL.mdgit clone --depth 1 https://github.com/adamayoung/TMDbWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/adamayoung/tmdb/integration-test)<a href="https://agentmods.dev/skills/adamayoung/tmdb/integration-test"><img src="https://agentmods.dev/badge/skills/adamayoung/tmdb/integration-test.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00087 | $0.00815 |
| Opus 5 | $0.00044 | $0.00407 |
| Sonnet 5 | $0.00017 | $0.00163 |
| Haiku 4.5 | $0.00009 | $0.00081 |
Grade A, and why
integration-test scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run integration 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
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.
A count is not evidence that your new test ran
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".
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 64 lines · 87 tokens per session scan A 58896868b4ad
integration-test is a skill published in the GitHub repository adamayoung/TMDb (177 stars, last pushed 6d ago), licensed Apache-2.0. It adds 87 tokens to every session and 815 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
swift-testing-expert
Expert guidance for Swift Testing: test structure, #expect/#require macros, traits and tags, parameterized tests, test plans, parallel execution, async waiting patterns, and XCTest migration. Use when writing new Swift tests, modernizing XCTest suites, debugging flaky tests, or improving test quality and…
peekie-attachments
Extract and list test attachments (screenshots, logs, blobs) from an Xcode .xcresult bundle via peekie attachments. Trigger when the user asks about attached files in a bundle — e.g. "extract failure screenshots from /tmp/Tests.xcresult to /tmp/out", "save attachments for a single test", "what's attached to my failing…
peekie-tests
Parse and format test results from an Xcode .xcresult bundle via peekie tests. Trigger when the user asks anything about test outcomes from a bundle — e.g. "did the tests pass in /tmp/Tests.xcresult?", "show me failing tests from this build", "what tests failed?", "which tests were skipped?", "give me a JSON list of…
peekie-coverage
Extract code coverage from an Xcode .xcresult bundle via peekie coverage. Trigger when the user asks about coverage from a bundle — e.g. "what's the coverage in /tmp/Tests.xcresult?", "coverage per module please", "covered vs total lines for each file", "give me overall coverage as a percentage I can print in CI", "is…
roundtrip-radar
Per-journey code audit tracing data through complete user flows for bugs, data safety, performance, and round-trip completeness. Discovers workflows, audits each end-to-end, rolls up cross-cutting issues, and supports natural-language flow tracing. Triggers: "roundtrip audit", "trace user journey", "/roundtrip-radar".
verify
Drive CrowTelemetry's OTLP ingest end-to-end — boot the real receiver, POST OTLP JSON with curl, inspect the SQLite db.