New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

TMDb Integration Failure Fixer

by adamayoung in adamayoung/TMDb

Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to.

Apache-2.0Auto-check passedDevOps & Cloud

Install TMDb Integration Failure Fixer

skills CLI
$ npx skills add adamayoung/TMDb --skill fix-integration-failures -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install adamayoung/TMDb fix-integration-failures --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/adamayoung/TMDb.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/fix-integration-failures .claude/skills/fix-integration-failures && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
fix-integration-failures
GitHub stars
178
Token cost
~2.7k tokens
SKILL.md length
1,492 words
Files
1
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to.

  • Works in 6 steps: Find the failing run → Diagnose → Transient? Re-run first → …
  • Diagnosing why the scheduled TMDb Integration workflow failed
  • SKILL.md covers Agent behaviour contract, 0. Find the failing run, 1. Diagnose and 2. Transient? Re-run first, plus 5 more sections
  • Calls gh, git and make

What it does

The weekly Integration workflow runs on a Sunday schedule as a live-API canary: since nothing in the code changed, a failure there means the live TMDb API drifted, a test's assumed data went stale, or a transient error or rate limit hit. This skill is specifically for a failure not already attached to an open feature PR, such as the scheduled run, a manual dispatch, or a failure sitting on main; a failure tied to an open PR belongs to a separate /watch-pr or /fix-pr-checks flow instead.

It never edits main directly; any fix lands on its own fix/<slug> branch through a PR. Diagnosis always runs first through /diagnose-integration-failure rather than guessing, and a shape-change or drifted-data conclusion must come with an observed line showing the actual live call that saw today's response; if that line is missing, the diagnosis is re-run exactly once, and if it is still missing the cause is treated as unverified and reported as such in the PR body and in claude-analysis.md, never described as confirmed drift.

A re-run of the workflow is the cheap test for telling a transient failure from a real one, and only a cause that survives a re-run, or a clear data or shape drift, gets a PR opened for it. A real fix to the model or decoder then follows a failing-test-first TDD approach, and whether the resulting PR auto-merges once green depends on whether merge was passed as an argument to the skill.

When your agent uses it

  • Diagnosing why the scheduled TMDb Integration workflow failed
  • Deciding whether a CI failure is a transient blip or a real API drift
  • Fixing a live-API test failure on main with a proper PR, not a direct push

Example prompts

  • “Diagnose and fix this week's failed Integration run.”
  • “/fix-integration-failures merge”
  • “Is this Integration failure transient, or did the TMDb API actually change?”

Requirements

  • A CI environment running the Integration workflow
  • The /diagnose-integration-failure skill

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Find the failing run
  2. Diagnose
  3. Transient? Re-run first
  4. Fix the real cause on a branch off main
  5. Open the PR (and optionally merge)
  6. Report

What it can do on your machine

Read from SKILL.md and the folder at commit a3f1311. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git
    • make
    • swift

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

TMDb Integration Failure Fixer loads about 2.7k tokens when it runs. Until then it costs about 76 tokens; SKILL.md has 1,492 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~76
When it runs · the whole SKILL.md, loaded when a task matches
~2.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from adamayoung/TMDb at commit a3f1311, republished under its Apache-2.0 licence (© adamayoung). 1,492 words, ~2,708 tokens.

Download SKILL.mdSave it as .claude/skills/fix-integration-failures/SKILL.md (or your agent's skills folder).
name
fix-integration-failures
description
Diagnose and fix a failing scheduled (or standalone) TMDb Integration workflow run — re-run transients, or fix real drift on a branch off main, then PR and (optionally) merge. Use for the weekly Sunday Integration cron failure, or any red Integration run not tied to an open PR.

Fix Integration workflow failures

The Integration workflow (.github/workflows/integration.yml) runs the live-API integration suite on a weekly schedule (cron: '0 0 * * 0' — Sunday 00:00 UTC), as well as on PRs/pushes. The scheduled run is a live-API canary: nothing in the code changed, so a failure means the live TMDb API drifted, a test's assumed data went stale, or a transient error/rate-limit hit. This skill takes such a failure from red run → green main: diagnose it, then either re-run a transient or fix the real cause on its own branch and open (and optionally merge) a PR.

Scope. This is for an Integration failure not attached to an open feature PR — the scheduled canary, a workflow_dispatch, or a failure on main. When a failing Integration check belongs to an open PR, /watch-pr and /fix-pr-checks own that; they delegate the pre-existing/unrelated case back here (fix on a branch off main), which is exactly this skill's job.

Mode — check the arguments passed to this skill (shown at the end). If they include merge (e.g. /fix-integration-failures merge), auto-merge the fix PR once green. Otherwise stop at ready-to-merge and hand off (default).

Agent behaviour contract

  1. Never edit main directly (CLAUDE.md). Any fix lands on a fix/<slug> branch off main, via a PR.
  2. Diagnose before fixing. Always run /diagnose-integration-failure first; let its ranked cause drive the fix. Don't guess. Check the diagnosis carries its evidence. A shape-change (cause 1) or drifted-data (cause 2) conclusion must arrive with an observed: line — the live call that saw today's response. Missing one, re-run the diagnosis once asking for it. Still missing → treat that cause as unverified: proceed, but say so in the PR body and in claude-analysis.md, and never describe it as confirmed drift. Re-run once, not in a loop — a headless run has no MCP and legitimately cannot observe (it reports observed: unavailable (headless)), so an unbounded retry would spin forever. Transient (cause 3) and in-diff regression (cause 0) carry no observed: line by design; do not demand one.
  3. Distinguish transient from real. A re-run is the cheap test. Only open a PR for a cause that survives a re-run (or is clearly a data/shape drift).
  4. Test-first for real fixes. A model/decoder fix follows canon-tdd (failing unit test + fixture, then the fix). A drifted-assertion fix updates the integration test to assert behaviour, not a brittle exact value.
  5. The gate is make ci. Never open the PR until it passes locally.
  6. Don't paper over a real regression. If the cause is a genuine library bug (not drift/transient), fix it properly or stop and report — never just relax a test to hide it.

0. Find the failing run

Interactive vs headless. The steps below use the GitHub MCP (mcp__github__*, owner/repo from the origin remote). When this skill runs headless from integration-failure.yml — a CI runner, where the user-scoped MCP is not mounted — use the gh equivalents instead (given inline at each step and in Running headless below); that path stays 100% gh/git.

Find the failing run with mcp__github__actions_list method list_workflow_runs (owner/repo from origin, resource_id: integration.yml, workflow_runs_filter: { event: schedule, status: completed }). The status enum has no failure value, so filter the results to conclusion == "failure" yourself.

  • Prefer the most recent schedule (or workflow_dispatch) run on main.
  • Note its run id and event (sets the cause ranking).
  • No failing run → report "Integration is green, nothing to fix" and stop.
  • Headless: gh run list --workflow Integration --status failure --limit 5 --json databaseId,event,headBranch,conclusion,createdAt,displayTitle.

1. Diagnose

Invoke /diagnose-integration-failure, handing it the run id (it fetches the failed-job logs — via mcp__github__get_job_logs, or gh run view --log-failed when headless). It returns the three-section analysis — Summary, Likely cause (ranked; for a scheduled run it leads with backend/data drift, not a code regression), and Suggested fix. Use that ranking to choose the path below.

2. Transient? Re-run first

If the diagnosis points to case 3 (HTTP 429 / rate-limit, a timeout near the 30-min cap, or a truncated log with no assertion failure):

Re-run the failed jobs with mcp__github__actions_run_trigger method rerun_failed_jobs (owner/repo from origin, run_id: <id>), then block on the re-run with gh run watch <run-id> (the MCP has no blocking-wait equivalent). After it returns, re-read the conclusion with mcp__github__actions_get method get_workflow_run (resource_id: <id>) — don't trust the rerun call to surface it.

bash
gh run watch <run-id>   # blocking wait — kept on gh
  • Green on re-run → it was transient. Report and stop; no PR needed.
  • Fails the same way again → treat as deterministic; go to §3.
  • Headless: gh run rerun <run-id> --failed then gh run watch <run-id>.

(The integration client already retries 429/5xx with backoff, so a true transient that survives a re-run is uncommon — a repeat failure is usually real drift.)

Show full SKILL.md (727 more words)Show less

3. Fix the real cause on a branch off main

Reproduce locally first to confirm and to get a fast edit loop. Branch off origin/main directly — never git checkout main first. This is worktree-safe: when this skill is invoked from a /deliver worktree (via /watch-pr §1c), main is usually checked out in the main working copy, so git checkout main fails with fatal: 'main' is already used by worktree … — the same trap /pr documents for its rebase step:

bash
git fetch origin
git checkout -b fix/<slug> origin/main   # e.g. fix/<service>-integration-drift

Invoked mid-/deliver (from /watch-pr)? Don't create the fix branch in the deliverable's worktree — that switches its checkout away from the feature branch being watched. Give the fix its own worktree instead and work there, removing it once the fix PR merges:

bash
git worktree add .claude/worktrees/fix-<slug> -b fix/<slug> origin/main

Run the failing suite locally to reproduce — /integration-test (or swift test --filter <Suite>/<test>). Then fix per the diagnosis:

  • TMDb backend / response-shape change (a field added, removed, renamed, or now nullable) → fix the Swift model / CodingKeys / fixture test-first (canon-tdd): add a failing unit test + a JSON fixture matching the current live shape. The diagnosis's observed: line tells you which endpoint drifted and how, but it is a one-line summary (and unavailable headless) — not a response body, so it cannot source a fixture. Fetch the real response with mcp__tmdb__* and build the fixture from that, cross-checking the OpenAPI spec for the documented shape — then the model fix.
  • Stale assumed data (a test asserts a specific live title, count, id, date, or ordering that drifted) → relax the integration assertion to verify behaviour, not a brittle exact value (e.g. assert non-empty / a stable property / >= 1 rather than an exact count). Match the robust pattern already used by sibling tests in the same suite.
  • A genuine library regression → fix it properly, test-first. If it is not a quick, confident fix, stop and report — don't merge a workaround.

Verify: /integration-test green for the touched suite, then make ci (mandatory full gate). If make ci is red, fix and re-run — never PR on red.

4. Open the PR (and optionally merge)

Run /pr to commit (gitmoji), push, and open the PR (🐛/✅/♻️ as fits; make ci runs again inside /pr). Then run /watch-pr to drive it to ready:

  • Default (no merge) → /watch-pr watch-only: report the ready PR URL and stop for the user to merge.
  • merge → /watch-pr merge: squash-merge once green, then report.

/watch-pr handles any further transient flakes on the PR's own checks (re-run), so a live-API hiccup during CI won't strand the fix.

5. Report

Close with: the run id that failed, the diagnosis verdict (transient vs real), what you changed (file + one line) or that a re-run cleared it, the PR URL and whether it merged, and anything left for the user (e.g. a real regression you chose not to auto-fix).

Running headless (from integration-failure.yml)

When the Integration Failure Alert workflow invokes this skill on a scheduled failure, it runs non-interactively, so adapt:

  • A failing-step log is already at failure-log.txt in the workspace — diagnose from it (pass it to /diagnose-integration-failure); don't re-download logs.
  • Verify with the targeted suite + a build — swift build --build-tests and swift test --filter <Suite>/<test> — not the full make ci. The opened PR's own CI (ci.yml + integration.yml) is the authoritative gate; the alert job need not replicate the whole pinned-lint/xcsift toolchain.
  • Open the PR with git/gh directly (git checkout -b → commit → push → gh pr create), not /pr — /pr runs the full make ci, which the lightweight alert job can't satisfy. The format/lint hooks still reshape files on edit, so the diff stays clean.
  • Then STOP — do not run /watch-pr and do not merge (a human reviews it). Write the diagnosis to claude-analysis.md and, if you open a PR, its URL on one line to pr-url.txt.
  • If the cause is transient (re-run territory) or a genuine regression you should not auto-fix, open no PR — explain in claude-analysis.md so the alert issue carries it.

Guardrails

  • Never edit .github/workflows/* to force a check green, and never force-push, without surfacing to the user first.
  • One failing run can surface several drifted assertions — fix them together in one PR, but keep each change minimal and behaviour-preserving.
  • If the live API is broadly down/throttled (many unrelated suites failing fast), that's an outage, not a fix target — report and wait it out.
  • Capture anything durable you learned (a new live-API shape, a recurring drift) with /capture-knowledge before the PR, so the fixture/notes land with it.

Arguments: $ARGUMENTS

© adamayoung, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/fix-integration-failures of adamayoung/TMDb.

Open the folder on GitHubat commit a3f1311

Compare with similar skills

TMDb Integration Failure Fixer next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

TMDb Integration Failure Fixer compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
TMDb Integration Failure Fixer this skilladamayoung/TMDb178—~2.7kAutomated safety check: PassApache-2.0
Devops EngineerYikai-Liao/symusic1891 repos~1.5kAutomated safety check: PassMIT
JS Security Auditc0x12c/ai-toolkit106—~1.6kAutomated safety check: WarnNone
Release Itwondelai/skills2.4k—~4kAutomated safety check: PassMIT
Delivery Managerborghei/Claude-Skills886—~2.2kAutomated safety check: PassMIT
Cicd Playbookmohitagw15856/pm-claude-skills1.4k—~2.9kAutomated safety check: NotesMIT

Similar skills

  • Devops Engineer

    Yikai-Liao/symusic

    Creates Dockerfiles, configures CI/CD pipelines, writes Kubernetes manifests, and generates Terraform/Pulumi infrastructure templates.

    189 GitHub starsUsed in 1 repo~1.5k tokens
    DevOps & CloudAuto-check passed

  • JS Security Audit

    c0x12c/ai-toolkit

    Audit JS/TS projects against NPM Security Guidelines covering project setup, dependency hygiene, CI/CD pipeline, Dependabot, and incident response.

    106 GitHub stars~1.6k tokensUpdated 3 mo ago
    SecurityAuto-check: warnings

  • Release It

    wondelai/skills

    Build production-ready systems with stability patterns: circuit breakers, bulkheads, timeouts, and retry logic.

    2.4k GitHub stars~4k tokensUpdated 28 days ago
    DevOps & CloudAuto-check passed

  • Delivery Manager

    borghei/Claude-Skills

    Expert delivery management for release planning, deployment strategy, incident response, change management, SLA/error-budget tracking, and DORA metrics across continuous delivery pipelines.

    886 GitHub stars~2.2k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

  • Cicd Playbook

    mohitagw15856/pm-claude-skills

    Write a CI/CD pipeline playbook for a service or team. An agent skill from mohitagw15856/pm-claude-skills.

    1.4k GitHub stars~2.9k tokensUpdated yesterday
    DevOps & CloudAuto-check: notes

  • Docs Manuals

    jh941213/my-cc-harness

    Generate user manuals (Diátaxis) and operator manuals (runbooks, deployment guide, configuration reference, incident playbook).

    126 GitHub stars~916 tokensUpdated 2 mo ago
    DevOps & CloudAuto-check: notes

More from adamayoung/TMDb

All 18 skills in this repo

  • Swift DocC Documentation

    adamayoung/TMDb

    Writes and maintains DocC /// comments for the public API of the TMDb Swift package, following the project's summary patterns and comment structure.

    178 GitHub stars~2.6k tokensUpdated 5 days ago
    Auto-check passed

  • Implement Plan (Canon TDD)

    adamayoung/TMDb

    Drives an approved plan to completion test-first, deriving a Canon TDD test list, showing it before any code and stopping only when every item is written, passing and green.

    178 GitHub stars~4.5k tokensUpdated 5 days ago
    Auto-check passed

  • TMDb Backlog Triager

    adamayoung/TMDb

    Grooms the Backlog column of a GitHub project board by re-verifying each issue against current main, closing dead ones, promoting actionable ones to Ready and naming the decision the rest need.

    178 GitHub stars~5k tokensUpdated 5 days ago
    Auto-check passed

  • Canon TDD Workflow

    adamayoung/TMDb

    Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty.

    178 GitHub stars~1.3k tokensUpdated 5 days ago
    Auto-check passed

  • Capture Knowledge

    adamayoung/TMDb

    Records non-obvious lessons from a finished task, such as gotchas, API quirks and design decisions, into a project's knowledge folder before a pull request opens.

    178 GitHub stars~2.3k tokensUpdated 5 days ago
    Auto-check passed

  • Cut Release

    adamayoung/TMDb

    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…

    178 GitHub stars~3k tokensUpdated 5 days ago
    Auto-check passed

Works with

Categories

Questions about TMDb Integration Failure Fixer

What does TMDb Integration Failure Fixer do?

Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to. The weekly Integration workflow runs on a Sunday schedule as a live-API canary: since nothing in the code changed, a failure there means the live TMDb API drifted, a test's assumed data went stale, or a transient error or rate limit hit. This skill is specifically for a failure not already attached to an open feature PR, such as the scheduled run, a manual dispatch, or a failure sitting on main; a failure tied to an open PR belongs to a separate /watch-pr or /fix-pr-checks flow instead.

When should I use TMDb Integration Failure Fixer?

TMDb Integration Failure Fixer fits situations like: diagnosing why the scheduled TMDb Integration workflow failed; deciding whether a CI failure is a transient blip or a real API drift; fixing a live-API test failure on main with a proper PR, not a direct push.

How do I install TMDb Integration Failure Fixer in Claude Code?

Run `npx skills add adamayoung/TMDb --skill fix-integration-failures -a claude-code`. Or copy the skill folder (.claude/skills/fix-integration-failures in adamayoung/TMDb) into .claude/skills/fix-integration-failures in your project. Claude Code loads it when a task matches its description.

How do I install TMDb Integration Failure Fixer in Codex?

Run `npx skills add adamayoung/TMDb --skill fix-integration-failures -a codex`. Or copy the skill folder (.claude/skills/fix-integration-failures in adamayoung/TMDb) into .agents/skills/fix-integration-failures in your project. Codex loads it when a task matches its description.

Can I use TMDb Integration Failure Fixer in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add adamayoung/TMDb --skill fix-integration-failures -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/fix-integration-failures, .gemini/skills/fix-integration-failures, .github/skills/fix-integration-failures and .opencode/skills/fix-integration-failures in your project.

What does TMDb Integration Failure Fixer need to run?

Going by SKILL.md and its folder, TMDb Integration Failure Fixer needs the command-line tools its instructions call (gh, git, make and swift). Our summary lists: A CI environment running the Integration workflow; The /diagnose-integration-failure skill.

Does TMDb Integration Failure Fixer access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is TMDb Integration Failure Fixer safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does TMDb Integration Failure Fixer use?

TMDb Integration Failure Fixer is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does TMDb Integration Failure Fixer use?

About 2.7k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to TMDb Integration Failure Fixer?

Skills that share tags, products or a category with TMDb Integration Failure Fixer: Devops Engineer (Yikai-Liao/symusic, 189 stars), JS Security Audit (c0x12c/ai-toolkit, 106 stars), Release It (wondelai/skills, 2.4k stars) and Delivery Manager (borghei/Claude-Skills, 886 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains TMDb Integration Failure Fixer?

adamayoung (a GitHub user) maintains it in adamayoung/TMDb, which has 178 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 3, 2026.

Source: adamayoung/TMDb on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.