Bug

---
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.

1. Ask the user to describe the bug: what happened, what was expected, and steps to reproduce (if known).
2. Investigate the codebase to confirm the area of code involved. Note relevant file paths.
3. **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.
4. 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 `crates/runner-app/Cargo.toml`>
     ```
   - Command shape: `gh issue create --label bug --label P1 --title "…" --body "…"`
5. Report the issue URL and the assigned priority.

#### `list`
Show all bugs, sorted by priority.

1. 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`
2. 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).
3. 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.
4. 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.

1. Close the GitHub Issue: `gh issue close <number>`
2. Confirm closure to the user.

#### `prioritize <issue-number> <P0|P1|P2|P3>`
Set or change the priority of an existing bug.

1. 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.)
2. Confirm the new priority.

#### `view <issue-number>`
Show details of a specific bug report.

1. Fetch the issue: `gh issue view <number>`
2. 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 `crates/runner-app/Cargo.toml` when populating the Environment section.