How do you triage open source issues before a maintainer looks?
An open source triage AI Employee that reads every new public GitHub issue as it opens, labels it against your rules, drafts a first response grounded in your docs, and leaves it for a maintainer. It labels and drafts. It never closes an issue.
×
A public repo gets issues that are duplicates, questions already answered in the docs, real bugs with no reproduction, and feature requests, all in the same inbox, all unlabeled, all waiting for a maintainer who has a day job. The first triage pass is mechanical but unavoidable: read it, figure out what kind of issue it is, label it, and ask for whatever's missing before anyone can actually work it. That first pass is where issues stall. A reporter who gets no response for a week assumes the project is dead; a maintainer who opens a backlog of forty unlabeled issues doesn't know where to start. The work isn't hard. It's that a person has to do the same read, label, respond loop over and over before the interesting engineering can even begin.
When a new issue opens, the open source triage AI Employee reads it, checks your docs and existing issues read only, applies the labels your rules call for, and drafts a first response: a pointer to the docs, a request for a reproduction, or a note that it looks like a duplicate. It labels and drafts; a maintainer decides. It never closes an issue.
See exactly how the work gets done.
Fires on a new issue
Each newly opened public issue triggers a run, so the reporter gets a labeled issue and a first response fast, not after it's sat unread for a week.
Carries your triage rules
Which labels exist, what counts as a bug versus a question, and what a good reproduction looks like travel with it as skills and memory, updated as your project's conventions change.
Reads docs and issues read only
It searches your docs and existing issues read only to ground the response and spot likely duplicates. Credentials stay in memory, never exposed to the model.
Labels against your rules
It applies the labels your rules call for: type, area, needs reproduction. That way a maintainer opens a backlog that's already sorted instead of a wall of untagged issues.
Drafts a first response
It leaves a drafted reply grounded in your docs for a maintainer to review and post. That might be a link, a reproduction request, or a duplicate note.
Never closes an issue
It labels and drafts, and stops there. Closing, resolving, or dismissing an issue is always a maintainer's call.
Runs in your environment
Every run is isolated inside your own infrastructure, reaching only the repo and the docs it needs to triage.
Reads docs and issues read only
It reads your docs and existing issues to ground the response. It never edits a doc or rewrites another issue.
Never closes an issue
It labels and drafts only. It never closes, resolves, or dismisses. That decision stays with a maintainer.
Drafts, never auto posts a verdict
The first response is a draft a maintainer reviews before it goes out, so no reporter gets an automated dismissal in your project's name.
You own the rules
The label taxonomy and triage rules are yours, versioned and changed on your terms, not in a vendor dashboard.
The public issue that used to sit unlabeled for a week now opens already sorted, with a first response grounded in your docs drafted and waiting. The AI Employee does the first pass; the maintainer does the engineering.
On every issue
Labeled and drafted before a maintainer looks
Grounded in docs
First responses built from your docs, not guesses
Never closes
The AI Employee triages; a maintainer decides
