roadmap-tracker

Keeps the tracker true so a restarted coordinator can read it and continue the queue. It decides what lives where: roadmap issue, milestones, labels, closing comments, and the checks each round runs. The method itself (roadmap in the tracker, every new issue gets a milestone, close with a comment naming the PR, update the roadmap after a merge) is coordinator-method; the project's AGENTS.md, CONTRIBUTING.md and branch protection win over this skill. How Matt Pocock's skills create issues is matt-bridge; this skill only adds the tracker steps on top. Exact commands are in commands.md: read it when you need one. Tracker reads and audits are shell work with no model (model-mix, mechanical checks).

1. Facts and limits

• The repo and the roadmap issue number come from the project's memory or .claude/CLAUDE.md, not from this skill. If missing, find the pinned issue (gh issue list --json number,title,isPinned), record it in project memory, and say so.
• Tracker writes are public GitHub actions. Write only to repos the project owns, from the coordinator flow, and run the read-only form of a command first.
• Installed gh is 2.83.2 on this machine. It has no gh milestone command and no --blocked-by flags: use gh api (section 3 and 6). Check gh --version before assuming newer flags.
• Sub-issues and dependencies may not be enabled on every repo. Whether the person's repos have them is unverified: run the read-only GET in commands.md once per repo before relying on it.

2. The roadmap issue

• One pinned issue holds the roadmap: a checklist grouped by milestone, one line per ticket - [ ] #N title, with the PR once it exists ((PR #M)).
• A repo pins at most 3 issues. Read isPinned first, and never unpin the person's pins to make room: pick the roadmap's slot, or ask once.
• After a restart, read the roadmap issue and the open PRs, then continue the queue (coordinator-method).
• Update the body with read, edit, write: fetch it, change only the lines that moved, write it back with gh issue edit N --body-file. Fetch right before the write, since the person may have edited it.
• Keep the roadmap to state and links. Decisions and long text go in the ticket or the PR.

3. Milestones

• gh api only. A milestone must exist before an issue uses it, and gh takes it by name. Behavior on a missing name or on duplicate titles is unverified: list first, create if absent, never create a second one with the same title.
• Naming: follow the project's existing milestones. With none, this skill's default (not from coordinator-method) is one milestone per cycle or phase, phase-1-<slug>, or vX.Y when the project releases by version. Record the choice in the roadmap issue.
• Close a milestone when its last ticket closes, and give open ones a due_on only when the person gives a date.

4. Every issue gets a milestone

• Filing: gh issue create --milestone "<name>".
• Issues made by another skill: add the milestone right after creation, gh issue edit N --milestone "<name>". Issues from Matt's skills: matt-bridge §4 (milestone, HITL label, pin).
• Each round: list open issues with no milestone and fix every one. See commands.md.

5. Labels and the queue

Triage roles come from Matt's triage skill: two category roles (bug, enhancement) and five state roles (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix). A triaged issue carries one of each. The label strings in the repo come from docs/agents/triage-labels.md, written by setup-matt-pocock-skills: read it, create missing labels by the mapped names, never a duplicate under the default names. Its template maps only the state roles.

• Issues from Matt's skills: matt-bridge §4 (milestone, HITL label, pin).
• Comments the triage skill posts start with the line > *This was generated by AI during triage.*. Keep that line.
• Two state labels on one issue is a conflict: stop and ask the person, as the triage skill says.

6. Hierarchy and dependencies

• A slice's "Blocked by" body section is the source. Real links are optional and help picking unblocked work: sub-issues (up to 100 per parent, 8 levels, same owner) and blocked_by dependencies, both through gh api.
• The ids those endpoints take are the issue's REST id, not its number, sent with -F so it is an integer. See commands.md.
• Pick the next ticket from ready-for-agent issues in the current milestone whose blockers are closed.

7. After a merge

• Put a closing keyword in the PR body (Closes #N) when the PR targets the default branch. Keywords in a commit message close the issue but leave the PR out of its linked PRs. Against a non-default base nothing links.
• Whatever closed it, the ticket gets a comment naming the PR: gh issue close N --comment "Completed in #PR" --reason completed, or gh issue comment when it is already closed.
• Tick the line in the roadmap issue and add the PR number. Add any ticket the merge created or unblocked.
• Then launch what the merge unblocks (coordinator-method).

8. Boards

Project boards are optional. --project needs the project token scope, which only the person grants (gh auth refresh -s project). Never use a board as the source of truth over the roadmap issue.

Done when

• The roadmap issue is pinned, its checklist matches the open and closed tickets, and no merged ticket is still unchecked.
• Every open issue has a milestone and one state label, and the ready-for-agent list for the current milestone is the queue you act on.
• Each closed ticket has a comment naming the PR, or a "not planned" reason.
• No command wrote to the tracker without its read-only form run first.