/antfu-issue-triage

name: antfu-issue-triage
description: Triage open issues and PRs of the current GitHub repo - find already-fixed, duplicate, and spam items, suggest labels, gauge demand from reactions and comments, then present a table of proposed actions and comments for confirmation before touching anything. Use when asked to triage, organize, clean up, or groom issues and PRs.
metadata:
  author: Anthony Fu
  version: "2026.10.23"

Issue Triage

Go through the open issues and PRs of the **current repo** (`gh repo view --json nameWithOwner`) and propose clean-up actions. Maintainers decide; the agent investigates.

Hard Rules

• **Read-only until confirmed.** Never comment, label, close, or edit before the user approves the action tables. Reads (`gh issue view`, `gh api` GET, `gh search`) are fine.
• **Every comment says it is automated by an agent.** End with a separate last line (blank line before it): `🤖 *Automated by an agent.*`
• **Comments are short and plain.** Write them in simple English (use the `simple-english` skill if available): 1-3 short sentences, active voice, no jargon, no filler. Write each comment fresh for the item. Do not reuse a fixed template. Always include the link (PR, commit, release, or canonical issue) that justifies the action.
• Only apply approved rows. If the user edits or drops rows, follow their edits exactly.
• Be conservative: when unsure, propose `keep open` (with labels if useful) instead of closing. Do not close items with active maintainer discussion, an open linked PR, or a milestone unless the user asks.
• Use plain hyphens; no em or en dashes.

Workflow

1. **Scope.** Confirm the repo and range (default: all open items; for large repos ask for a limit, label, or age filter). Fetch in bulk:

   gh issue list --state open --limit 200 --json number,title,body,author,labels,createdAt,updatedAt,comments,reactionGroups,url,milestone
   gh pr list --state open --limit 200 --json number,title,body,author,labels,isDraft,reviewDecision,closingIssuesReferences,url,reactionGroups
   gh label list --limit 200 --json name,description

2. **Learn the labels.** Read every label name and description. Only apply labels that exist. New labels (including `spam` if missing) go in the Labels table and are created only after approval. Check how maintainers labeled similar items (`gh issue list --state all --label <l>`). Compare the repo's labels with the Recommended Labels section below and note useful ones that are missing. 3. **Map references.** Collect cross-references from bodies, comments, and the timeline (`gh api repos/{owner}/{repo}/issues/{n}/timeline --paginate`): `#123`, URLs, `closes/fixes`, linked PRs, cross-repo links. Treat linked items as one cluster. Do not close an issue whose fix PR is still open. Do not mark linked items as duplicates of each other. 4. **Check each item:**

• **Already fixed/implemented.** Search merged PRs and commits (`gh pr list --state merged --search "<keywords>"`, `git log -i --grep`), changelog, docs, and current code. Find the first release with the fix (`git tag --contains <sha> --sort=version:refname | head -1`). Verify in the code, not just the title. A partial fix is not fixed: keep it open.
• **Duplicate.** Group by symptom or request, not wording. Search open and closed issues with distinctive text (`gh issue list --state all --search "<text>"`). Pick one canonical item: linked PR > maintainer response > best repro > most reactions > oldest. Close the others into it.
• **Spam.** Needs two or more strong signals: promo/SEO/crypto links, off-topic text, repeated identical posts, empty body with a link, bulk activity from a new account. Typos, terse text, wrong template, or non-English are not spam.
• **Labels.** Suggest existing labels for unlabeled or mislabeled items.
• **Low hanging fruit.** Items a maintainer can finish fast: PRs that are approved or ready with passing CI, small PRs with a clear change, typo or docs fixes, bugs with a clear repro and an obvious small fix, and requests that are small and well defined. Say why each is quick, and propose the `low hanging fruit` label for it. Skip items that are blocked, unclear, or large.
• **Demand.** Count positive reactions (👍 ❤️ 🎉 🚀), negative ones, distinct commenters, "+1" comments, and folded-in duplicates. Rate `High / Medium / Low` for the repo's size and show the raw numbers. Recent activity on an old item means it is still wanted.

5. **Present the plan** as the tables below, **Stop to ask for confirmation**. Run no write command in this turn. 6. **Execute** approved rows only, one at a time: comment, then label, then close. Stop on the first API error and report it. End with a done/failed table with links.

• Run one issue per command (comment, label, and close for that issue chained with `&&`). Do not batch many issues in one script or loop: bulk write commands can be blocked by the permission classifier. If a command is blocked, do not work around it. Split it into smaller per-issue commands, and tell the user.
• Create approved new labels first, in their own command.
• For rows the user adds after the tables (for example "also close #4"), write a short fresh comment in the same style and show it in the final report.

Recommended Labels

General labels. Map them to the repo's existing labels first (same meaning, different name). Never rename or delete existing labels.

| Group | Labels | Meaning | |-------|--------|---------| | Type | `bug`, `enhancement`, `documentation`, `regression` | What kind of item it is. `regression`: only appears after a new release. | | Triage state | `pending triage`, `needs reproduction` | Where the item is stuck. | | Resolution | `duplicate`, `invalid`, `wontfix`, `spam` | Why it was closed. | | Priority | `p1-chore`, `p2-nice-to-have`, `p2-edge-case`, `p3-minor-bug`, `p3-significant`, `p4-important`, `p5-urgent` | How much it matters. Descriptions: p5 breaks most users and n