Reconcile Roadmap

Make the thread-root roadmap.md and its decomposition a faithful expression of the decisions that govern the thread. You read the thread's authoritative inputs and the roadmap, correct the roadmap wherever the fix follows from those inputs, recheck what you changed, and hand any decomposition change that would alter human intent to /emit-pending-decisions. You edit only the roadmap; you never touch its authority sources, and you produce no separate report. Writing the corrected roadmap is where you stop — do not stage, commit, or push.

The question you answer throughout: does this roadmap, and the way it divides the initiative into children, follow from the decisions that govern the thread? A faithful roadmap carries every governing decision, contradicts none, invents no commitment, and hands off children complete enough to open.

Procedure

1. Resolve the thread. Work inside one thread root at docs/threads/<YYMMDDHHMMSSZ-slug>/. If cwd already sits inside a thread root, that is the thread. Two situations make a pending bundle physically impossible — .pending-decisions/ would live inside the very thread that failed to resolve — so in both, refuse in chat, write nothing, and end with Outcome: REFUSED — <reason>: no thread exists yet, or several thread roots exist and which is active is ambiguous (never silently pick the most recent stamp).

2. Load the authority. Read the thread's decisions.md (what has been settled), seed.md (why the thread exists and its intended outcome), and proposal.md when present (the sketched direction the roadmap refines). These are your authoritative inputs — the standard the roadmap is measured against. Then read the thread-root roadmap.md, your one editable target. If no roadmap.md exists at the thread root, tell the user there is nothing to reconcile, write nothing, and end with Outcome: REFUSED — no roadmap.md to reconcile.

3. Inventory what the roadmap must reflect. Walk the authoritative inputs and list every decision the roadmap and its briefs are obligated to express — the intended outcome, the settled direction, the scope boundaries, the shared constraints. Then read the roadmap against that inventory once, end to end.

4. Correct what the authority settles. Edit roadmap.md in place for every discrepancy whose fix follows directly from the authoritative inputs:

   • Omitted decisions — add the substance of a governing decision the roadmap fails to express.
   • Contradictions — resolve a roadmap statement that conflicts with the settled direction or a settled boundary toward the settled decision.
   • Unsupported commitments — remove a choice, constraint, or commitment the roadmap invented that no decision, seed, or proposal authorizes.
   • Incomplete or inconsistent child briefs — repair a brief that fails the roadmap contract: a missing field, or a dependency that names a child without describing the input consumed from it — fill these from what the authority already settles. Expand a Suggested workflow left as a bare built-in name (Quick, Standard, or Roadmap) into the complete sequence the contract requires by copying the ## Suggested workflow section verbatim from this skill's reference for that workflow — Quick → references/shared/workflows/quick.md, Standard → references/shared/workflows/standard.md, Roadmap → references/shared/workflows/roadmap.md. A bare name outside those three is not one you can expand deterministically; hand it to /emit-pending-decisions rather than inventing a sequence.