Create Roadmap Document

Create Roadmap Document

Repository continuity composition

For repository-scoped work, compose maintain-repository-continuity in Resume mode before selecting work. After an authorized repository change passes domain validation, compose Refresh and Verify immediately before presenting the pull request, and include the reconciled root CONTINUITY.md in the same change. A policy-permitted no-change or exemption result must be documented instead of fabricating an edit.

• Contribute: Roadmap item state, dependencies, evidence, validation, and next dependency-ready work
• Never claim: That planned work is complete or mutable tracker state is current without verification

Purpose

Create, update, or validate ROADMAP.md in conformance with architecture-roadmap.

Primary question:

How should this project evolve over time?

Use This Skill When

• the canonical document is missing
• strategic direction is scattered across issues, chat, or ad hoc notes
• capability evolution needs now/next/later/maybe framing
• major initiatives must be sequenced without overspecifying tasks or dates
• the roadmap needs review after purpose, vision, architecture, or methodology changed

Do Not Use This Skill For

• turning every future idea into a committed obligation
• building an issue queue, sprint plan, or implementation checklist
• writing release notes or exact delivery dates unless strategically necessary
• using tool choices or current tickets as the main roadmap structure
• redefining system or architecture ownership instead of consuming it

Required Inputs

Resolve:

• governing specification and version
• upstream purpose, vision, principles, foundations, system, architecture, and methodology documents
• current project posture and major capability gaps
• known strategic initiatives, constraints, and sequencing pressures
• uncertainties, dependencies, and open questions that affect long-horizon planning

Optional Inputs

Use when available:

• accepted ADRs with roadmap implications
• milestone or release history that reveals capability evolution
• market, user, or organizational evidence that changes strategic priority

Missing evidence must be recorded rather than invented.

Workflow

1. Read library/organization/specs/architecture/foundation/roadmap.spec.md.
2. Read the upstream vision and current architectural state before sequencing future work.
3. Identify capability evolution and strategic initiatives rather than individual tasks.
4. Group the future into clear horizons such as now, next, later, and maybe.
5. Keep optionality visible so speculative ideas do not become obligations.
6. Use dates only when strategically necessary; prefer outcomes, capabilities, and sequence.
7. If evidence conflicts or priority is unresolved, preserve the uncertainty and report provisional or blocked completion.
8. Draft or update ROADMAP.md using templates/ROADMAP.template.md.
9. Validate with references/validation-checklist.md and references/authoring-guide.md.

Output Contract

Produce or update:

• ROADMAP.md
• governing specification identifier and version
• explicit strategic horizons, initiatives, dependencies, and optional items
• assumptions, contradictions, and open questions
• validation results
• downstream review recommendations for issues, milestones, or planning artifacts

Boundaries

ROADMAP.md owns strategic sequencing, future capability evolution, and major phases or horizons.

It does not own sprint plans, issue queues, implementation steps, release notes, or architectural rationale already owned elsewhere.

Validation

Use references/validation-checklist.md for mandatory checks and references/authoring-guide.md for horizon, optionality, and anti-pattern guidance.

Blocked or Provisional Outcomes

If the vision is missing, if the future is only a tactical backlog, or if major strategic priorities are contradictory, do not pretend the roadmap is settled. Report whether the result is blocked, provisional, or limited to a clearly scoped horizon update.

Completion Criteria

• architecture-roadmap is identified as the governing specification.
• Required upstream evidence has been read.
• The primary question is answered directly.
• Strategic horizons and initiatives are explicit.
• Ownership boundaries with backlog, release, and architecture artifacts are respected.
• Optionality, assumptions, contradictions, and open questions are visible.
• Acceptance criteria and package-level validation checks pass.