菜单
Use when the user wants to plan a delivery batch, order waves of intents, ship a batch of intents in one go, track a named collection of intents toward a goal, or asks for a "roadmap". Creates and maintains a roadmap file, a delivery-side collection of intents (the counterpart to a release), separate from INDEX.md status tracking.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Wrap, finish, close, or mark an intent Done, delivered or abandoned. Use when completing or abandoning an intent, when a checklist reaches 100 percent and Exec is finished, or when asked to "wrap this up".
Autonomous intent delivery - agent takes over How and Exec. Use when user says "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes and user confirms autonomous execution. Requires an active intent in INDEX.md.
Use when diagnosing Plastic installation health, after updates, or when something seems broken. Runs checks and reports findings with fix options.
Use when updating Plastic. Runs the `update` verb, which reads the installed VERSION, derives its channel, queries npm dist-tags, and advances to the next version on that channel (or switches channel with a flag).
Use when merging a feature branch to main and tagging a release, bumping the version, or when the user says "release", "tag", or "ship it"
Use when completing or reviewing intents, reorganizing the index, or when the intent store needs maintenance. Examples: <example>Context: User has finished implementing a feature. user: "This intent is done, clean up the index" assistant: "I'll use the intent-curator to update the intent status and reorganize INDEX.md" <commentary>Intent lifecycle change triggers curator for index maintenance.</commentary></example> <example>Context: The intent store has grown and clusters need review. user: "Organize the intents" assistant: "I'll use the intent-curator to review clusters, flag orphans, and suggest connections" <commentary>Periodic maintenance of the Zettelkasten structure.</commentary></example>
| name | plastic-roadmap |
| description | Use when the user wants to plan a delivery batch, order waves of intents, ship a batch of intents in one go, track a named collection of intents toward a goal, or asks for a "roadmap". Creates and maintains a roadmap file, a delivery-side collection of intents (the counterpart to a release), separate from INDEX.md status tracking. |
| user-invocable | true |
A roadmap is a named, ordered, delivery-side collection of intents: the delivery-side counterpart
to a release (completion-side, CHANGELOG.md). It lives at roadmaps/{slug}.md, a sibling of
INDEX.md wherever INDEX.md lives: the global tier's ~/.plastic/roadmaps/ (beside
~/.plastic/INDEX.md), or a project's root, ~/.plastic/projects/{slug}/roadmaps/ (beside that
project's INDEX.md and project.yml). It never sits inside store/, which holds intent
directories, not project artifacts.
A roadmap file has four parts: a title/meta header, ## Goal (prose), ## Batches (ordered;
entries inside a batch are parallel-safe, batches run sequentially), and an append-only dated
## Log. A roadmap written before owner ruling 145 may instead use the legacy ## Waves heading;
reading accepts both, but every new roadmap is scaffolded with ## Batches, and an existing
roadmap file's heading is never renamed to migrate it. Each batch entry mirrors that intent's
status in INDEX.md (queued/delivering/delivered/abandoned/blocked).
INDEX.md is the single writer of intent status; on any conflict INDEX wins and the roadmap
entry is corrected to match.
The skill operates on the roadmap file directly via Read/Edit. The one deterministic helper it
uses is the savepoint ledger writer (scripts/roadmap-savepoint, append/rebuild); every verb's
closing step calls append after its Read/Edit, and the roadmap .md file itself stays
Read/Edit-only.
| Verb | When | Mechanics |
|---|---|---|
| Create | user wants to start a new roadmap / plan a delivery batch | references/operations.md#create |
| Add / reorder entries | user wants to add intents to a batch or resequence batches | references/operations.md#add--reorder-entries |
| Sync status mirror | an entry's status may be stale against INDEX | references/operations.md#sync-status-mirror |
| Append log line | a roadmap event just happened (created, batch done, closed) | references/operations.md#append-a-log-line |
| Read / consume | a human or a coordinator needs the roadmap's current state | references/operations.md#read--consume |
| Close / archive | the roadmap's ## Goal is reached | references/operations.md#close--archive |
See references/file-format.md for the exact entry-line shape, status vocabulary, checkbox/log
format, and a worked example. See references/operations.md for step-by-step mechanics of each
verb above.
roadmaps/ is a sibling of INDEX.md, wherever INDEX.md
lives.## Goal is a checkable prose condition read by a human or agent, not an executable checker.- [x] ... — delivered / - [ ] ... — <status>); a human
reading cold should see shipped/running/next within a minute. ## Log lines are one-sentence,
EM-to-CTO-voice, dated, and link each entry-intent's outcome.md (lossless-by-reference).INDEX.md's section
list or the intent frontmatter schema.roadmaps/archived/{slug}.md so roadmaps/ lists only live ones.roadmaps/{slug}.savepoint.md, the derived counterpart to the human ## Log; see
references/file-format.md for its shape and location.