Skip to content

triage-issues

triage-issues runs an incoming issue through a disciplined state machine, so a bug report or feature request comes out either ready to work or clearly parked β€” never stuck in the limbo of β€œwe’ll look at it later.”

What it solves

Issue backlogs rot the same way everywhere: reports land half-described, nobody reproduces the bug before debating it, the same questions get asked twice because the first round of grilling was never written down, and rejected ideas vanish with no record of why β€” so they get re-proposed in six months. Triage done by gut produces an inconsistent backlog nobody trusts. A state machine makes every issue take the same well-defined path.

How it works

  • Categorise β€” bug or enhancement, first.
  • Defined states β€” each issue moves through needs-triage β†’ needs-info β†’ ready-for-agent / ready-for-human / wontfix, so its status is always explicit.
  • Reproduce before grilling β€” a bug must be reproduced before it’s debated, so the conversation is about a real failure, not a guess.
  • Preserve the work β€” grilling that ends in needs-info is saved in the issue notes, so the next round doesn’t restart from zero; rejected enhancements are recorded in .out-of-scope/ with their reasoning.
  • Honest attribution β€” every AI-generated comment carries a mandatory disclaimer, so a human reader always knows what an agent wrote.

When to use

Filing or triaging incoming bugs and feature requests, or preparing issues for an agent to pick up. It sits in the docs bundle next to plan-backlog.