ci failure triage

The problem

CI logs with dozens of failing tests are overwhelming. Finding the actual root cause in a wall of stack traces is slow, manual work that delays developers from starting the fix.

What it does

• Groups identical failures by normalizing messages to remove noise like timestamps, memory addresses, and UUIDs.
• Ranks failure clusters by frequency to show which bug accounts for the most noise.
• Identifies the specific line in your project code where the error originated, skipping internal library frames.
• Supports major runners including pytest, Jest, Vitest, Go test, mypy, tsc, and eslint.
• Provides a clear recommendation on which specific failure to fix first to clear the build.

Frameworks & tools

Python 3.8+, pytest, Jest, Vitest, Go, Mypy, TypeScript, and ESLint.

Why this beats prompting it yourself

Raw LLMs struggle to maintain focus when processing thousands of lines of log data and often fail to correctly normalize variable data like hex addresses. This skill uses a deterministic clustering logic that ensures every single failure is accounted for without hallucinating connections or missing edge cases in large files.

Use cases

• Triaging a red build with 50+ failures after a major refactor.
• Distinguishing between a flakey test and a genuine environment-wide outage.
• Quickly identifying which ESLint or TypeScript rule is causing the most friction across a codebase.
• Gating pipeline steps using the standard exit code logic.

Known limitations

Normalisation might occasionally group two unrelated bugs if they produce identical assertion messages. It requires a text-based log file or piped stdin to function.