Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add allemaar/open-skills --skill plan-evolvegit clone --depth 1 https://github.com/allemaar/open-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/allemaar/open-skills/plan-evolve)<a href="https://agentmods.dev/skills/allemaar/open-skills/plan-evolve"><img src="https://agentmods.dev/badge/skills/allemaar/open-skills/plan-evolve.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00137 | $0.00976 |
| Opus 5 | $0.00068 | $0.00488 |
| Sonnet 5 | $0.00027 | $0.00195 |
| Haiku 4.5 | $0.00014 | $0.00098 |
Grade A, and why
plan-evolve scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/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:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 83 lines · 137 tokens per session scan A 3da459012250
plan-evolve is a skill published in the GitHub repository allemaar/open-skills (14 stars, last pushed 21d ago), licensed Apache-2.0. It adds 137 tokens to every session and 976 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
polis-protocol
Set up and run a self-improving, multi-vendor AI agent team with the Polis Protocol — a markdown polis/ folder where each agent is a citizen with a capability card, tasks are contracts routed to whoever has the best track record by a learning router, settled work files lessons that compound into team memory, and…
media
Skill "media" from ymxlx/polis-protocol, covering polis protocol: a self-optimizing city of agents, the core idea, when this skill is active, structure of a polis and the first thing to do every session.
_data
Skill "_data" from ymxlx/polis-protocol, covering polis protocol: a self-optimizing city of agents, the core idea, when this skill is active, structure of a polis and the first thing to do every session.
subagent-driven-development
Execute plans via delegatetask subagents (2-stage review).
mcporter
List, auth, and call MCP servers/tools from the terminal.
research-engineer
An uncompromising Academic Research Engineer. Operates with absolute scientific rigor, objective criticism, and zero flair. Focuses on theoretical correctness, formal verification, and optimal implementation across any required technology.