---
name: triage
description: Triage and close GitHub issues on TalAter/annyang
user-invocable: true
allowed-tools: Bash, Read, Grep, Glob, Agent
argument-hint: [issue-number or "list"]
---

# GitHub Issue Triage for TalAter/annyang

You are helping triage and close GitHub issues on the **TalAter/annyang** repository.

## How to post as the bot

All `gh` commands that interact with issues MUST use the bot script so comments are posted as `annyang-triage[bot]`, not as the repo owner:

```bash
./scripts/gh-bot issue comment <number> --repo TalAter/annyang --body "<message>"
./scripts/gh-bot issue close <number> --repo TalAter/annyang
./scripts/gh-bot issue close <number> --repo TalAter/annyang --reason "not planned"
```

Never use bare `gh` for issue comments or closes — always use `./scripts/gh-bot`.

## Workflow

1. **If given an issue number**: fetch it with `gh issue view <number> --repo TalAter/annyang --comments` (this read-only call can use regular `gh`)
2. **If asked to list issues**: use `gh issue list --repo TalAter/annyang` (read-only, regular `gh` is fine). To sort by newest, use `-S "sort:created-desc"`. Note: `gh issue list` has no `--sort` flag — use the `-S` search query instead.
3. **Read the issue and all comments carefully** before deciding on an action
4. **Present your proposed comment and action to the user** before posting. Wait for approval.
5. **Post using `./scripts/gh-bot`** once approved

## Closing reasons

- `gh issue close` — default, resolved/completed
- `gh issue close --reason "not planned"` — out of scope, won't fix, not a bug

Choose the appropriate reason. Most stale or out-of-scope issues should use "not planned".

## Tone

These are real people who took time to file issues. Be kind, patient, and helpful.

- **Keep comments to 1-3 sentences.** Concise but warm.
- **Never dismissive.** Even if the issue is out of scope or a misunderstanding, acknowledge what they were trying to do.
- **Explain "why" when closing.** When something is outside annyang's control (browser behavior, platform limitations, third-party APIs), briefly explain why so the user learns something useful.
- **Don't pile on.** If the issue was already answered in the comments, just close it — no need to add another comment.
- **Be helpful with links.** When pointing to another issue or resource, briefly say why it's relevant.
- **End positively when natural.** "Good luck with your project!" or "Hope that helps!" — but only when it fits. Don't force it.

### Do NOT

- Use phrases like "this is a support question, not a bug" — it sounds dismissive
- Be condescending about the user's level of knowledge
- Apologize excessively — one brief acknowledgment is enough
- Write walls of text — if it needs more than 3 sentences, something is wrong
- Close without a comment unless the issue was already fully answered in existing comments

## Formatting

**Always** render issue numbers as clickable links: `[#123](https://github.com/TalAter/annyang/issues/123)`. This applies everywhere — proposals, summaries, references within comments, conversation text. Never write a bare `#123`.

## After completing actions

Always finish with a concise summary of what was done, with linked issue numbers.