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.
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 desktop UI changes through the Chrome DevTools Protocol, a connection for controlling the running app. Reproduce the user’s actual steps and compare screenshots, measured state, and console errors to establish evidence before and after a fix.
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.