用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/dikamilo/dx-workflow --skill dx-roadmap命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | dx-roadmap |
| description | Decompose an effort into an ordered list of vertical slices and write roadmap.md. |
| disable-model-invocation | true |
| argument-hint | ["effort-id"] |
Turn a researched, framed effort into an ordered sequence of vertical slices at context/efforts/<effort-id>/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 <effort-id> 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.
Read effort.md (note its ## Goal). Then read the effort's shared upstream as context: every research/<topic>.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.
Decompose the goal into candidate slices — don't order or write them yet, just name and scope each:
dx-refactor-discover) — one slice per module deepening.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.
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:
frame.md's alternatives/risks if present.Skip either question outright if frame.md or effort.md's ## Goal already states the answer unambiguously — say what you inferred instead of asking.
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 <effort-id> <slice-n>` 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.
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: <today>. Then print and stop:
Roadmap written: context/efforts/<effort-id>/roadmap.md — <n> slices
Next: /dx-new <effort-id> 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.
基于 SOC 职业分类