Backlog Refiner

Backlog Re-finer

Guide the user through a codebase-informed review of open GitHub issues for the repository that matches this workspace’s origin remote. The goal is a short list of likely-stale issues with evidence, not a blind “old = stale” report.

Core idea

An issue is not stale just because it is old or quiet. It is stale when investigation shows at least one of:

1. Already addressed — The behavior or work described is implemented, fixed, or otherwise satisfied in the current codebase (possibly in a different area than the ticket assumed).
2. Superseded approach — The ticket recommends or assumes a particular solution, but the project chose another path that solves the underlying problem; keeping the ticket open misrepresents current intent.
3. No longer applicable — Product/architecture/constraints changed; the ticket’s premise no longer holds.
4. Duplicate / replaced — Another issue, PR, or doc supersedes it (link the evidence).

If you cannot find evidence after reasonable code and history search, say so and treat the issue as undetermined rather than stale.

When to offer this workflow

Offer or follow this skill when:

• The user wants a backlog cleanup, stale issue list, or what can we close review.
• The user points at open issues in the GitHub repo that matches this git remote.
• The user suspects tickets describe the wrong solution compared to what the code does now.

Prerequisites and safety

• Authentication: Prefer the GitHub CLI (gh) if available and already logged in (gh auth status). Otherwise use a GITHUB_TOKEN (or GH_TOKEN) with at least repo scope for private repos, or public read access for public repos. Never paste tokens into chat, logs, or committed files.
• Rate limits: Use pagination and caching; avoid hammering the API. If listing hundreds of issues, summarize in batches or ask the user for filters (label, assignee, milestone, “updated before date”).
• Scope: Default to open issues only unless the user asks otherwise.

Step 1 — Resolve owner and repo from git

Run in the workspace root (or ask the user for the path):

git remote get-url origin

Parse the remote URL into owner and repo:

• https://github.com/OWNER/REPO.git → OWNER, REPO (strip .git).
• git@github.com:OWNER/REPO.git → same.

If there is no origin, or parsing fails, ask the user for OWNER/REPO explicitly. For this project, expect axelixlabs/axelix when the remote is the default GitHub URL.

Step 2 — Fetch open issues via GitHub API

Include issues only: GitHub’s “issues” listing includes pull requests. Filter out items that have a pull_request field in the API response, or use GraphQL/REST fields that distinguish issues.

Recommended (CLI):

gh api "repos/OWNER/REPO/issues?state=open&per_page=100" --paginate \
  --jq 'map(select(.pull_request == null))'

Use query parameters on GET requests (state, per_page, labels, etc.). Use -f only when the endpoint expects a body (for example POST).

Adjust OWNER/REPO or use /repos/{owner}/{repo}/issues with pagination in the tool the environment provides.

Capture for each issue at minimum: number, title, body, html_url, labels, assignees, created_at, updated_at, author, state (should be open).

Step 3 — Decide investigation order

Unless the user specifies otherwise:

1. Prefer issues least recently updated first (often higher stale risk given you will still verify in code).
2. Or prioritize issues the user names, or those with labels like tech-debt, bug, feature.