Triage issue

Skill aneja5/forge-skills/skills/triage-issue

An assembly line for AI software development. 35 skills, 11 agent personas, 29 commands. From raw idea to shipped code.

Install

npx -y skills add aneja5/forge-skills --skill triage-issue

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 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.

What its author says it does

Copied from the file, not written here

Use when user reports a bug, wants to file an issue, mentions "triage", when investigating a production problem before fixing it, when planning a fix that needs a TDD-shaped GitHub issue, or when a bug needs root-cause analysis before assignment.

SKILL.md

4.2 KB, 923 tokens by cl100k_base, as published. Nobody here has run it

Triage Issue

Overview

Investigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. Exploration-first — no guessing. The issue is written in terms of behaviors and contracts, not file paths or line numbers, so it stays useful after refactors.

When to Use

User reports a bug or unexpected behavior
User wants to file a GitHub issue before implementing a fix
User says "triage", "investigate", or "what's causing this"
Bug needs a structured fix plan before work begins

When NOT to Use

Root cause is already known — go straight to debugging-and-recovery
No GitHub repo exists — you can't create the issue
The problem is a missing feature, not broken behavior — use spec-driven-development

Common Rationalizations

Thought	Reality
"I know what's wrong, I'll skip investigation"	You know the symptom. Cause is found by tracing, not guessing
"The fix is obvious — no need for a plan"	Obvious fixes skip TDD cycles and reintroduce the bug
"I'll reference the file and line in the issue"	File paths rot — write behaviors and contracts, not pointers
"I'll ask the user for more details before investigating"	Codebase exploration answers more than follow-up questions

Red Flags

Issue body names specific file paths or line numbers (stale after any refactor)
Root cause described as "it just wasn't working" — that's a symptom, not a cause
TDD fix plan has more than 6 RED/GREEN cycles (not a vertical slice — decompose)
Fix plan describes internal state changes, not observable behavior changes

Core Process

1. Capture the problem

Get a brief description from the user. If none provided, ask ONE question: "What's the problem you're seeing?" Do NOT ask follow-up questions — start investigating immediately.

2. Explore and diagnose

Use the Agent tool with subagent_type=Explore to find:

Where the bug manifests (entry points, UI, API responses)
What code path is involved (trace the flow)
Why it fails (root cause, not symptom)
What related code exists (similar patterns, tests, adjacent modules)

Look at: related source files, existing tests, recent changes (git log on relevant files), error handling in the code path, similar patterns that work correctly.

3. Identify the fix approach

Based on investigation, determine:

The minimal change to fix the root cause
Which modules/interfaces are affected
What behaviors need to be verified via tests
Whether this is a regression, missing feature, or design flaw

4. Design TDD fix plan

Ordered list of RED-GREEN cycles. Each is one vertical slice:

RED: A specific test that captures the broken/missing behavior
GREEN: The minimal code change to make that test pass

Rules: tests verify behavior through public interfaces, not implementation details. One test at a time. Each test must survive internal refactors.

5. Create the GitHub issue

Use gh issue create. Do NOT ask the user to review before creating — create it and share the URL.

<issue-template>

Problem

[What happens (actual) vs what should happen (expected). How to reproduce.]

Root Cause Analysis

[Code path, why it fails, contributing factors — no file paths or line numbers]

TDD Fix Plan

RED: Write a test that [describes expected behavior] GREEN: [Minimal change to make it pass]
...

REFACTOR: [Any cleanup needed after all tests pass]

Acceptance Criteria

Criterion 1
All new tests pass
Existing tests still pass

</issue-template>

After creating: print the issue URL and a one-line root cause summary.

Verification

Codebase explored before drawing conclusions
Root cause identified (cause, not symptom)
TDD fix plan uses observable behaviors, not implementation details
Issue body contains no file paths or line numbers
Each RED/GREEN cycle is a vertical slice
GitHub issue created and URL returned to user

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 923 tokens

Counted across 839 of the 1,149 authors here whose files we hold, read 2026-08-07

Investigate root cause before proposing any fixin 102 of 839, across 67 files
Read error messages completelyin 89 of 839, across 49 files
Create a failing test case before fixingin 84 of 839, across 46 files
Reproduce the issue consistentlyin 82 of 839, across 41 files
Change one variable at a timein 82 of 839, across 42 files
Check recent changesin 74 of 839, across 36 files
Write the regression test before fixingin 74 of 839, across 40 files
Fix the root cause not the symptomin 60 of 839, across 45 files
Implement a single fix at a timein 59 of 839, across 20 files
Trace data flow backward to the sourcein 50 of 839, across 20 files
Remove all debug instrumentationin 49 of 839, across 13 files
Form a single hypothesisin 48 of 839, across 18 files

Said here and by no other author read

Explore the codebase before drawing conclusions
Write TDD fix plans using observable behaviors not implementation details
Keep each fix plan under six red-green cycles
Do not ask follow-up questions before investigating
Exclude file paths and line numbers from the issue body

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.