A triage workflow that scales

Collecting good reports is the easy half. This is a routine for processing them without the inbox becoming a place bugs go to be ignored.

Set up the board first

Before triaging anything, define columns. A workable default:

Five columns is usually right. Each maps to open or closed, and that state is what BugDump uses to determine outstanding work.

Resist adding Blocked, Needs Info, and Deferred. Every such column becomes a place tasks go to be forgotten. If it is not done, it is open.

Column names are visible on the public portal, so write them for an outside reader.

The daily pass

Ten to fifteen minutes, once a day. Two or three times a day during a release.

1. Group duplicates first. Before reading anything closely, scan for reports describing something you already have a task for and attach them. This is the highest-leverage step — it routinely turns forty items into six, and everything after it is cheaper.

2. Create tasks for what's genuinely new. One per distinct bug. Write the title for a stranger, since it may appear on the public portal: "Checkout fails for EU customers" rather than "checkout broken".

3. Use the intersection. For any task with several reports, look at what they share before opening a debugger. All Safari? A Safari bug. All under 768px? Responsive. All within fifteen minutes and then nothing? A deploy — go look at what shipped.

4. Set priority. A new project starts with four: Low, Medium, High, Critical. Reserve the top one for "someone is fixing this now." A backlog where everything is critical carries no information.

The list is yours to change — rename them to whatever your team says out loud, or cut them to three if the fourth never gets used. Fewer, clearly separated levels beat a long scale nobody applies consistently. See Customizing priorities.

5. Assign. An unassigned task in In Progress is nobody's.

6. Move it, don't annotate it. Column position is the status. A task in In Progress with a comment saying "actually blocked" is in the wrong column.

Run the pass from the keyboard

The pass goes faster if you never leave the board. Click the first card in the column you are working, which opens it in the side panel, then use J and K to move to the next and previous task in that column. Set priority, assign, and move the task from the panel's sidebar, press J, and keep going.

Stepping stays inside the column you started in and follows the board's filters, so filtering to Triage work or to one priority gives you a queue with a definite end. Esc closes the panel when you are done.

For the bulk decisions — everything from one bad deploy going to Confirmed, or a batch of spam being deleted — select several cards with Cmd/Ctrl + click or Shift + click and act on them at once instead of stepping through them.

Reproduce before confirming

Move a task to Confirmed only when you have reproduced it or the evidence is conclusive.

The evidence is usually there: the actions log is your reproduction steps recorded rather than remembered, the viewport tells you the width, and the replay shows what the user actually did.

Tasks that sit in Confirmed without ever being reproduced are the ones that get closed months later as "cannot reproduce." The evidence will not wait either: reports are deleted after the plan's retention period — 30 days on Free — and the actions log and replay go with them.

Handle the flood separately

When something breaks badly, reports arrive in bulk. Do not triage them one by one.

Create the task, attach the first few reports, and confirm it. New arrivals matching the same issue attach to that task. The forty-first report adds nothing, and that is fine — though every widget report counts toward the project's monthly report limit, so a long flood on Free can use up the month's 500.

Then fix the bug rather than reading reports about it.

Close things

The most common failure is not mis-triage — it is never closing anything.

Close Done when it ships. Close Won't Fix deliberately, with a comment saying why. A closed task with a reason is more respectful to a reporter than one left open forever.

If your open count only grows, the board has stopped describing reality.

Use the activity view

get_task_activity returns a daily summary of tasks created and resolved over the last 14 days, through MCP. The shape you want is created and resolved roughly in balance. Consistently more created than resolved means triage is running slower than reports arrive — either the routine needs more time, or the bar for creating a task is too low.

Let the agent do the tedious parts

Cross-report comparison is exactly the work humans skip:

Read the reports on #17 and tell me which browsers are affected.

Check task #8 — is this the same bug as #3?

Duplicate detection and environment correlation are mechanical, high-value, and reliably neglected. They are worth handing to Claude Code.

Notifications

Every member gets an in-app notification for each new report, and an email too when Email notifications is on in their account settings. Leave email on for whoever is triaging today and let everyone else turn it off.

A team where everyone is notified about every report is a team that has learned to ignore notifications.

See also

• Reading a bug report

• Working with tasks and the board

• Customizing priorities

• Custom properties: adding your own fields to tasks

• Setting up the public portal