How do I install the Bug Triage skill?

Run npx skillmds add majiayu000/bug-triage in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Bug Triage safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Bug Triage?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Bug Triage free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Bug Triage?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Bug Triage by majiayu000 — Agent Skill

Name: Bug Triage
Rating: 4.5 (4 reviews)
Author: majiayu000

Bug Triage

Reproduce, isolate, and fix a bug (or failing build/test), then summarize root cause, fix, and verification steps. Use when the user reports a bug, regression, or failing build/test and wants a fix.

majiayu000 c1159f3 2 files · 3.1 KB Updated Sep 9, 2026 567 repo stars

File contents

Bug triage

Goal

Turn an ambiguous bug report into:

a reliable repro (or a clear “cannot reproduce yet” with next info to collect)
a root-cause explanation
a minimal, reviewed fix
verification steps (commands + manual checks)

First checks

Read any repo-specific guidance (AGENTS.md, CONTRIBUTING.md, README).
Clarify impact: severity, who is affected, and whether it’s a regression.

If info is missing, ask for it

Exact steps to reproduce (starting state + inputs).
Expected vs actual behavior.
Error text / stack trace / logs (full, unedited if possible).
Environment: OS, runtime versions (Node/Bun), browser, commit hash/tag.
Frequency: always / sometimes / only certain data.
“Last known good” version or approximate date when it started.

Workflow (checklist)

Reproduce locally
- Prefer the simplest, fastest repro.
- If it’s flaky, try to reduce nondeterminism (seed, fixed time, retries).
Localize the failure
- Narrow to a file/function/component/config.
- Use rg to find relevant code paths and error strings.
Identify root cause
- Form a hypothesis, confirm with logs/breakpoints, then refine.
- If it’s a regression and git history exists, consider git bisect.
Implement the minimal fix
- Fix the cause, not the symptom.
- Avoid drive-by refactors and formatting churn.
Verify
- Run the project’s standard checks (lint/tests/build).
- Re-run the repro steps and confirm the fix.

Repo-aware command hints

Use what the repo actually uses:

If bun.lock exists: prefer bun ... (e.g. bun lint, bun build, bun dev).
Otherwise: use the project’s documented commands (npm, pnpm, yarn, etc.).
If bun.lock exists but bun is not available, tell the user and ask whether to install bun or use the repo’s alternative package manager.

Deliverable (paste this in the chat / PR / issue)

Use this format:

Summary: ...
Repro: ...
Root cause: ...
Fix: ...
Verification: ...
Risk/notes: ...

If you need a bug-report structure to ask the user for, use references/bug-report-template.md.

---name: bug-triagedescription: Reproduce, isolate, and fix a bug (or failing build/test), then summarize root cause, fix, and verification steps. Use when the user reports a bug, regression, or failing build/test and wants a fix.--- # Bug triage ## Goal Turn an ambiguous bug report into: - a reliable repro (or a clear “cannot reproduce yet” with next info to collect) - a root-cause explanation - a minimal, reviewed fix - verification steps (commands + manual checks) ## First checks 1) Read any repo-specific guidance (`AGENTS.md`, `CONTRIBUTING.md`, README). 2) Clarify impact: severity, who is affected, and whether it’s a regression. ## If info is missing, ask for it - Exact steps to reproduce (starting state + inputs). - Expected vs actual behavior. - Error text / stack trace / logs (full, unedited if possible). - Environment: OS, runtime versions (Node/Bun), browser, commit hash/tag. - Frequency: always / sometimes / only certain data. - “Last known good” version or approximate date when it started. ## Workflow (checklist) 1) Reproduce locally - Prefer the simplest, fastest repro. - If it’s flaky, try to reduce nondeterminism (seed, fixed time, retries). 2) Localize the failure - Narrow to a file/function/component/config. - Use `rg` to find relevant code paths and error strings. 3) Identify root cause - Form a hypothesis, confirm with logs/breakpoints, then refine. - If it’s a regression and git history exists, consider `git bisect`. 4) Implement the minimal fix - Fix the cause, not the symptom. - Avoid drive-by refactors and formatting churn. 5) Verify - Run the project’s standard checks (lint/tests/build). - Re-run the repro steps and confirm the fix. ## Repo-aware command hints Use what the repo actually uses: - If `bun.lock` exists: prefer `bun ...` (e.g. `bun lint`, `bun build`, `bun dev`). - Otherwise: use the project’s documented commands (`npm`, `pnpm`, `yarn`, etc.). - If `bun.lock` exists but `bun` is not available, tell the user and ask whether to install `bun` or use the repo’s alternative package manager. ## Deliverable (paste this in the chat / PR / issue) Use this format: - **Summary:** ... - **Repro:** ... - **Root cause:** ... - **Fix:** ... - **Verification:** ... - **Risk/notes:** ... If you need a bug-report structure to ask the user for, use `references/bug-report-template.md`.

Frequently asked questions