em:update
Compatibility: If
AskUserQuestionis unavailable, present options as a numbered list and wait for the user's reply. IfTaskis unavailable, run parallel steps sequentially. Thecontext: forkandagent:frontmatter fields are Claude Code-specific — on OpenCode and VS Code Copilot they are ignored and the skill runs inline using the current model.
Update an EM plan or task milestone file. Two input modes:
- Annotations:
>and>>markers already written in plan files - Conversational: plain-language description of what to change
Annotation syntax
> instruction — standalone line, applies to the block immediately below it:
> rewrite this phase for the new auth approach
### Phase 2 - Authentication Migration
content >> instruction — inline suffix, applies to that line:
- Migrate user sessions >> mark done
- Add refresh token rotation >> remove this task
- Configure OAuth providers >> change to use env vars
Both can appear in plan.md and any tasks/*.md.
Step -1: Parse Flags
BG_MODE = true if --bg present
SILENT = true if --silent present
If BG_MODE=true: skip the confirmation in Step 1 and send a desktop notification after Step 5.
Step 0: Select Plan
Check for plan slug argument. If not provided:
- List
.codevoyant/em/plans/*/plan.mdsorted by modification time (most recent first) - If only one plan, auto-select it
- If multiple, use AskUserQuestion to present the list and ask the user to choose
- If none exist, inform user to run
/em:planfirst
Verify .codevoyant/em/plans/{slug}/plan.md exists. Set PLAN_DIR=".codevoyant/em/plans/{slug}".
Step 0.5: Determine Input Mode
Check the argument string and triggering message for a change description:
- If a non-slug argument is present (e.g.,
/em:update add observability to phase 3), treat everything after the slug asCHANGE_DESCRIPTION - If neither:
CHANGE_DESCRIPTIONis empty -> annotation mode
Set INPUT_MODE:
conversational—CHANGE_DESCRIPTIONis non-emptyannotations— scan plan files for>/>>markers- If both present, process conversational change first, then apply any annotations
Step 1: Process Conversational Change (if INPUT_MODE includes conversational)
Read plan.md and any relevant tasks/*.md to understand current structure.
Translate CHANGE_DESCRIPTION into concrete edits:
- Identify exactly which files are affected
- Determine what needs to change -- specific new text, removed lines, renamed sections
- Show a concise preview before applying:
Proposed changes for: "{CHANGE_DESCRIPTION}"
plan.md
+ Phase 2: add observability milestone under deliverables
tasks/develop.md
+ Task: "Set up distributed tracing with OpenTelemetry"
+ Failure mode: "Trace context lost across service boundaries"
Apply these changes?
If the change marks a task as done, after applying offer: "Push status update to Linear? (uses mcp__linear-server__save_issue with completed state)"
If BG_MODE=true, auto-apply without asking.
Otherwise use AskUserQuestion:
question: "Apply these changes to {slug}?"
header: "Roadmap Update"
multiSelect: false
options:
- label: "Apply"
description: "{first line of change summary}"
- label: "Adjust"
description: "Let me clarify what I want"
- label: "Cancel"
description: "Don't change the plan"
- Apply: proceed
- Adjust: ask "What should be different?", update proposed changes, re-confirm
- Cancel: exit
Step 2: Scan for Annotations
grep -rn "^>" {PLAN_DIR}/plan.md {PLAN_DIR}/tasks/ 2>/dev/null
grep -rn ">>" {PLAN_DIR}/plan.md {PLAN_DIR}/tasks/ 2>/dev/null
For each annotation, parse: FILE, LINE_NUM, CONTENT (before >>), INSTRUCTION.
If INPUT_MODE=annotations and no annotations found:
No annotations found in {slug}.
To annotate, edit plan.md or tasks/*.md directly:
> rewrite this section for the new approach -- applies to next block
- task name >> mark done -- applies to this line
Exit.
Step 3: Apply Each Annotation
Work bottom-to-top within each file so line numbers stay valid.
| Instruction | Action |
|---|---|
| "mark done", "done", "✓" | Mark the item complete |
| "remove", "delete", "drop" | Delete the target line(s) or section |
| "rewrite", "replace", "change to" | Rewrite per instruction |
| "add", "insert", "append" | Insert new content |
| "rename" | Update the label/title |
| Free-form | Interpret and apply as a direct edit |
Remove the annotation marker after applying. Log each change for the summary.
Step 4: Consistency Pass
After all changes:
- Verify task milestone files still exist:
{PLAN_DIR}/tasks/design.md,tasks/develop.md,tasks/deploy.md - Check milestone naming and task numbering is consistent throughout
plan.md - Verify "NOT this period" section still accurately reflects deferrals
Step 5: Validation Pass
Run 2 validation rounds autonomously — no user prompts.
For each round, launch parallel agents (model: claude-haiku-4-5-20251001, run_in_background: true):
Plan-level agent -- checks plan.md: milestones have objectives/deliverables/risks, assumptions listed.
Per-task-file agents -- one per tasks/*.md file touched in this update: each task has requirements, ACs, design/SA fields filled; tasks are specific and actionable.
Collect results (TaskOutput block: true). Auto-fix any NEEDS_IMPROVEMENT issues. Run round 2 after fixes. Cap at 3 rounds.
Step 6: Report
Updated: {slug}
Changes applied:
plan.md:24 -- added observability milestone
tasks/develop.md:8 -- added OpenTelemetry task
Validation: {N} rounds -- {PASS | X issues remain}
If an annotation was ambiguous or could not be applied:
⚠️ Skipped annotation at {file}:{line}: {reason}
Annotation preserved — resolve manually.
Step 7: Notify (--bg only)
If BG_MODE=true and SILENT=false:
npx @codevoyant/agent-kit notify --title "em:update complete" --message "Roadmap '{slug}' updated"
More from cloudvoyant/codevoyant
mem:help
Use when the user asks about available mem commands or needs help choosing a skill. Triggers on: \"mem help\", \"help mem\", \"what can mem do\", \"mem commands\", \"list mem skills\", \"mem reference\". Lists all mem commands with descriptions, arguments, and usage guidance.
14dev:plan
Use when planning architecture for a project or feature. Triggers on: "dev plan", "architecture plan", "plan architecture", "design architecture", "technical design", "system design for". Produces draft plan artifacts in .codevoyant/plans/{slug}/. Use /dev:approve to promote to docs/architecture/.
14em:review
Use when reviewing an engineering roadmap for quality and realism. Triggers on: "em review", "review roadmap", "sanity check roadmap", "em check", "review this plan". Checks capacity realism, dependency gaps, missing risks, and phasing quality. Auto-launched after em:plan.
13dev:explore
Use when researching technical approaches before building. Triggers on: "explore options", "what are my options for", "research approaches", "compare solutions", "dev explore", "generate proposals", "help me decide between". Runs parallel proposal generation via subagents and outputs to .codevoyant/explore/.
13em:plan
Use when planning a project (epic) or initiative with Linear as tracker.
13pm:plan
Plan a product roadmap for a quarter, half-year, or year. Writes a draft roadmap to .codevoyant/roadmaps/ using capability tiers. Triggers on: "pm plan", "product roadmap", "plan a roadmap", "quarterly roadmap", "annual plan".
13