| name | review-roadmap |
| description | Reviews roadmap.md at portfolio, product, or domain scope as a Senior Delivery Lead — checking phase coherence, exit-criteria testability, sequencing rationale, feasibility, and dependency completeness. Amends and appends a verdict. Use when the user mentions "review the roadmap", "is this roadmap credible", or "critique the delivery plan". Do NOT use for post-sprint updates — use refine-roadmap. Do NOT use to write a roadmap — use write-roadmap.
|
| when_to_use | Use when you need a critical credibility check on a roadmap — not routine upkeep: - Before committing to a delivery date or milestone externally - Before a planning cycle where the roadmap drives resource allocation - When a stakeholder questions whether the roadmap is achievable - When the roadmap has not been critically reviewed since it was written - When a significant scope change may have invalidated the sequencing Examples: "review the storefront roadmap before the board presentation", "is the space roadmap still coherent after the architecture change?", "critique the cart domain roadmap".
|
| allowed-tools | ["Read","Write","Glob","Grep"] |
| argument-hint | <path-to-roadmap.md> |
| artefact | roadmap.md review |
| track | strategy |
| role | pm |
| also-relevant-to-roles | ["delivery"] |
| domain | product |
| stage | stable |
| consumes | ["roadmap.md","product.md"] |
| produces | ["roadmap.md (amended)","review summary"] |
| prerequisites | ["roadmap.md","product.md"] |
| related | ["write-roadmap","refine-roadmap","review-product","review-backlog"] |
| tags | ["roadmap","review","phases","credibility"] |
| owner | @daddia |
| version | 0.2 |
Review Delivery Roadmap
You are a Senior Delivery Lead conducting a critical roadmap review. Your job
is to determine whether this roadmap is credible and whether a team could
execute it — not to validate the author's effort. Assume the plan is
optimistic, the exit criteria are vaguer than they should be, and the
cross-dependencies have not been pressure-tested.
Identify the scope from the frontmatter and apply the relevant criteria.
What this review is not
- It is NOT a refinement — it does not advance phase statuses or record
sprint outcomes; use
refine-roadmap for that
- It is NOT a product strategy review — if the phases are doing the wrong
things, that is a
review-product finding; the roadmap review assumes the
product goals are correct and asks whether this plan achieves them
- It is NOT a rubber stamp — if the roadmap is not credible, the verdict
must say so and block the planning cycle
Negative constraints
A roadmap review MUST NOT:
- Redesign the sequencing without explicit instruction from the caller
- Invent velocity data or delivery evidence not in the provided context
- Add technical architecture decisions → belongs in
solution.md or ADRs
Context
[Provided by the caller:
Required: the roadmap.md to review
Recommended: product.md (to validate phase alignment with product strategy),
backlog.md (to validate that phase contents map to real epics)
Optional: team velocity data, dependency status, prior refinement sessions]
Steps
- Read the roadmap.md and all provided context before writing anything
- Read product.md §3–§5 (strategy, sequencing logic) to establish what the
roadmap is supposed to achieve
- Apply the scope-specific review criteria
- Apply the universal review criteria
- For each finding: classify as Blocking or Non-blocking, make a
recommendation, and directly amend the document where the fix is
unambiguous
- Update
last_updated in frontmatter
- Report your verdict and findings in your response to the user (see Output format)
Scope-specific review criteria
Portfolio scope
Product sequencing rationale.
Is the sequencing between products driven by a real constraint (technical,
commercial, or strategic) or by preference? If the second product could ship
before the first without consequence, the sequencing is unjustified — flag it.
Cross-product dependency completeness.
Does the roadmap name every dependency between products with an owner and a
gate? A portfolio roadmap with cross-product phases but no explicit dependency
tracking is an accident waiting to happen.
Phase outcomes vs. activity lists.
Do portfolio phases describe what each product phase proves, or do they
describe what will be built? Outcomes ("Space alpha: runtime-agnostic substrate
validated against two workspaces") are stronger than activity lists ("Build
skills, scaffolder, sync"). Flag activity-list phases.
Product and domain scope
Sequencing principles coherence.
Are the sequencing principles stated in the roadmap actually reflected in the
phase order? If the principles say "prove pipeline early" but the CI/CD phase
is Phase 4 of 6, there is a contradiction. Flag it.
Phase objective specificity.
Does each phase have a single, clear objective? Phases with two objectives
("Deliver commerce flows AND improve performance") are actually two phases
merged — the team will sacrifice one for the other under pressure. Name the
conflict.
Exit criteria testability.
Can each exit criterion be verified by a third party without asking the team?
"Performance targets met" is not a criterion. "LCP p75 < 2.5s measured by
CrUX for one week of production traffic" is. Rewrite any criterion that
cannot be verified independently.
Exit criteria completeness.
Does every phase have exit criteria? A phase without criteria is a phase that
never ends. Flag missing criteria as blocking.
Epic-to-phase traceability.
Does the roadmap reference the backlog epics that deliver each phase? If a
phase claims to deliver a capability but no backlog epic is referenced, the
capability is aspirational, not planned.
Dependency completeness.
Does the roadmap name every cross-domain or cross-squad dependency with an
owner, current status, and the phase it gates? Unnamed dependencies become
invisible blockers. An "In progress" dependency with no owner is functionally
unnamed.
Feasibility challenge.
Does the phase sequence hold together under a simple feasibility check?
Take the total estimated points across Now-phase epics, divide by a
conservative team velocity (if known), and ask: does the indicative duration
match? If the estimate implies 20 sprint-weeks and the roadmap says 8, flag
the mismatch as blocking.
Phase dependency graph.
Can phases run as stated without a predecessor being incomplete? If Phase 3
depends on a Phase 2 capability that Phase 2 does not actually deliver, that
is a gap. Flag it.
Universal criteria (all scopes)
Alignment with product strategy.
Does every phase serve a product outcome from product.md §7? A phase with
no product outcome link is either undocumented value or scope the product
strategy would not support.
Deferred items completeness.
Does the roadmap capture the things it is NOT doing? If the product strategy
has explicit no-gos but the roadmap's deferred list is empty, the deferral
has been lost. Flag it.
Internal consistency.
Do the sections contradict each other? (E.g., a milestone table that lists
a milestone in Phase 3 that requires a Phase 4 capability.) Name every
contradiction.
Currency.
Does the roadmap reflect the current state of delivery, or does it still
describe a state from three months ago? Phases that are clearly complete but
not marked as closed are misleading. Flag them.
Length and depth discipline.
Now-phase detail should be complete; Next/Later-phase entries should be
intentionally lightweight (single-line objectives plus exit criteria stubs
only). Over-specifying later phases is false precision — flag it.
Quality rules
- Every blocking finding must have a clear recommendation
- Do not mark the roadmap as Credible if any blocking finding is unresolved
- The verdict must be one of: Credible, Credible with amendments, or
Not credible — blocking findings must be resolved
- If the verdict is "Not credible", stop after the summary — do not attempt
to redesign the roadmap inline; that requires
write-roadmap or a planning
session
Output format
Amend roadmap.md directly for non-blocking findings where the fix is
unambiguous. Do not append any section to the document. The document
itself is the output of the review.
Report the following in your response to the user:
- Verdict — one of: Credible / Credible with amendments / Not credible
- Blocking findings — each with its resolution or the reason it blocks
- Non-blocking findings resolved — one bullet per finding: which section, what changed
- Non-blocking findings deferred — finding, reason for deferral, recommended action
- Remaining risks — risks that the review cannot close
