issue-maintenance

Issue Maintenance

prioritize-issues reports; analyze-issue specs out one issue for implementation. This skill maintains — it mutates the backlog: labels, priority, and issue text. Five passes, one report.

0. Prerequisites

• gh authenticated for the target repo. If gh isn't installed (some hosted/cloud sessions), every step below has a GitHub MCP equivalent (mcp__github__list_issues, issue_read, issue_write, get_label) — same data, different transport. Say which you used in the report.
• No repo clone. Everything here is issue metadata (title, body, comments, labels) via gh issue — skip the mktemp -d / gh repo clone step entirely, unlike code-health-audit's and plain-language-audit's scheduled pattern. This skill never touches source files. The one exception is the label-convention doc in §4b, which is a single API file read, not a clone.

1. Discover the repo

gh repo view --json nameWithOwner -q .nameWithOwner   # if not specified

2. Fetch the backlog and the real label set

gh issue list --state open --limit 200 --json number,title,labels,createdAt,updatedAt,body,milestone,comments
gh label list

Paginate past 200. Cache the label list — every --add-label below must come from it verbatim. Never invent a label. If a label this workflow wants (needs-repro, needs-info, duplicate, any priority:*) doesn't exist in this repo, skip that operation for the whole run and say so once in the report ("not configured in this repo") — don't repeat the note per issue.

2b. Establish how this repo types its issues

Pass 2 groups label coverage by issue type, so the run needs to know what a "type" is here before it can group anything. Two mechanisms exist and repos use one or the other:

• GitHub native issue types (Bug / Feature / Task and custom ones). There is no gh issue type subcommand — since gh 2.94.0 issue types ride on the ordinary commands (--type on create/edit, a type field on list/view), and before that they were reachable only through the API. Detect them with GraphQL: gh api graphql -F owner='{owner}' -F name='{repo}' -f query='query($owner:String!,$name:String!){repository(owner:$owner,name:$name){issueTypes(first:10){nodes{id name}}}}' (gh fills {owner}/{repo} in -F values, never inside the query string). A null issueTypes or an empty nodes list means this repo has none, which is the ordinary answer for a personal-account repo — issue types are configured at organization level. Don't detect with gh api repos/{owner}/{repo}/issue-types: it can return 200 with Task / Bug / Feature on a repo that can't use them, where gh issue edit --type fails and the GraphQL mutation silently sets nothing. If the repo does have them, that is the typing mechanism: fetch the type per issue in the §2 bulk call.
• A type label convention — epic, bug, enhancement, user-story, documentation, and so on. The convention doc from §4b usually names these outright (Narraitor's .github/labels.md has a ## Type Labels section listing exactly six). Use that list as the type mapping rather than inventing one from whatever labels happen to look type-ish.