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-executegit 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-execute)<a href="https://agentmods.dev/skills/allemaar/open-skills/plan-execute"><img src="https://agentmods.dev/badge/skills/allemaar/open-skills/plan-execute.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.00092 | $0.01473 |
| Opus 5 | $0.00046 | $0.00737 |
| Sonnet 5 | $0.00018 | $0.00295 |
| Haiku 4.5 | $0.00009 | $0.00147 |
Grade A, and why
plan-execute 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 6d 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 — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/execute
Execute an approved plan with precision — follow the plan exactly, surface any judgment calls, declare completion explicitly.
Structured execution spec:
protocol.yon. Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the@STAMPdate.
Execution Protocol — no silent decisions, no silent drift. The plan was already reviewed. Surface anything not specified. Declare when done.
Valid Executable Plan
A plan is executable if it has all of the following:
- Numbered steps — each step is a discrete, concrete action (not prose intention)
- Concrete actions — each step names what to do, not what to achieve (e.g., "Edit
src/auth.tsto add JWT validation" not "add authentication") - At least one verifiable outcome — at least one step or verification entry that produces an observable, checkable result
If the plan does not meet this definition, the Phase 1 gate will reject it with the specific gap named.
Phase 1 — Alignment
- Load the approved plan using this priority order:
- Conversation context first — if a plan was produced in this conversation, use it
- Then
PLAN.mdin the project root - Then
implementation_plan.mdin the project root - If none found, see Gate below
- Confirm execution mode: no planning, no exploring, no scope additions.
Gate:
- No plan found → run
/plan-createfirst. Do not proceed. - Plan found but does not meet the Valid Executable Plan definition → state the specific gap (e.g., "no numbered steps", "no verifiable outcome") and ask the user to revise or invoke
/plan-create. Do not proceed.
Phase 2 — Action
Execute each step from the plan in order. Track progress against the plan as you go.
If drift is detected — environment, codebase, or dependencies differ from what the plan assumed — stop immediately. Do not self-correct. Do not improvise. State the specific discrepancy:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 6d ago First seen · 115 lines · 92 tokens per session scan A 73fd3b68ec87
plan-execute is a skill published in the GitHub repository allemaar/open-skills (14 stars, last pushed 20d ago), licensed Apache-2.0. It adds 92 tokens to every session and 1,473 once invoked, about $0.0005 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.