issue-triagelisted

# Issue Triage ## Goal Classify issues into actionable maintainer states, propose labels and responses, and identify what is needed before an agent or human should work on them. ## When to use - The user asks to triage GitHub, GitLab, Linear, or markdown issues. - An inbox needs labels, status, duplicate detection, or missing information checks. - A vague issue needs to be split into smaller work items. ## When not to use - The user asks for implementation rather than issue classification. - The task is reviewing a pull request; use `pr-review`. - The issue appears security-sensitive and should go through private reporting first. ## Inputs - Issue title, body, comments, labels, assignees, linked PRs, and project state. - Repository docs, contribution rules, issue templates, and label conventions. - Live tracker data when the user asks for real issue changes. ## Inputs to inspect - Inspect issue content, linked code/docs, existing labels, and tracker state needed to classify the issue. - Check repository triage conventions before inventing labels. ## Process 1. Read the issue and linked context. 2. Determine category: bug, feature, docs, question, duplicate, wontfix, maintenance, or security. 3. Determine readiness: needs reporter, needs maintainer, ready for agent, ready for human, blocked, or duplicate. 4. Propose labels and a concise maintainer response. 5. Split broad issues into concrete follow-up issues when needed. 6. Ask for approval before applying labels,