# Dx Roadmap > Decompose an effort into an ordered list of vertical slices and write roadmap.md. - Skill: `dikamilo/dx-roadmap` (Agent Skill) - Install (CLI): `npx skillmds@latest add dikamilo/dx-roadmap` - Raw SKILL.md: https://api.skillmd.com/api/skills/dikamilo/dx-roadmap/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: dikamilo (https://skillmd.com/u/dikamilo) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/dikamilo/dx-roadmap --- # dx-roadmap Turn a researched, framed effort into an ordered sequence of **vertical slices** at `context/efforts//roadmap.md`. Each slice is a tracer bullet — end-to-end and demoable, not a horizontal layer — and maps to exactly one child change. This skill decomposes; it does **not** create the child changes (that is `dx-new`). **Guard.** Resolve `` under `context/efforts/`. If it is missing, tell the user to run `/dx-new` first. If the path is under `context/archive/`, refuse — an archived effort is done. If `roadmap.md` already exists, show it and ask before overwriting. ## 1 — Gather what upstream settled Read `effort.md` (note its `## Goal`). Then read the effort's shared upstream as context: every `research/.md`, and `frame.md` and `brainstorm.md` if present. A `brainstorm.md` reached this effort by passing the bundling test — its `## Conclusion & route` names the independently shippable capabilities it found, which is raw material for the slices below. Read `foundation/glossary.md` for naming (a one-line habit — no section). These are decisions already made; slice within them, don't re-litigate them. ## 2 — Draft candidate slices Decompose the goal into candidate slices — don't order or write them yet, just name and scope each: - **Feature effort** — each slice cuts end-to-end through every layer it touches (schema → api → ui), narrow but complete. Not "all the schema, then all the api." - **Refactor effort** (from `dx-refactor-discover`) — one slice per module deepening. - For each candidate, note its dependencies: which other candidates (if any) it needs in place first. Don't pad the count — a two-slice effort is fine. If it wants only one slice, it should have been a plain change; say so. ## 3 — Anchor interview (invoke `dx-references` with `interview`) Dependency alone rarely picks a unique order — several candidates are often equally free to go first. Two questions settle the ties that matter; ask them one at a time, each with a recommendation, per the interview loop: 1. **Tie-break bias.** What should decide between equally-eligible slices: surface the riskiest assumption first, ship the smallest demoable thing first, or follow strict dependency order with no further bias? Ground the recommendation in `frame.md`'s alternatives/risks if present. 2. **Lead slice.** Among the candidates with no unmet dependency, which should ship first? Skip this question if only one candidate qualifies. Skip either question outright if `frame.md` or `effort.md`'s `## Goal` already states the answer unambiguously — say what you inferred instead of asking. ## 4 — Order, confirm, then write Topologically sort candidates by dependency, then use the tie-break bias to order same-eligibility slices, placing the chosen lead slice first among them. Show the resulting numbered list (name → one-line why-here) and ask the user to confirm before writing — proceed / reorder or edit (free text) / cancel. Once confirmed, write `roadmap.md` in the `effort-md` shape (invoke `dx-references` with `effort-md`): each slice names exactly one child change id (the id `dx-new` will create, e.g. `payments-schema`, using glossary vocabulary), its one-line `why`, and a `next` line spelling out `` `/dx-new ` `` verbatim so it can be copy-pasted straight from the file. Do **not** write a maintained checklist: effort progress is **derived** by scanning each child change for `archived_at`, never a hand-checked box. There is nothing to flip here. Before printing the summary, sanity-check the written order: every slice's dependency appears earlier in the list, and the lead slice sits as early as its dependencies allow. Fix and rewrite if not. ## Done when `roadmap.md` exists with an ordered list of vertical slices, each linked to one child change id; `effort.md` is set to `status: scoped` and `updated: `. Then print and stop: ``` Roadmap written: context/efforts//roadmap.md — slices Next: /dx-new 1 — create the first slice's child change (also in roadmap.md's Slice 1 `next` line) ``` Stop. Do not create the child changes and do not chain into another skill.