Plan evolve
Evolve a target to its next version — treat what shipped as v1, plan the next iteration. The target can be a plan, a repo, a system, a document, a feature, or a skill. If a v1 plan artifact exists, evolve it; if not, the current state of the target IS v1. Trigger: 'what would v2 look like', 'evolve this', 'what's next for this', 'next iteration of this', 'plan the next version'. Use plan-deep-dive to inspect the current state, plan-execute to run the new plan, and plan-cleanup to remove artifacts after execution.From its SKILL.md
npx -y skills add allemaar/open-skills --skill plan-evolveAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.8 KB, 689 tokens by cl100k_base, as published. Nobody here has run it
/plan-evolve
This is exactly what I wanted — can we evolve this to its next version? Treat what shipped as version 1, now plan version 2 — what would that be?
Frame
Something shipped. It worked. Now the user wants the next version of it.
The target can be anything that has a current state:
- A plan (
PLAN.mdor a plan file) - A repo, codebase, or system
- A document, spec, or skill
- A feature, product, or process
Version numbers are immaterial — "v1 → v2" is just shorthand for "what shipped → what's next."
Find v1
Identify what counts as v1:
- A
PLAN.mdor plan file in the current directory or.claude/plans/ - A plan or target the user points you to
- The current state of the target itself — if no plan artifact exists, what is built / written / deployed today is v1
If no plan was provided, do not block and do not demand one — the current state of the target is the floor you evolve from. Only ask the user if the target itself is ambiguous.
The work
V1 is the floor, not the ceiling. The next version means:
- What did v1 leave on the table?
- What would you do differently now that v1 exists?
- What new possibilities does v1 unlock that weren't visible before?
- Where did v1 make pragmatic compromises that the next version can resolve?
Don't re-plan from scratch. Evolve. V1's decisions are load-bearing until proven otherwise.
Output a next-version plan. If v1 was a plan, match its format — same structure, upgraded content. If v1 was a target with no plan, produce a plan in a clear phased format. Mark what's new, what changed, and what carries forward unchanged.
Hard rules
- Never discard v1 — it shipped, it earned its place
- Don't version-up for the sake of it — every change needs a reason
- If v1 had phases or structure, keep it unless there's a strong reason to restructure
- Ask the user what they valued most about v1 and what felt incomplete — don't assume
Downstream
Suggest the natural next command — these mirror the next-skills: front-matter:
/plan-deep-dive— inspect the new plan phase-by-phase/insight-critique— focused review of the proposed v2 plan/plan-execute— execute once approved
Human output. This skill's handler-facing output obeys the human-output contract (
human-output/SKILL.md).
Next skills. On completion, run the Next Skills protocol (
next-skills/SKILL.md): surface thenext-skillsrecommendations from front-matter for the caller to pick. Offer only — never auto-invoke.
Self-improvement. On completion, run the Self-Improvement Protocol (
self-improve/SKILL.md): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.