Failure triage
Use when confronted with an unknown failure in CI or production, before committing to a deep debugging approach.From its SKILL.md
npx -y skills add yeaight7/agent-powerups --skill failure-triageAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.4 KB, 533 tokens by cl100k_base, as published. Nobody here has run it
Purpose
Before diving deep into a stack trace or spending hours reproducing a bug, triage it to determine the blast radius, subsystem, and debugging approach. Do not start writing fixes until you have explicitly stated your triage hypothesis and confirmed the category.
When to Use
- A CI job or production system is failing and the cause is unknown
- A bug report arrives without a clear owner or subsystem
- Before choosing between deep debugging, bisecting, or reproduction work
Inputs
- The failure signal: stack trace, CI log excerpt, or error report
- The repo, for recent-change inspection
Workflow
-
Categorize the failure:
- Syntax/Build error — fails before running
- Logic error — runs, but produces wrong output
- Infrastructure/Environment error — network timeout, missing DB table
- Flaky/Non-deterministic error — fails sometimes
-
Locate the origin. Scan the stack trace. Ignore framework/library internals. Find the highest frame that belongs to the first-party application code:
# surface first-party frames (adjust the path filter to the repo layout) grep -n "src/" stacktrace.txt | head -20 -
Check recent changes. Most bugs are in the newest code:
git log -n 5 --oneline git diff HEAD~5 --stat git log -n 10 --oneline -- <suspect-file-or-dir> -
Formulate a hypothesis. State clearly: "I suspect this is an environment error caused by missing configuration, originating in
src/config.ts."
Output
- A stated category (build / logic / environment / flaky)
- The suspected origin file or subsystem
- An explicit triage hypothesis, before any fix is attempted
Verification
- Failure assigned to exactly one category
- Origin frame identified in first-party code, not framework internals
- Recent commits checked for related changes
- Hypothesis stated explicitly before any fix was written
Failure Modes
- Fixing before triaging — patching the symptom at the crash site while the root cause lives elsewhere.
- Blaming the framework — the highest first-party frame is the lead; library internals rarely are.
- Skipping recent history —
git logis the cheapest triage tool available; check it before anything expensive.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most debug triage skills give in 533 tokens
Counted across 1,020 of the 1,639 authors here whose files we hold, read 2026-09-06
- Find root cause before attempting any fixin 134 of 1020, across 118 files
- Create a failing test case before implementing a fixin 109 of 1020, across 95 files
- Read error messages and stack traces completelyin 102 of 1020, across 88 files
- Reproduce the issue consistently before investigatingin 90 of 1020, across 77 files
- Make the smallest possible change to test a hypothesisin 90 of 1020, across 76 files
- Trace data flow backward to find the sourcein 84 of 1020, across 70 files
- Form a single hypothesis before testingin 78 of 1020, across 64 files
- Implement only one fix at a timein 76 of 1020, across 63 files
- Question the architecture if three fixes failin 73 of 1020, across 59 files
- Add diagnostic instrumentation at component boundariesin 68 of 1020, across 56 files
- Compare broken code against working examplesin 68 of 1020, across 57 files
- Write a regression test before applying the fixin 62 of 1020, across 55 files
Said here and by no other author read
- Locate the first-party code origin
- Formulate an explicit triage hypothesis
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.