Triage the backlog

Triage is one read-only pass over a project’s backlog. An agent reads the tickets and the repository and comes back with an order to run them in, and with the reasons that order exists.

What a pass decides

For every ticket it places, triage records:

• A rank. Lower runs first. Ranks are fractional, so a ticket added later can slot between two that already have places.
• A size. S, M, L or XL, from what the work actually touches.
• Dependencies. The tickets whose work must be merged before this one starts.
• Conflicts. The tickets that touch the same files and must never run alongside it.
• Areas. The parts of the codebase it lands in.
• A one-line rationale for the placement.
• Flags, where something is wrong with the ticket itself.

There are three flags. Needs detail means the agent could not tell what to build. Too big means this is more than one run of work. Duplicate? links to the ticket that appears to ask for the same thing. A flagged ticket keeps its place in the order but stays out of the queue until you deal with it, and each flag carries the button that clears it.

Starting a pass

The Triage button sits in the Backlog column header.

Pick the agent, model and reasoning effort for the pass, then a strategy:

• Dependencies first. Foundations early, then your priorities, then small before large.
• Quick wins first. Small, safe tickets land early. Dependencies are still respected.
• Riskiest first. Central or uncertain work goes early so problems surface soon.

Then a scope. New tickets only places the untriaged tickets and leaves ranked ones where they are. Re-rank everything starts the order again from scratch. The footer says how many tickets the pass will place, and how many running tickets it will not touch.

While the pass runs, the cards being read carry a violet beam and the Triage button becomes Stop. One pass runs per project at a time; asking for a second is refused rather than queued.

The board afterwards

Cards carry their rank as a badge. A ticket that depends on another shows a “waits for” chip naming it. Flagged tickets show their flag. Beside the Triage button, a chevron with a count queues every ranked, unflagged ticket at once, in rank order; the Backlog column rules can do the same thing without you.

Dependency links apply to both the queue and manual starts. A prerequisite must be Done, and Herdloom checks that its landed commit is present on the project’s base branch before starting the dependent ticket. Moving a card to Done alone does not merge its code. A conflict holds until the other ticket has landed on the base branch, because two branches cut from the same base that edit the same file still collide at merge time. A ticket that is blocked is skipped, not stuck: the queue moves on to the next one that can run.

Starting from an empty project

Make the scaffold the first ticket: the app structure, build configuration, and initial dependencies. Every feature that needs it should have a dependency on that ticket. Queue them together if you like; the scaffold runs first, and its dependents wait until it merges. Independent features can then run in parallel in their own checkouts. Rank alone does not make one ticket wait for another.

If a dependent ticket already has a checkout from earlier work, Herdloom brings in the merged base before running it. Uncommitted changes or an update conflict stop the run for you to resolve, without discarding your work.

Keeping the order yours

Moving a ticket up or down in its drawer pins it, and later passes leave pinned tickets alone. Unlinking a dependency is one click when the ticket is idle. You cannot delete a prerequisite while unfinished tickets depend on it; archive completed work or update those links first. Editing a ticket’s title or description after triage marks its result stale, so you know the placement was made against older text.

Next

Deal with the flags: Clarify and Split turn an unclear or oversized ticket into one an agent can finish. Or hand the queue over in Automation.