GitHub issue triage
The job
Triage every new GitHub issue — read it, propose labels and a first response, and route it for approval before anything is written back to the repo.
Why it's hard without a system
The pain you recognize
- A brittle script can list issues, but it cannot read context and decide whether something is a bug, a question, or a duplicate.
- A single agent in a chat can draft a reply, but it dies when the laptop closes and nothing remembers what was decided last time.
- A human bottleneck reads every issue by hand — fine at five issues a week, broken at fifty.
How a team of agents does it
Division of labor, with a human checkpoint
The unit is a team, not a single agent — and the human checkpoint is a product surface, not an afterthought.
Triage agent
Pulls new issues on a schedule, reads each one, and proposes labels, a priority, and a draft reply — storing its reasoning in memory so the context carries to the next run.
Maintainer checkpoint
Before any label or comment is applied to the issue, the workflow pauses for a human decision. Approve, edit, or reject — with the agent's proposal attached.
Audit trail
Every listIssues call, every draft, every approval and its outcome is recorded. When something is wrong, the run trace shows exactly which step did what.
What's involved
Plugins and platform
Platform capabilities
- Schedule — fires on a cadence, no human pressing start
- Agent memory — carries issue context across runs
Approval point
Before labels or comments are applied to the issue — the workflow pauses for a maintainer decision.
Proof surface
The run trace (each listIssues and LLM call), the approval gate with the proposed action, and the audit log of what was applied.