What it does: writes the ROADMAP at roadmap_file: milestones in delivery order, each with an outcome someone can check. Once the user approves it, wkc-backlog turns a milestone into tickets. close <milestone> closes a milestone in the tracker once its tickets are finished and the person confirms its exit check.
When to use it: after wkc-architect approves a SPEC, or when a PRD or SPEC change, or a request, adds, moves, or drops milestone scope. A bug, a request inside a milestone's scope, or a change to tickets goes to wkc-backlog instead. Callers are people, a model acting on a person's request, and wkc-backlog, which invokes it for a change it classifies as a ROADMAP change, in a run as outside one. wkc-yolo reaches it only through wkc-backlog. A model runs it only when a person or wkc-yolo asked for that work. Model invocation approves nothing: outside a run, the ROADMAP stays Status: draft until the person approves it in the conversation, and a milestone closes only on the person's yes, in a run too.
Dependencies: prd_file, spec_file, and roadmap_file from docs/dev-agents/config.md, falling back to docs/dev-agents/PRD.md, SPEC.md, and ROADMAP.md when there is no config. The wkc-tracker skill for reads: list, show, and milestone, in its list and show forms; its one write is milestone close, from close <milestone>; and run show for a call with --run. The wkc-backlog skill for a milestone's tickets.
Input: free text: a change to the ROADMAP, such as a milestone to add, split, reorder, or drop. With nothing given, read the documents and the tracker, and write or update the ROADMAP. close <milestone>: close that milestone, by its exact tracker name; section 5 runs, and nothing else. --run <ref> marks a call from wkc-backlog in a wkc-yolo run and names its run config (section 6).
Output: the ROADMAP file and its status line, and a short report that names the next milestone for wkc-backlog. For close: the milestone closed, or what keeps it open. Under a run, the change and each decision it took, or parked with nothing written.

Writes only the ROADMAP, and closes a milestone only through section 5. Never creates, edits, links, or moves a ticket, and never reads or writes ticket files, gh, or Linear itself. Never edits the PRD or SPEC, their status lines included, and writes no code or config. Keep what the user wrote in the ROADMAP unless they ask to change it.

1. Read before asking

Read, in this order, whatever exists:

docs/dev-agents/config.md, the configured context_file, and the rule files in rules_dir.
The PRD, the SPEC, and the current ROADMAP.
The tracker's milestones, with wkc-tracker milestone list, and milestone show <name> for each milestone the change touches, so you know which milestones already have tickets. Use list and show only where a ticket's substance decides where scope belongs. If wkc-tracker cannot run, say why, and plan without it.

The SPEC is approved only when the line under its title reads Status: approved (YYYY-MM-DD), or Status: approved (YYYY-MM-DD, delegated: <run config ref>) when a run approved its last change. With no SPEC, or a draft one, stop and ask. Recommend finishing and approving it with wkc-architect first, and offer to plan from intent the user states here. If the user already said to go ahead, do not ask again. Approving the PRD or SPEC belongs to wkc-research and wkc-architect: never offer to approve one here.

Classify the request before writing:

A change to what the PRD or SPEC says, such as a new goal, a dropped requirement, or a different contract: name it, send it to wkc-research for the PRD or wkc-architect for the SPEC, and plan nothing that depends on it.
A bug, discovered work, a request inside an existing milestone's scope, or a change to existing tickets: that is wkc-backlog's work. Say so, offer to run it, and write nothing.
A change that adds, moves, or drops milestone scope, or reorders milestones: a ROADMAP change.

Where a milestone needs a decision the SPEC does not make, such as a missing contract field or an unchosen option, do not make it. Name it under the milestone's Depends on and in the report as work for wkc-architect; wkc-backlog turns it into a spike or decision ticket.

2. Write the ROADMAP

Milestones in the order they ship. Each is a slice someone can check working end to end, not a layer such as "database" or "API". Order by real dependencies first, then put what the SPEC's Risks and dependencies and Open unknowns flag as risky early. One milestone is a valid ROADMAP. Use the outline as a guide and drop lines that say nothing.

# <Product> ROADMAP

Status: draft

## M1: <name>
Outcome: <what a person can do or see once it ships>
Scope: <PRD goals and SPEC sections it delivers>
Depends on: <earlier milestones, outside dependencies>
Exit check: <how to tell it is done: a command, a demo, a measure>

## Changes   <!-- dated, newest first, for updates -->

The heading after ## is the milestone's name in the tracker too. The ROADMAP holds intent and order, never progress: no status, checkboxes, assignees, completion dates, or ticket lists. The tracker owns those, and wkc-tracker list <milestone> shows a milestone's tickets.

The ROADMAP states the current plan, like the PRD and SPEC. When updating it, rewrite only the affected milestones, then add a one-line Changes entry: the date, what changed and why, and what it replaced. Do not rename a milestone that already has tickets; the tracker cannot rename one. When a change moves scope out of a milestone that has tickets, name those tickets as work for wkc-backlog; never change them here.

3. Approval

Show the ROADMAP, or what changed in it, and for each changed milestone that already has tickets, its counts from milestone show and the ticket work the change leaves for wkc-backlog.

A question ends its turn. Number the options, put the recommended one first, and accept a digit:

Approve the ROADMAP, then draft tickets for with wkc-backlog.
Approve the ROADMAP only.
Change something first.

Option 1 names the first milestone in order whose scope has no tickets yet; with none, drop it.

The line under the title records approval: Status: draft until the user approves the ROADMAP, then Status: approved (YYYY-MM-DD) with that day's date. Write it only on approval in this conversation, or under a run as section 6 says. Changing a milestone's outcome, scope, dependencies, or exit check, or adding, removing, or reordering milestones, sets an approved ROADMAP back to Status: draft. Wording fixes and Changes entries keep the approval.

On option 1, write the status line, then invoke the wkc-backlog skill for that milestone. It drafts the tickets and asks for its own approval before it publishes anything.

4. Report

Say what changed in the ROADMAP and its status line, the open decisions for wkc-architect, the ticket work a change leaves for wkc-backlog, and the next milestone that needs tickets. Run wkc-backlog <milestone> when a milestone needs tickets.

5. Close a milestone

Read the config, the ROADMAP, and wkc-tracker milestone show <milestone>. A name the tracker cannot find is a stop that names the milestones that exist. No approved SPEC is needed.

While any ticket in it is backlog, ready, in-progress, or in-review, or has no clean status, stop: name each one from wkc-tracker list <milestone>, and write nothing.

Otherwise show the counts by status and the milestone's Exit check from the ROADMAP, or say it has none. Ask whether the exit check passed. You run no exit check, because some need AI sessions or a maintainer review. The question ends the turn:

Yes, the exit check passed: close .
No, keep it open.

Only on a yes in this conversation, call wkc-tracker milestone close <milestone>, and report what it says, including a backend with no milestone state. Never edit the ROADMAP for a close: the tracker owns progress.

6. Under a run

A call is unattended only when it passes --run <ref>; without it, the call is manual, whatever its text says. First read the run config with wkc-tracker run show <ref>. When that refuses, or the config does not say Planning: delegated, write nothing and return the reason. Such a call never ends a turn on a question, and never invokes wkc-backlog, which called it:

Wherever sections 1 to 3 would ask, decide from the PRD, the SPEC, the tracker, and the change's evidence, and return each decision with the section that settled it. Return work for another skill instead of offering it. When they leave a question undecided, write nothing and return parked: the question, what leaves it open, and who must answer.
Never delegated: a PRD or SPEC change, closing a milestone, and what a run's person controls: initial ticket IDs, admission ceilings, model selections, headless workers, grants, and phase renewal. A milestone a run adds or widens never adds its tickets to the run's Initial tickets:. A change that needs one, and any close, writes nothing and returns parked with Needs: a person.
Write the line under the title as Status: approved (YYYY-MM-DD, delegated: <ref>) with today's date, and a Changes entry that says run <ref> made it and gives the evidence and the reason. Commit nothing: wkc-yolo owns the planning pull request.

wkc-plan

wkc-plan