update-plan
Skill60 starsChanged 34 days agoMITView on GitHub
Update an existing plan's status, todo list, and phase progress. Tracks what was done, updates completion status, and maintains the changelog. Use this skill during or after working on a plan phase to keep planning artifacts current.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- knwoop/clear-plan-skillstheir own version, first seen Oct 14, 2026
- sikbrad/spark-harness-templatetheir own version, first seen Jul 25, 2026
- kimgoetzke/coding-agent-configstheir own version, first seen Apr 30, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- knwoop/clear-plan-skills★ 9same name
- kimgoetzke/coding-agent-configs★ 2same name
- sikbrad/spark-harness-template★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/agents.mdAGENTS.md
- archive-legacy-docsSkill
- author-and-verify-implementation-planSkill
- browser-walkthroughSkill
- create-planSkill
- delegate-analysisSkill
- execute-work-packageSkill
- generate-docsSkill
- generate-handoverSkill
- report-environment-issueSkill
- resume-planSkill
- review-fixSkill
- review-implementation-planSkill
- review-implementationSkill
- review-planSkill
- update-docsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
42 rules. About 0 are common, 30 are distinctive, and 12 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈30
Distinctive · estimate
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
After completing work: to mark items and phases as done
- Distinctive: line 27
When blockers are discovered: to document them
- Distinctive: line 28
When the implementation approach changes: to update the implementation plan
- Distinctive: line 29
After a plan review: to apply accepted Remove / Merge / Simplify findings while keeping scope artifacts consistent
- Distinctive: line 30
When the user asks to "update the plan" or "mark phase as done"
- Very specific: line 36
Use doc-explorer only if verifying acceptance criteria requires codebase analysis (results are written to docs/).
- Distinctive: line 44
implementer: never used for plan maintenance.
- Very specific: line 52
Check plans/ directory for existing plans
- Very specific: line 53
If multiple plans exist, use the question tool to ask the user which plan
- Very specific: line 54
Read the plan's plan.md to understand the current status
- Very specific: line 55
Read todo.md to see current task state
- Distinctive: line 61
Add new items discovered during work
- Distinctive: line 66
Verify all acceptance criteria from the phase document are met
- Very specific: line 67
Update phase status in phases/phase-N.md frontmatter
- Very specific: line 68
Update the phases table in plan.md
- Distinctive: line 73
If the technical approach changed during implementation
- Very specific: line 74
Update the affected implementation/phase-N-impl.md
- Distinctive: line 75
Document the reason for the change
- Distinctive: line 76
Update any affected todo items
- Distinctive: line 86
Do not invent replacement phases, abstractions, infrastructure, requirements, or acceptance criteria
- Very specific: line 88
If execution has not started, remove obsolete pending phase artifacts after explicit approval.
- Distinctive: line 89
Keep the review artifact immutable
- Distinctive: line 90
Update references directly affected by the reduction, then stop.
- Distinctive: line 110
Always add a changelog entry:
- Distinctive: line 136
When a phase is completed and the next phase begins:
- Distinctive: line 140
Read the next phase's implementation plan
- Distinctive: line 142
Update the todo list's Phase Context section: update phase/implementation links, relevant docs, and latest handover reference
- Very specific: line 143
Update plan status in plan.md if needed
- Distinctive: line 144
Add changelog entry documenting the transition
- Very specific: line 149
Update plan status in plan.md frontmatter to completed
- Distinctive: line 150
Verify that the overall Definition of Done is met
- Distinctive: line 151
Add a final changelog entry: "Plan completed"
- Very specific: line 153
Use the question tool to confirm with the user that the plan is truly done
- Distinctive: line 167
Next: stop | primary decision required.
- Distinctive: line 171
Always read before writing: Read the current state of all affected files before making changes.
- Distinctive: line 172
Changelog is append-only: Never modify or remove existing changelog entries.
- Distinctive: line 173
Preserve history: When moving todo items between sections, maintain the completion date annotation.
- Distinctive: line 174
Atomic updates: Update all related files together (todo + phase + plan) - don't leave them in an inconsistent state.
- Distinctive: line 176
Track deviations: If the actual implementation deviated from the plan, document the deviation in the implementation plan rather than …
- Distinctive: line 178
File-based interface: All updates are written to plan files.
- Distinctive: line 180
Reduction over compensation: When fixing gold-plating, remove or simplify work.
- Distinctive: line 181
Review artifact immutability: Never modify the review that authorized remediation.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 fixAlways 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 startedStep 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)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

