jmerta/codex-skills

bug-triage

Use when the user reports a bug, regression, runtime error, failing build, or broken test and wants reproduction, diagnosis, root-cause analysis, or an authorized fix. Isolates the shared cause and verifies the smallest relevant change.

First seen Jan 23, 2026

Installation

$ npx skills add jmerta/codex-skills --skill bug-triage

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from jmerta/codex-skills · top by installs.

npx skills add jmerta/codex-skills

Browse all from jmerta/codex-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 130
License LICENSE
Default branch main
Open issues 4
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,482 B
  • docs SUMMARY.md 254 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 43 installs

SKILL.md

Bug triage

Establish scope

  1. Read repository instructions and inspect the current branch, status, and relevant diff.
  2. Determine whether the user asked only for diagnosis or also authorized a fix.
  3. Inspect available errors, logs, tests, and code before asking for missing details.
  4. Record expected behavior, actual behavior, environment, frequency, and last known good state when they affect the investigation.

Reproduce and isolate

  1. Use the smallest reliable reproduction. Preserve the original failure output.
  2. If the failure is intermittent, control time, randomness, concurrency, data, and retries one variable at a time.
  3. Trace the failing path end to end. Search every caller of the function or component before editing it.
  4. Form a falsifiable hypothesis and run the narrowest check that can confirm or reject it.
  5. Use history or git bisect only when a regression boundary will materially shorten the search.

Separate these outcomes explicitly:

  • confirmed product regression;
  • pre-existing or baseline failure;
  • environment, credentials, service, or dependency failure;
  • insufficient evidence to reproduce.

Fix when authorized

  1. Add or adapt the smallest regression check that fails for the confirmed cause.
  2. Fix the shared root cause rather than guarding one visible caller.
  3. Avoid unrelated refactors, dependency upgrades, formatting churn, and broad exception handling.
  4. Re-run the reproduction, focused regression check, and the smallest relevant project checks.

Use the package manager, wrapper, and commands already selected by the repository. Infer them from repository instructions, manifests, lockfiles, and scripts; do not substitute another tool just because it is installed locally.

Report

Include:

  • Observed: exact symptom and affected scope.
  • Root cause: confirmed explanation, or the leading hypothesis clearly labeled.
  • Change: files and behavior changed, or diagnosis only.
  • Verification: commands and results, including baseline failures.
  • Remaining risk: untested paths, flaky behavior, or external blockers.

Use references/bug-report-template.md only when the user needs a reusable intake form.