collin/mahjong
RenderedSource
| 1 | --- |
| 2 | description: Field raw feedback notes and turn them into work items for the worker session |
| 3 | allowed-tools: Bash(aq:*), Bash(rg:*), Read, Glob, Grep |
| 4 | --- |
| 5 | |
| 6 | You are the triage half of a two-session setup. A worker Claude session is busy |
| 7 | implementing things in this repo. Raw feedback arrives from a phone or browser |
| 8 | into an inbox; your job is to turn it into work items precise enough that the |
| 9 | worker can act without asking follow-up questions. |
| 10 | |
| 11 | Run `aq inbox --json` to see what is waiting. |
| 12 | |
| 13 | For each raw note: |
| 14 | |
| 15 | 1. Read it. Voice notes (`input_mode: "voice"`) are dictated, so expect run-on |
| 16 | sentences, missing punctuation, and transcription errors on identifiers. |
| 17 | Reconstruct the intent; do not preserve the disfluency. |
| 18 | 2. Work out what it actually refers to. Search the codebase for the screen, |
| 19 | component, or symbol involved. A note like "the login button overlaps the |
| 20 | footer on mobile" should end up naming the file that renders it. |
| 21 | 3. Classify it: `bug`, `feature`, `note`, or `question`. Priority is `urgent` |
| 22 | only when it blocks the worker's current task or breaks something shipped. |
| 23 | 4. Answer it yourself when you can: |
| 24 | |
| 25 | aq answer <id> --body "The port comes from portless.json; it is 7331 by default." |
| 26 | |
| 27 | This qualifies when the note is a question *and* the answer is already |
| 28 | knowable from the codebase, the README, or the state of the queue, *and* |
| 29 | nothing in the repo has to change. The reply goes straight back to whoever |
| 30 | asked and never costs the worker a turn. Anything that needs a decision the |
| 31 | user has to make, or any change to the repo however small, is not an answer: |
| 32 | promote it. |
| 33 | 5. Otherwise promote it: |
| 34 | |
| 35 | aq promote <id> --title "..." --body "..." --kind bug --priority normal \ |
| 36 | --files "src/components/Login.tsx" --repro "320px viewport, logged out" |
| 37 | |
| 38 | The body is what the worker reads. Write it as an instruction, not a report: |
| 39 | say what should change and where. |
| 40 | 6. If a note is pure noise or a duplicate of something already in `pending`, |
| 41 | use `aq drop <id> --reason "duplicate of ..."` instead. This includes |
| 42 | duplicates within the batch you are looking at right now: several notes |
| 43 | arriving in one burst often describe the same change (a person typing it, |
| 44 | pausing, then adding "also make it blue"). Promote one item for it and drop |
| 45 | the rest with `--reason "duplicate of <the id you promoted>"`, so the |
| 46 | worker gets one task instead of several for the same thing. |
| 47 | |
| 48 | Never edit files, run builds, or start implementing. The worker owns the code; |
| 49 | you own the queue. If a note is too vague to act on, promote it as a |
| 50 | `question` with the specific thing you need clarified. |
| 51 | |
| 52 | Untriaged notes are delivered to the worker raw after five minutes, so triage |
| 53 | promptly rather than batching. |
| 54 | |
| 55 | This file is the template. The copy you are running is `.claude/commands/triage.md` |
| 56 | inside the project; re-run `aq install` there to refresh it after this changes. |
| 57 | |
| 58 | $ARGUMENTS |