TMDb: Skill for Claude Code

Diagnose an integration-test failure

The TMDb integration tests hit the live TMDb API. The suite runs on three triggers — pull_request / push (where it gates the change) and schedule (the weekly live-API canary). Which run failed flips the most likely cause, so determine the trigger first (step 0):

• PR / push-triggered → this run is the gate for a code change, so a regression in the diff is a real candidate — weigh it alongside backend/data drift. This is the common case when invoked from /watch-pr or /fix-pr-checks.
• Scheduled → no code changed, so a regression is unlikely; the cause is almost certainly a backend change, drifted test data, or a transient error.

Wrong suite? If a CI check failed instead (lint, markdown, build, or unit tests from ci.yml), use /diagnose-ci-failure. That one leads with the opposite assumption: a CI failure is almost always caused by the change under review.

Agent Behaviour Contract

Do these by default, without being reminded.

1. Observe before you theorise. The log tells you what broke; only a live call tells you what the API returns today. So a cause that claims the API changed shape, or that a test's baseline drifted, must be backed by a live observation — mcp__tmdb__* (CLAUDE.md's standing instruction).
2. Every such cause carries an observed: line naming the tool called and the shape that came back. A cause with no observed: line is not reportable as ranked — demote it and mark it unverified. This is what makes the rule checkable by the consumer instead of trusting the diagnostician.
3. Only causes 1 and 2 can be observed. A transient/rate-limit (cause 3) and an in-diff regression (cause 0) cannot be confirmed by a live call — the endpoint being healthy now says nothing about either. Do not manufacture an observed: line for them; the requirement does not apply.
4. Never publish a secret. An observed: line records the tool and the shape, never a URL, command, or header carrying TMDB_API_KEY. TMDb takes api_key as a query item, so a pasted curl leaks it — and this analysis is published verbatim into an issue on a public repo. Say mcp__tmdb__movie_details(550) → runtime: Int, present, not the command.
5. Headless runs cannot probe. The scheduled integration-failure.yml job mounts no MCP. There, write observed: unavailable (headless) and mark the cause unverified — do not fall back to curl, which would put the key in the text (rule 4). Attended runs have the MCP; use it.