Turning One Night of Ticket Sorting Into /queue groom

A teammate’s queue had 22 tickets on it. Five were small and ready to pull. The other 17 had been sitting in Inbox so long that nobody remembered why they were still open.

There was no mystery in it. Tickets pile up on a shared board the way email piles up in an inbox. Everything arrives at the same priority, so priority stops meaning anything. With 22 items assigned and nothing tiered, there was no way to tell at a glance which ones could start now, which were waiting on someone else, and which were waiting on nothing at all.

Sorting the pile by hand

We went through the board ticket by ticket. Five were small and ready, with no blockers and nothing pending from anyone else. Those moved to the top tier, so they could be pulled in order without re-reading the whole list every morning.

The other 17 were old, with no recent activity and no clear reason to stay open. We left them at the bottom and flagged them for cancellation. The decision to cancel belongs to the business owner, so we didn’t make it.

Then we built a ranked pull list: a single ticket saying what to work on and in what order. It drew from both their plate and ours, so they weren’t juggling two views of the same work.

Saving the sort as a command

Two other people on the team run the same kind of queue, and their boards have the same problem: everything flat, old tickets mixed in with fresh ones. We had just done the sort by hand for one person, and the alternative was doing it by hand three more times. So we wrote down what we’d done as a saved command, /queue groom. It captures the tiering rule, the definition of stale, and the pull-list format. Anyone can run it against their own queue and get the same result: small and ready on top, stale and flagged at the bottom, and a ranked list to work from.

Sorting tickets is fast either way. What changed is where the process lives. The first time, it lived in our heads, in the specific choices we made about one person’s queue on one night. If someone had asked the next week how we decided what counted as stale, we’d have had to reconstruct it. As a saved command, the second and third runs use the same rules whoever runs them.

That is the difference between fixing a queue and fixing how we handle queues. The first helps one person for one week. The second means the next teammate with a cluttered board doesn’t wait for us to notice and sort it manually. It also gives us something to argue with if we disagree with our own judgment call from a month ago. We have a document to point at instead of a memory.

Where the command stops

We didn’t cancel the 17 stale tickets ourselves, though the flags were clear enough that we could have. Someone owns those tickets, and closing work that isn’t ours to close needs a person’s yes. A rule we wrote for ourselves at 1 AM can’t supply one. So the command sorts and flags, and it never deletes. That boundary went into the document along with the tiering logic: it says where the automation ends and a human has to decide.

dxdev LESSON · paste into your AI coding agent
LESSON: Turn A One-Off Cleanup Into A Written Playbook Before Repeating It By Hand
SOURCE: dxdev.com/blog/queue-groom-playbook-scales
WHAT HAPPENED: A teammate's board had 22 tickets sitting at the same flat priority. Going through them by hand, five were small and ready with no blockers, so they got moved to a top tier and combined with the writer's own tickets into a single ranked pull list. The other 17 were stale with no recent activity, so they were flagged for cancellation and left at the bottom, since closing them wasn't the writer's call to make. Two other teammates ran queues with the same flat, untiered problem, so instead of manually repeating the sort for each of them, the tiering rule, the definition of stale, and the pull-list format were written down as a saved command, `/queue groom`.
THE RULE: When a manual fix works and you notice the same problem exists elsewhere, write down the exact rules you used as a reusable process before repeating the manual work, and keep any decision that isn't yours to make, like canceling someone else's ticket, outside the automation.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does the process document a specific, checkable definition of what counts as ready versus stale, rather than leaving it to judgment each time?
      2. Can someone other than the original author run the process and get the same tiering result?
      3. Does the automation stop short of taking actions that belong to a different owner, such as canceling or closing someone else's work?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.