CI Failure Triage Lite

Stop wasting hours scrolling through thousands of lines of CI noise. When a pipeline turns red, this skill identifies the root cause by scanning for the first true error and decoding cryptic exit codes. It separates infrastructure meltdowns from genuine code regressions and flaky test suites.

What it does

• Exit code decoding translates codes like 137, 143, and 139 into human-readable causes like OOM kills or signal timeouts.
• Root cause isolation identifies the first point of failure in a log to distinguish the primary error from cascading fallout.
• Failure classification categorizes issues into infrastructure, network, dependency drift, or deterministic breakage.
• Evidence extraction quotes exact log lines and line numbers to support every diagnostic claim.
• Experiment recommendation suggests the single most cost-effective action to confirm a diagnosis.

How it works

1. Intake the raw CI log or a link to the failing job output from GitHub Actions, GitLab CI, or Jenkins.
2. Analysis of the failing step, exit codes, and the sequence of logs to find where the process first deviated.
3. Verdict generation providing a confidence score (High/Medium/Low) and a specific failure label.

Frameworks & tools

Works with any CI provider including GitHub Actions, GitLab CI, Jenkins, and CircleCI. Compatible with logs from any language or test framework, such as Jest, Pytest, Go test, or JUnit.

Why this beats prompting it yourself

Generic prompts often hallucinate based on the last few lines of a log, which are usually just cleanup errors. This skill follows a strict "first error" protocol and uses a pre-defined reference library for Unix exit signals, ensuring infrastructure issues aren't misdiagnosed as code bugs.

Use cases

• Triage intermittent failures to determine if a "flaky" test is actually a resource exhaustion issue.
• Debug environment drift when a build passes locally but fails in CI due to dependency resolution errors.
• Analyze OOM kills by identifying SIGKILL signatures in silent or truncated process logs.

Known limitations

Requires log text to function. Cannot access private repositories or execute code to verify fixes. One log cannot statistically prove flakiness on its own.