| name | bug |
| description | Report, list, or manage bug reports as GitHub issues |
Bug Reporting
Report and manage bugs for Runners via GitHub Issues with the bug label.
Usage
/bug <action> [args]
Actions
new
Report a new bug.
- Ask the user to describe the bug: what happened, what was expected, and steps to reproduce (if known).
- Investigate the codebase to confirm the area of code involved. Note relevant file paths.
- Pick a priority (see Priority below). If the user didn't state one, propose one based on the bug's severity and the rubric, and confirm before filing. Don't file unlabeled.
- Create a GitHub Issue with labels
bug and the chosen P0/P1/P2/P3:
-
Title: bug: <short description>
-
Body using this template:
## Description
<what's wrong>
## Expected behavior
<what should happen>
## Steps to reproduce
<if known>
## Relevant code
<file paths and brief pointers to the affected area>
## Environment
- OS: <if relevant>
- Version: <app version from `src-tauri/tauri.conf.json`>
-
Command shape: gh issue create --label bug --label P1 --title "…" --body "…"
- Report the issue URL and the assigned priority.
list
Show all bugs, sorted by priority.
- Fetch open bugs with priority + metadata as JSON so they can be sorted:
gh issue list --label bug --state open --limit 50 --json number,title,labels,createdAt,assignees
- Sort the rows by priority (
P0 first, then P1, P2, P3, then unlabeled-by-priority last). Within a priority bucket, sort by createdAt ascending (oldest first — they've been waiting longest).
- Present a table with columns: Priority, #, Title, Created, Assignee (if any). Use the priority label as the leading column so the ranking is visually obvious. Issues without a P-label show
— in the priority column and a callout asking the user to triage them.
- If the user asks for closed bugs too, repeat with
--state all and add a State column.
close <issue-number>
Mark a bug as fixed.
- Close the GitHub Issue:
gh issue close <number>
- Confirm closure to the user.
prioritize <issue-number> <P0|P1|P2|P3>
Set or change the priority of an existing bug.
- Remove any existing P-label on the issue, then add the new one:
gh issue edit <number> --remove-label P0 --remove-label P1 --remove-label P2 --remove-label P3 --add-label <priority>
(Removing all four is safe — gh ignores remove-label for labels not present.)
- Confirm the new priority.
view <issue-number>
Show details of a specific bug report.
- Fetch the issue:
gh issue view <number>
- Display the full issue body, current priority, comments count, and state.
Labels
bug — all bug issues use this label.
P0 / P1 / P2 / P3 — priority, exactly one per issue.
Priority
Every bug gets exactly one priority label. Rubric:
- P0 — Ship-blocker, data-loss risk, security issue, or recent regression breaking a load-bearing flow. Drop other work.
- P1 — Real user friction in a common path; broken affordance the user sees daily. Fix this cycle.
- P2 — Annoying but workaround exists; rare path; cosmetic issue in a prominent surface. Fix when convenient.
- P3 — Edge case, theoretical, or "would be nice." No fixed timeline.
When in doubt between two levels, pick the lower-urgency one and say why; over-labeling P0/P1 dilutes the signal.
Notes
- Do not commit or push unless the user explicitly asks.
- When creating issues, investigate the codebase first to include relevant file paths — this makes bugs actionable.
- Read the app version from
src-tauri/tauri.conf.json when populating the Environment section.