Skill: Update Plan
What This Skill Does
Keeps planning artifacts synchronized with actual progress:
- Updates todo items (mark done, add new items, note blockers)
- Updates phase status (pending → in_progress → completed)
- Updates plan status and changelog
- Updates implementation plan if approach changed during work
- Prepares for next phase when current phase completes
When to Use
- During work on a plan phase: to track progress in real-time
- After completing work: to mark items and phases as done
- When blockers are discovered: to document them
- When the implementation approach changes: to update the implementation plan
- After a plan review: to apply accepted Remove / Merge / Simplify findings while keeping scope artifacts consistent
- When the user asks to "update the plan" or "mark phase as done"
Execution Model (Recommended)
- Preferred: the primary agent runs this skill and updates artifacts under
plans/<name>/. - Rationale: plan updates encode session decisions and current intent; the primary has the best access to that context.
- Use
doc-exploreronly if verifying acceptance criteria requires codebase analysis (results are written todocs/). - Optional (edge cases): delegate mechanical edits (bulk todo moves, large reshuffles) to
doc-explorerif needed.
Routing Matrix (Who does what)
- Writes: updates under
plans/<name>/includingplan.md,todo.md,phases/**, and (when needed)implementation/**. - Primary: preferred owner for updates (session decisions/intents live here).
- doc-explorer: optional helper for mechanical edits or codebase analysis to verify acceptance criteria.
- implementer: never used for plan maintenance.
Workflow
Step 1: Identify the Plan
Find the active plan:
- Check
plans/directory for existing plans - If multiple plans exist, use the
questiontool to ask the user which plan - Read the plan's
plan.mdto understand the current status - Read
todo.mdto see current task state
Step 2: Determine What to Update
Option A: Todo updates (most common)
- Mark completed items: move from Pending/In Progress to Completed
- Add new items discovered during work
- Mark blocked items with reason
- Move next items to In Progress
Option B: Phase completion
- Verify all acceptance criteria from the phase document are met
- Update phase status in
phases/phase-N.mdfrontmatter - Update the phases table in
plan.md - Populate todo list with next phase's items (from implementation plan)
- Add changelog entry
Option C: Implementation plan revision
- If the technical approach changed during implementation
- Update the affected
implementation/phase-N-impl.md - Document the reason for the change
- Update any affected todo items
Option D: Plan-level updates
- Requirements changed → update
plan.md - New risks identified → add to risks table
- Scope adjustment → update scope section
Option E: Plan-review remediation
- Inputs: immutable plan-review artifact, accepted finding IDs, explicitly rejected IDs with rationale, and user/primary decisions
- Apply accepted
Remove,Merge, andSimplifydispositions acrossplan.md, pending phase files,todo.md, and affected references - Do not invent replacement phases, abstractions, infrastructure, requirements, or acceptance criteria
- Record applied finding IDs and material scope decisions in the changelog
- If execution has not started, remove obsolete pending phase artifacts after explicit approval; if history exists, preserve it and mark the phase
skippedor superseded with a concise pointer - Keep the review artifact immutable
- Update references directly affected by the reduction, then stop; do not create a general plan-audit pass
Step 3: Apply Updates
Updating Todo List (todo.md)
### Completed
- [x] Implement user authentication endpoint (2025-02-14)
### In Progress
- [ ] Add input validation for login form
### Pending
- [ ] Write integration tests for auth flow
### Blocked
- [ ] Deploy to staging - waiting for CI pipeline fix
Always add a changelog entry:
### 2025-02-14
- Completed: Implement user authentication endpoint
- Started: Add input validation for login form
- Blocked: Deploy to staging (CI pipeline issue)
Updating Phase Status
In phases/phase-N.md frontmatter:
status: completed # was: in_progress
updated: "2025-02-14"
Updating Plan Changelog
In plan.md:
### 2025-02-14
- Phase 1 completed, Phase 2 started
Step 4: Phase Transition
When a phase is completed and the next phase begins:
- Mark current phase as
completed - Mark next phase as
in_progress - Read the next phase's implementation plan
- Populate the todo list with the next phase's implementation steps
- Update the todo list's Phase Context section: update phase/implementation links, relevant docs, and latest handover reference
- Update plan status in
plan.mdif needed - Add changelog entry documenting the transition
When the final phase is completed (Plan Completion):
- Mark the final phase as
completed - Update plan status in
plan.mdfrontmatter tocompleted - Verify that the overall Definition of Done is met
- Add a final changelog entry: "Plan completed"
- Clear the todo list's active phase header or add a "Plan Completed" note
- Use the
questiontool to confirm with the user that the plan is truly done
Step 5: Report
Summarize what was updated. If the phase is complete, highlight:
- What was achieved
- Whether all acceptance criteria were met
- What comes next
For plan-review remediation, return:
- Outcome: succeeded | partial | blocked
- Findings: applied and unresolved IDs
- Edits: changed artifacts with one-line descriptions
- Next: stop | primary decision required; no independent re-review was started
Rules
- Always read before writing: Read the current state of all affected files before making changes.
- Changelog is append-only: Never modify or remove existing changelog entries. Only add new entries.
- Preserve history: When moving todo items between sections, maintain the completion date annotation.
- Atomic updates: Update all related files together (todo + phase + plan) - don't leave them in an inconsistent state.
- Phase transitions are explicit: A phase is only
completedwhen all acceptance criteria are verified. Use thequestiontool to confirm with the user if unsure. - Track deviations: If the actual implementation deviated from the plan, document the deviation in the implementation plan rather than silently updating.
- Use subagents sparingly: Plan updates are typically small enough for the primary agent. Only use subagents if verifying acceptance criteria requires codebase analysis.
- File-based interface: All updates are written to plan files. Do not return updated content as chat messages.
- Review remediation is bounded: Apply accepted findings once and stop. Do not automatically re-review, continue until zero findings, or reopen rejected findings.
- Reduction over compensation: When fixing gold-plating, remove or simplify work. Do not add replacement architecture, infrastructure, tests, or documentation unless the confirmed objective requires it.
- Review artifact immutability: Never modify the review that authorized remediation; record decisions and resulting scope in the plan changelog.
Templates
This skill includes normative templates as bundled files. Only read the templates when processing them. Output MUST preserve template headings/frontmatter keys when updating plan artifacts:
tpl-todo.md- Expected structure for the todo listtpl-phase.md- Expected structure for phase documentstpl-implementation-plan.md- Expected structure for implementation planstpl-plan.md- Expected structure for the plan document (reference for changelog/phases table updates)