Agent Upstart

Cool things people are building with agents. Five links a day, one line each.

Playbooks · Coding agents

Triage a backlog of issues with an agent

A small team works through a pile of open issues with Copilot Chat and the GitHub CLI: every issue ends labelled, assigned, or closed with a reason.

Audience: Small team · Stack: A GitHub repo with a backlog of open issues, GitHub CLI installed and authenticated · Tool: GitHub CLI plus GitHub Copilot Chat for drafting triage notes

Before you start

Steps

  1. List the open backlog with gh issue list --state open, and narrow it with the filters the CLI supports, for example gh issue list --label bug or gh issue list --assignee @me. Work from the list, oldest first, not from memory of which issues feel urgent.
  2. For each issue, read it in full with gh issue view NUMBER before judging it. Skimmed triage is how real bugs get closed and vague requests get prioritised.
  3. Draft a triage note for the issue in Copilot Chat, grounded in the issue text: what the reporter actually describes, what is missing for anyone to act on it, and which of your labels fits. Treat the draft as a suggestion — check it against the issue before using any of it.
  4. Apply the decision with the CLI. Add a label with gh issue edit NUMBER --add-label "label-name", assign it with gh issue edit NUMBER --add-assignee @me, or hand a well-specified bug to Copilot as a coding agent with gh issue edit NUMBER --add-assignee "@copilot", both forms documented in the GitHub CLI manual. Several issue numbers can be passed to one edit command when the same change applies to all of them.
  5. If an issue is a duplicate, link it to the original in a comment with gh issue comment NUMBER --body "Duplicate of #ORIGINAL", then close it with gh issue close NUMBER --comment "Closing as a duplicate of #ORIGINAL". The comment forms are documented in the CLI manual; the duplicate judgement itself is yours.
  6. If an issue cannot be acted on, comment asking for the one missing piece — a reproduction, a version, an example — and label it as waiting. Do not close an issue for missing information without saying what is missing.
  7. At the end of the batch, re-run gh issue list --state open and count what changed: how many labelled, assigned, closed, and left waiting. Record those four numbers. A triage session that cannot report them did not finish.

Worked example

A small team faces sixty open issues and time-boxes a session to the twenty oldest. The list shows a crash report with steps to reproduce, a feature request with no use case, and three reports of the same login error. The crash report is labelled as a bug and assigned to a teammate; the feature request gets a comment asking for the use case and a waiting label; the three login reports are linked to the earliest one, and the two later ones are closed as duplicates with a comment naming the original. One well-specified crash is assigned to @copilot for a fix attempt. The session ends with the four numbers: twelve labelled, four assigned, three closed, one waiting — and forty issues still open, honestly counted, for the next session.

What can go wrong

Limits

Time and cost: NOT_MEASURED. This page gives no time or cost figure because the tool docs fetched for it state none that applies to this task.

Verification

Tier: AUTHOR_DOCS_VERIFIED · verified 2026-10-23. The workflow on this page was not run end to end in a sandbox for this page; every command, flag, and capability claim below was checked against an author doc or author repo fetched on 2026-10-23.

Cut from this page, with reason:

If a step here does not match what your installed tool shows, trust the tool's own docs for your version and stop before approving a change you cannot read.

Back to: Coding playbooks hub (../../guides/coding/) · Skills index (../../skills/)

Also: Small-team hub