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.
Content & Writing
102 Stars
7 Forks
Updated Jan 3, 2026, 12:54 AM
Why Use This
This skill provides specialized capabilities for jMerta's codebase.
Use Cases
Developing new features in the jMerta repository
Refactoring existing code to follow jMerta standards
Understanding and working with jMerta's codebase structure
---
name: bug-triage
description: 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`.