Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.
Diagnose a failing GitHub Actions run — find the first real error in the logs, tell a flake apart from a genuine failure, and identify the commit that broke it. Use when checks are red on a PR, a workflow failed, the build is broken, CI is flaky, or the user asks why a run failed or whether a failure is real.
Run score Not tested
See how to installThis skill investigates failed GitHub Actions runs and explains which job failed, what caused the failure, and whether it is related to the PR. It checks the earliest failing job and the first error in that job, looking past warnings and later errors that may hide the cause. It classifies the result as a code problem, an environment issue, an intermittent failure, or a failure that already existed before the change.
Use it when a PR check turns red, when a test passes after a rerun, or when you need to identify which change broke a build. It can compare the run with the base branch and inspect the PR’s changes to determine their connection to the failure. The report includes the relevant file and line, a link to the failing step, and a recommended next action.
The skill uses GitHub MCP tools to inspect run logs and PR information. A successful rerun alone is not treated as proof that the issue is fixed; intermittent test failures are still investigated.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
The goal is one sentence a human can act on: which job failed, on what, and whether it is this PR's fault. A screenshot of red checks is not a diagnosis.
List the run's jobs and take the earliest failing one. Later jobs usually fail because an earlier one did, and their logs are longer and more alarming — which is why people diagnose the wrong job.
Within that job, find the first error, not the last. Build tooling prints a summary at the end that names the last thing to fail; the first error is what actually broke.
Skip past the noise that always appears in failing logs: deprecation warnings, peer dependency notices, cache misses. None of them fail a build on their own.
Read the first error and put it in one of four buckets. They have different fixes and mixing them up wastes the most time.
| Bucket | Signal | What to do |
|---|---|---|
| Real failure | Assertion, type error, or compile error naming code this PR touched | Report the file and line |
| Environment | Network timeout, registry 5xx, disk full, runner image change | Re-run; if it persists, it is infrastructure |
| Flake | Timing, ordering, or concurrency; passes on re-run | See step 4 — do not stop at "re-run passed" |
| Pre-existing | Fails identically on the base branch | Not this PR's problem; say so explicitly |
Check pre-existing early. Fetch the most recent run on the base branch and compare the failing job. A PR blamed for a failure it inherited burns an afternoon.
For a real failure, connect the error to a diff. Get the PR's changed files and check whether the failing test or module is among them, or imports something that is.
If the failing area is untouched by the PR, the likely causes in order are: a dependency that moved, a merge with a base that already broke, or a genuine action-at-a-distance bug — which is the most interesting outcome and worth saying out loud.
A re-run that goes green proves the failure is intermittent. It does not prove the code is correct, and intermittent failures in CI are usually real race conditions that will also happen in production.
When you re-run and it passes, say that plainly, name the test, and check whether it has failed before on other PRs. A test that flakes on many PRs is a bug report about that test. Re-running until green and reporting success is how a real concurrency bug survives review.
Give the requester, in this order: the job, the first error with its file and line, the bucket from step 2, and what you recommend. Link the specific failing step, not the run — the run page makes them hunt for what you already found.
If the fix is small and obvious, say what it is. If the failure is pre-existing or infrastructural, say who needs to know, since the PR author usually cannot fix it.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.
Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.
Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.
Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.
Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.
Operate real desktop apps and browser windows by inspecting controls, clicking, typing, and checking the result after each action. Use it for settings changes, window arrangement, or verifying a complete workflow through the interface.