Bug triage

Skill zakelfassi/skills-driven-development/examples/webapp-starter/skills/bug-triage

Agents that learn by doing — and remember how they did it. A methodology for AI agents to create, evolve, and share reusable skills.

Install

npx -y skills add zakelfassi/skills-driven-development --skill bug-triage

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

17 stars17 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

Triage a bug report into an actionable GitHub issue with severity, reproduction steps, and assignment. Use when a bug is reported, when error logs need investigation, or when asked to file/triage an issue.

SKILL.md

2.7 KB, as published. Nobody here has run it

Bug Triage

Convert a bug report (user message, error log, Sentry alert) into a well-structured GitHub issue.

Inputs

Bug report (raw text, screenshot, error log, or Sentry URL)
Reporter (who reported it, if known)
Environment (production, staging, local)

Steps

Reproduce or verify
- Can you reproduce the bug from the report?
- If yes: document exact reproduction steps
- If no: flag as "needs-repro" and note what you tried

Classify severity

Severity	Criteria	Label
P0	Data loss, security, or full outage	`severity:critical`
P1	Major feature broken, no workaround	`severity:high`
P2	Feature broken, workaround exists	`severity:medium`
P3	Minor annoyance, cosmetic	`severity:low`

Identify the component
- Frontend / Backend / Infrastructure / Extension
- Add the corresponding label: area:frontend, area:backend, etc.

Write the GitHub issue

## Bug: [one-line description]

**Severity:** P[0-3]
**Environment:** [production/staging/local]
**Reporter:** [name or "internal"]

### What happened
[Clear description of the bug]

### Expected behavior
[What should have happened]

### Reproduction steps
1. ...
2. ...
3. ...

### Evidence
[Error logs, screenshots, Sentry link]

### Suspected cause
[If you have a hypothesis, state it]

File the issue

gh issue create --title "Bug: [description]" --body "[body]" --label "bug,severity:[level],area:[component]"

Assign if obvious
- If the suspected cause points to a clear owner, assign them
- If not, leave unassigned (triage meeting will handle it)

Conventions

Bug titles always start with Bug:
Every bug issue has both a severity: and area: label
P0 bugs get a Slack notification (via scripts/notify-critical.sh)
Duplicate bugs are closed with a reference to the original

Edge Cases

Vague reports: Ask the reporter for reproduction steps before filing. Don't file issues you can't act on.
Already fixed: Check recent commits/PRs. If fixed, reply to reporter and don't file.
Feature request disguised as bug: Re-label as enhancement and move to backlog.