Nightly issue triage

Every night, an AI agent labels new GitHub issues, spots duplicates, asks reporters for missing details and leaves a prioritized digest for the morning.

New issues arrive at every hour and nobody owns the inbox. This workflow triages them while you sleep, with an agent that knows your code: it reads each new issue, checks it against the repository, and prepares the morning so that the team starts with decisions, not with sorting.

How it works

1. Triage: the agent fetches the issues opened since the last run, applies the repository's existing labels (type, area, priority), links duplicates, and asks the reporter for the missing reproduction steps, politely and only when something is really missing.
2. Digest: a second step reads the triage log and writes a short, prioritized digest: what is urgent, what is a quick win, what needs a decision.

What you need

• An agent connected to the repository's machine, with the GitHub CLI installed.
• A GITHUB_TOKEN workspace secret allowed to label and comment on issues.

Steps

1. 1. Triage new issues

   Triage the GitHub issues of the repository in the current directory opened during the last {{inputs.since_hours}} hours.
   
   1. Check that the GitHub CLI works: `gh auth status`. If it fails, fail the step with the reason.
   2. List the repository labels (`gh label list --limit 200`) and the open issues created in the window:
      `gh issue list --state open --search "created:>=<ISO date of now minus {{inputs.since_hours}} hours>" --json number,title,body,labels,assignees,author --limit 100`.
      Leave alone the issues that already have an assignee or a type label (bug, feature, question…).
   3. Read the README and the architecture notes (CLAUDE.md, AGENTS.md) so you can tell which area of the code an issue concerns.
   4. For each remaining issue:
      - Classify it (type, area, priority) using only labels that exist, and apply them with `gh issue edit <number> --add-label ...`.
      - Search for duplicates among open and recently closed issues (`gh issue list --search "<key words>" --state all`). If one is a clear duplicate, comment "Possible duplicate of #<n>" with one sentence of why. Do not close it.
      - If a bug report lacks what is needed to reproduce it (version, steps, expected vs actual), post one short, friendly comment listing exactly what is missing. Never comment otherwise.
      - When the code makes the cause obvious, note the likely files in your log (not in the issue).
   5. Write the triage log in Markdown: one line per issue with the labels applied, the duplicates found, the questions asked and the likely files.
      Complete the step with `--value triaged=<number of issues triaged>`.

2. 2. Morning digest

   Read the triage log from the previous step ({{steps.triage-new-issues.outputs.triaged}} issues triaged) and write the morning digest for the team, in Markdown, at most one screen:
   
   - **Urgent**: regressions, security reports and anything blocking users, with a one-line reason each.
   - **Quick wins**: issues whose fix looks small, with the likely files.
   - **Needs a decision**: feature requests or questions a maintainer should answer.
   - **Waiting for the reporter**: the issues where details were requested.
   
   Link every issue as #<number>. If nothing was triaged, say so in one line.

Secrets

• GITHUB_TOKEN: A GitHub token allowed to read the repository and label and comment on its issues (fine-grained "Issues read and write").

Suggested schedule: Every night at 2:00

FAQ

Will the agent create labels or close issues?

It only uses the labels that already exist in the repository, and closes nothing. Duplicates are linked with a comment so a maintainer can close them.

What if an issue was already triaged by a person?

Issues that already have a type label or an assignee are left alone.

Use this template (free) · All templates