Automate GitHub issue triage with labels and a daily summary

Triage is small work that arrives constantly. Each issue needs a read, a label, a guess at severity, and a check for an older report of the same thing. Skipped for a week, the list becomes too long to sort, and real bugs sit next to questions and feature ideas. GitHub exposes issues and labels through its REST API, so the sorting itself can be drafted from data you already have.

You add the job and connect your repository. Each day a scheduled agent lists issues opened since the last run, reads titles, bodies and comments, and compares them with open issues for likely duplicates. For each one it proposes labels from your existing label set, a priority, and one sentence of reasoning. Its brief tells it to choose from labels you already use and not to create new ones. Issues missing steps to reproduce are marked so someone can ask for them. The agent drafts proposals and changes nothing on the issue.

The CTO agent, as department head, reviews the list before it goes out: is each label one your repository uses, does each duplicate link actually describe the same problem, is any security-sounding report marked for you directly. Then you approve, edit or skip it, and nothing is applied to your repository until you do. Check the opening days against your own judgement to see where it over- or under-rates severity.

Write short label definitions in your repository so the agent chooses by meaning, not by name. Keep priorities few: urgent, normal, low. Review the duplicate suggestions most closely, since linking two different bugs hides one of them. Over time, note which proposals you changed and tighten the brief with that.