Skip to content
Back to skills

Failure Triage

ASecurity

Use when confronted with an unknown failure in CI or production, before committing to a deep debugging approach.

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 6, 2026
ai-agentsgobashdebugginggit

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add yeaight7/agent-powerups --skill failure-triage --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Failure Triage?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Failure Triage
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/yeaight7-failure-triage-agent-powerups/badge)](https://www.skillsdirectory.com/skills/yeaight7-failure-triage-agent-powerups)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: failure-triage
description: Use when confronted with an unknown failure in CI or production, before committing to a deep debugging approach.
---

## 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

1. **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

2. **Locate the origin.** Scan the stack trace. Ignore framework/library internals. Find the highest frame that belongs to the *first-party application code*:

   ```bash
   # surface first-party frames (adjust the path filter to the repo layout)
   grep -n "src/" stacktrace.txt | head -20
   ```

3. **Check recent changes.** Most bugs are in the newest code:

   ```bash
   git log -n 5 --oneline
   git diff HEAD~5 --stat
   git log -n 10 --oneline -- <suspect-file-or-dir>
   ```

4. **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 log` is the cheapest triage tool available; check it before anything expensive.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…