bug-triage

Name: bug-triage
Author: zakelfassi

17stars0forks

How to install bug-triage?

zakelfassi/skills-driven-development/bug-triage

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

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Bug Triage
2
3	Convert a bug report (user message, error log, Sentry alert) into a well-structured GitHub issue.
4
5	## Inputs
6	- Bug report (raw text, screenshot, error log, or Sentry URL)
7	- Reporter (who reported it, if known)
8	- Environment (production, staging, local)
9
10	## Steps
11
12	1. Reproduce or verify
13	- Can you reproduce the bug from the report?
14	- If yes: document exact reproduction steps
15	- If no: flag as "needs-repro" and note what you tried
16
17	2. Classify severity
18	\| Severity \| Criteria \| Label \|
19	\|----------\|----------\|-------\|
20	\| P0 \| Data loss, security, or full outage \| `severity:critical` \|
21	\| P1 \| Major feature broken, no workaround \| `severity:high` \|
22	\| P2 \| Feature broken, workaround exists \| `severity:medium` \|
23	\| P3 \| Minor annoyance, cosmetic \| `severity:low` \|
24
25	3. Identify the component
26	- Frontend / Backend / Infrastructure / Extension
27	- Add the corresponding label: `area:frontend`, `area:backend`, etc.
28
29	4. Write the GitHub issue
30	```markdown
31	## Bug: [one-line description]
32
33	Severity: P[0-3]
34	Environment: [production/staging/local]
35	Reporter: [name or "internal"]
36
37	### What happened
38	[Clear description of the bug]
39
40	### Expected behavior
41	[What should have happened]
42
43	### Reproduction steps
44	1. ...
45	2. ...
46	3. ...
47
48	### Evidence
49	[Error logs, screenshots, Sentry link]
50
51	### Suspected cause
52	[If you have a hypothesis, state it]
53	```
54
55	5. File the issue
56	```bash
57	gh issue create --title "Bug: [description]" --body "[body]" --label "bug,severity:[level],area:[component]"
58	```
59
60	6. Assign if obvious
61	- If the suspected cause points to a clear owner, assign them
62	- If not, leave unassigned (triage meeting will handle it)
63
64	## Conventions
65	- Bug titles always start with `Bug:`
66	- Every bug issue has both a `severity:` and `area:` label
67	- P0 bugs get a Slack notification (via `scripts/notify-critical.sh`)
68	- Duplicate bugs are closed with a reference to the original
69
70	## Edge Cases
71	- Vague reports: Ask the reporter for reproduction steps before filing. Don't file issues you can't act on.
72	- Already fixed: Check recent commits/PRs. If fixed, reply to reporter and don't file.
73	- Feature request disguised as bug: Re-label as `enhancement` and move to backlog.

People who liked this also viewed

6 picks

Type

bug-triage

17stars0forks

View on GitHub

How to install bug-triage?

zakelfassi/skills-driven-development/bug-triage

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Bug Triage
2
3	Convert a bug report (user message, error log, Sentry alert) into a well-structured GitHub issue.
4
5	## Inputs
6	- Bug report (raw text, screenshot, error log, or Sentry URL)
7	- Reporter (who reported it, if known)
8	- Environment (production, staging, local)
9
10	## Steps
11
12	1. Reproduce or verify
13	- Can you reproduce the bug from the report?
14	- If yes: document exact reproduction steps
15	- If no: flag as "needs-repro" and note what you tried
16
17	2. Classify severity
18	\| Severity \| Criteria \| Label \|
19	\|----------\|----------\|-------\|
20	\| P0 \| Data loss, security, or full outage \| `severity:critical` \|
21	\| P1 \| Major feature broken, no workaround \| `severity:high` \|
22	\| P2 \| Feature broken, workaround exists \| `severity:medium` \|
23	\| P3 \| Minor annoyance, cosmetic \| `severity:low` \|
24
25	3. Identify the component
26	- Frontend / Backend / Infrastructure / Extension
27	- Add the corresponding label: `area:frontend`, `area:backend`, etc.
28
29	4. Write the GitHub issue
30	```markdown
31	## Bug: [one-line description]
32
33	Severity: P[0-3]
34	Environment: [production/staging/local]
35	Reporter: [name or "internal"]
36
37	### What happened
38	[Clear description of the bug]
39
40	### Expected behavior
41	[What should have happened]
42
43	### Reproduction steps
44	1. ...
45	2. ...
46	3. ...
47
48	### Evidence
49	[Error logs, screenshots, Sentry link]
50
51	### Suspected cause
52	[If you have a hypothesis, state it]
53	```
54
55	5. File the issue
56	```bash
57	gh issue create --title "Bug: [description]" --body "[body]" --label "bug,severity:[level],area:[component]"
58	```
59
60	6. Assign if obvious
61	- If the suspected cause points to a clear owner, assign them
62	- If not, leave unassigned (triage meeting will handle it)
63
64	## Conventions
65	- Bug titles always start with `Bug:`
66	- Every bug issue has both a `severity:` and `area:` label
67	- P0 bugs get a Slack notification (via `scripts/notify-critical.sh`)
68	- Duplicate bugs are closed with a reference to the original
69
70	## Edge Cases
71	- Vague reports: Ask the reporter for reproduction steps before filing. Don't file issues you can't act on.
72	- Already fixed: Check recent commits/PRs. If fixed, reply to reporter and don't file.
73	- Feature request disguised as bug: Re-label as `enhancement` and move to backlog.

People who liked this also viewed

6 picks

Type