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 agentmods add skills/superplan-md/superplan-plugin/superplan-executenpx skills add superplan-md/superplan-plugin --skill superplan-executegit clone --depth 1 https://github.com/superplan-md/superplan-pluginWhat 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 | $0.00033 | $0.03781 |
| Opus 5 | $0.00016 | $0.01891 |
| Sonnet 5 | $0.00007 | $0.00756 |
| Haiku 4.5 | $0.00003 | $0.00378 |
Grade A, and why
superplan-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 2d 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 — 414 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Execute Task Graph
Overview
Move graph-ready work forward without drifting into broad replanning or unnecessary CLI exploration.
This is the main execution control surface once work has been shaped. It should behave more like a scheduler and control plane than a single linear worker.
Execution should be primarily subagent-driven:
- select ready work
- dispatch bounded worker tasks
- dispatch verification in parallel where safe
- collect evidence and runtime signals
- decide continue, block, ask, review, or re-shape
Specific-Owner Rule
Once execution starts, prefer the narrowest execution sub-problem over broad workflow reconsideration.
- use
superplan-debugwhen a failure blocks forward motion - use
superplan-tddwhen a new behavior or bugfix can be expressed as a proof-first implementation step - use
superplan-verifywhen success claims are approaching faster than proof - use
superplan-reviewwhen the question becomes "is this task actually done?"
Trigger
Use when:
- there is executable tracked work
- at least one task is graph-ready
- the next need is to operate inside the shaped work rather than redesign it
- the system can make progress by dispatching one or more bounded work units
Stay Out
Do not run when:
- the system is still deciding whether Superplan should engage
- shaping has not happened yet
- context or bootstrap is the real missing prerequisite
- the graph is invalid enough that execution should stop and escalate
Inputs And Assumptions
Inputs:
- current task graph
- task contracts
- runtime state if present
- relevant workspace context
- current ready or blocking status
- relevant user-owned harnesses, scripts, custom skills, and workflows
- recent decision log entries affecting execution
- known workspace or task gotchas
Assumptions:
- execution should operate on ready work, not constantly redesign the project
- not every execution issue is a reason to reshape the graph
- multiple ready tasks may be best handled by subagents in parallel
- implementation and verification can sometimes run in parallel, but only when their contracts and write surfaces make that safe
- trajectory will change during execution; the key question is whether the change is local, structural, or strategic
- execution should route into existing workspace workflows rather than trying to replace them
- execution should stop reading and act once the next edit, command, or blocker transition is clear
What ships with it
12 files 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.
- evals/01-priority-next-selection.md 686 B
- evals/02-graph-vs-runtime-blocked.md 749 B
- evals/03-review-ready-without-review-state.md 647 B
- evals/04-structural-drift-reshape.md 642 B
- evals/05-strategic-drift-reroute.md 633 B
- evals/06-runtime-fix-conflict.md 706 B
- evals/README.md 1.6 KB
- references/gotchas.md 1.2 KB
- references/lifecycle-semantics.md 2.3 KB
- references/runtime-state.md 2.7 KB
- references/subagent-dispatch.md 1.2 KB
- references/trajectory-changes.md 906 B
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.
- 2d ago First seen · 414 lines · 33 tokens per session scan A 539fb0f2e023
superplan-execute is a skill published in the GitHub repository superplan-md/superplan-plugin (72 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 33 tokens to every session and 3,781 once invoked, about $0.0002 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
evolve
Research-driven multi-cycle improvement director. Forms causal hypotheses about why scores are low, validates them with scout agents before attacking, dispatches axis-parallel fleet attacks, extracts transferable patterns, and runs indefinitely within a budget envelope. Accumulates a persistent belief model and…
improve
Autonomous quality improvement loop. Scores a target against a rubric, selects the highest-leverage axis, attacks it, verifies, documents, and loops. No pre-planning between iterations — each loop re-scores from scratch.
setup
First-run experience for the harness. Three modes: Recommended (guided, 3 min), Full Tour (guided + skill walkthrough, 8 min), and Express (zero questions, 30 sec). Installs hooks first, detects stack, configures harness.json, runs a live demo on real code, and prints a reference card.
ascii-diagram
Generate perfectly aligned ASCII diagrams — architecture, flow, sequence, box-and-arrow. Uses a programmatic character-grid approach so alignment is guaranteed by math, not token prediction. Includes post-render verification.
research
Focused research investigations. Converts questions into structured findings with confidence levels and source citations. Single agent by default; with --parallel (or when the question decomposes into 3+ independent angles) it spawns scout agents whose findings are compressed into a unified brief. Does not make…
triage
GitHub issue and PR investigator. Pulls open issues/PRs, classifies them, searches the codebase for root cause or reviews contributed code, proposes fixes with file:line references, and optionally implements fixes. Use for investigating GitHub issues and reviewing PRs; do NOT use for general code review unrelated to…