triage-issues

Categorize, verify, and convert incoming bug reports and feature requests into agent-ready briefs.

1|Updated Jul 13, 2026
One-click install
npx skills add https://github.com/dineshrevunuru/SuperSkills --skill triage-issues-dineshrevunuru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: triage-issues
Source: https://github.com/dineshrevunuru/SuperSkills/tree/main/triage-issues
Command: npx skills add https://github.com/dineshrevunuru/SuperSkills --skill triage-issues-dineshrevunuru

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Incoming bug reports and feature requests often arrive vague, unverified, or misframed, and acting on them directly wastes effort on bugs that never reproduce or specs built on a reporter's guess. This Skill moves each item through a lightweight state machine — categorize, verify the claim actually holds, then write a durable agent-ready brief — so nothing gets built before it is confirmed real. ## Core Features & Use Cases - Categorize and verify before acting: Classify each item as bug or enhancement, run one lightweight reproduction to confirm the claim, and route it to states like needs-info, ready-for-agent, ready-for-human, or wontfix. - Agent-ready brief writing: Produce behavioral, durable specs with verified current behavior, desired behavior, key interfaces, independently testable acceptance criteria, and explicit out-of-scope lines that an AFK agent can build from cold. - Solo and tracker modes: Default to a lightweight local-list flow for solo backlogs, mode-switching up to GitHub labels, external PR discovery, and an out-of-scope dedup knowledge base only when a shared tracker exists. - Use Case: A beta tester texts "the app is broken, I can't book anything." Instead of writing "fix the booking error," you reproduce the issue, discover it only fails when a slot is taken between selection and confirm, and hand off a scoped, testable brief. ## Quick Start Triage this bug report from my beta backlog: verify whether it actually reproduces, then write an agent-ready brief for it.

Frequently Asked Questions about triage-issues

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a backlog of bug reports and feature requests?

Run each item through a three-step pipeline: categorize it as bug or enhancement, verify the claim by reproducing it yourself, then apply a state such as ready-for-agent, needs-info, or wontfix. For a full backlog, bucket items oldest-first and surface what needs attention rather than triaging everything at once.

How do I write a brief an AI agent can build from?

Write a behavioral spec with verified current behavior, desired behavior, key interfaces described as seams rather than file paths, independently testable acceptance criteria, and an explicit out-of-scope line. Verify the bug reproduces first so the brief names the real code path, not the reporter's guess.

Should I verify a bug report before writing a fix spec?

Yes. Writing a brief from an unverified claim means an agent may burn a session on a bug that never reproduced or on the wrong bug hiding under the reporter's framing. One lightweight reproduction confirms the real code path and produces a far stronger, testable scope.

When should I use GitHub labels versus a simple local list for triage?

Use a simple local list by default for solo work like client messages or beta feedback, with no labels or tracker ceremony. Escalate to GitHub labels, external PR discovery, and an out-of-scope dedup knowledge base only when the backlog lives in a shared tracker other people act on.

What is the difference between triaging a bug and diagnosing it?

Triage decides whether to act: it runs one lightweight reproduction to confirm the bug is real and writes a scoped brief. The full diagnose loop of reproduce, minimize, hypothesize, instrument, and fix is a separate discipline that receives the brief triage produces.

How do I handle duplicate or already-rejected feature requests?

Search the codebase by concept to check if the feature is already built, and check prior decisions for matching rejections before triaging. Point already-built requests to where the feature lives, and record only genuine rejections so the dedup record is not poisoned by false negatives.