菜单
Diagnose a failing CI workflow run (lint, markdown lint, build, or unit tests) — identify which job failed, the cause, and a concrete fix
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | diagnose-ci-failure |
| description | Diagnose a failing CI workflow run (lint, markdown lint, build, or unit tests) — identify which job failed, the cause, and a concrete fix |
The CI workflow (.github/workflows/ci.yml) gates every PR and the merge to
main. Unlike the live-API integration suite, a CI failure is almost always
caused by the change under review — a lint violation, a compile warning/error,
a broken unit test, or a Linux-portability gap. Start from the diff, not from
"maybe it's flaky".
CI fans out into four real jobs (plus a ci gate job that only aggregates
results). The diagnosis differs per job, so this skill is a router: identify
the failing job, then follow the matching reference file for that job's causes,
fixes, and local-reproduction command.
Wrong suite? If the Integration workflow (the live-API suite from
integration.yml) failed — not a CI job — use/diagnose-integration-failureinstead. It leads with the opposite assumption: a scheduled/live-API failure is usually backend or data drift, not your change.
Lint, Lint Markdown, Build and Test
(macOS), or Build and Test (Linux). Don't guess the cause before you know
the job.-warnings-as-errors / --Werror
— a deprecation or unused-binding warning is a real failure./lint,
/build-for-testing, /test, make lint-markdown, make build-linux).file:line.Use the first that applies:
origin
remote): mcp__github__actions_list method list_workflow_runs
(resource_id: ci.yml, workflow_runs_filter: { branch: <branch> }), then
mcp__github__get_job_logs (run_id: <id>, failed_only: true,
return_content: true). (mcp__github__pull_request_read method
get_check_runs also shows which job is red.) Headless / no MCP:
gh run list --workflow CI --branch "$(git branch --show-current)" --limit 1,
then gh run view <id> --log-failed.github-actions format, so
the failing lines are GitHub ::error:: annotations carrying file:line —
read those first.Once you know which job failed:
swiftlint --strict / swiftformat --lint)?
└─ references/lint.md — style/format violations + the version-drift gotchamarkdownlint)?
└─ references/markdown.md — README / DocC markdown rulesreferences/build.md — compile errors and --Werror warningsreferences/unit-tests.md — failing Suite/test, fixture/model mismatchreferences/linux.md — Apple-only API gating, Foundation differencesSymptom → next move:
error: … is unavailable / cannot find … in scope, Linux job only → references/linux.mdwarning: … treated as error → references/build.mderror: from swiftc on macOS build → references/build.mdSuite/test recorded a failure / #expect failed → references/unit-tests.mdkeyNotFound, valueNotFound) → references/unit-tests.mderror: … (rule_id)) → references/lint.mdsuperfluous_disable_command on unchanged code → references/lint.md (suspect version drift)--lint non-zero) → references/lint.mdMD0xx violation → references/markdown.mdProduce exactly these three sections (keep it under ~150 words; if the caller asked for a file, write the markdown there and nothing else, otherwise reply directly):
Summary: which job and step failed, and the specific error (rule /
file:line / failing Suite/test).
Cause: the root cause, tied to a changed file where possible.
Fix: the concrete next step from the relevant reference file.
| File | Failing job | Covers |
|---|---|---|
references/_index.md | — | Navigation index by symptom |
references/lint.md | Lint | SwiftLint --strict, SwiftFormat --lint, pinned versions, drift |
references/markdown.md | Lint Markdown | markdownlint on README + DocC .md |
references/build.md | Build and Test (build step) | compile errors, --Werror warnings, release build |
references/unit-tests.md | Build and Test (test step) | Swift Testing failures, JSON fixture/model mismatch |
references/linux.md | Build and Test (Linux) | Apple-only API gating, Foundation portability |
Take the current 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 (e.g. from /plan) and want the rest of the feature pipeline run end-to-end. Invoking it is itself plan approval — it then runs autonomously to a single hard stop: ready-to-merge.
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.
Review the working-tree changes (vs main) for correctness, concurrency, architecture, testing, and API/doc issues — following .github/CODE_REVIEW.md — and return a severity-graded report. Scales the machinery to the diff size: a single code-reviewer agent for a small change, or a fan-out-and-verify Workflow for a large/multi-unit one. Produces findings; it does not apply fixes (the caller does).
Watch the current branch's PR — reply to and resolve review threads, fix failing checks, and optionally merge when ready
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.
Compile the TMDb Swift package for the current platform to check it builds. Use to verify code compiles after changes — delegates the build to the tooling-runner agent (Haiku) and returns a concise pass/fail + errors-as-file:line summary, keeping logs out of context. To also compile the test targets, use /build-for-testing.