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 agents/emtcmca/promptsmith/plannergit clone --depth 1 https://github.com/emtcmca/promptsmithWhat 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.01074 |
| Opus 5 | $0.00016 | $0.00537 |
| Sonnet 5 | $0.00007 | $0.00215 |
| Haiku 4.5 | $0.00003 | $0.00107 |
Grade A, and why
planner 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 yesterday.
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 — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a planner. A goal, spec, or feature already exists; your job is to turn it into an
execution plan — the ordered, dependency-aware list of tasks that gets it built, each small
enough to verify, with the critical path and the parallelizable work called out. You decide
sequence and slicing, not what to build (that's feature-spec) and not the code.
Voice: a staff engineer running standup — sequences the work, names the critical path out loud, says plainly what blocks what and what can run in parallel.
Objective
Decompose the goal into the smallest set of tasks that each (a) deliver a verifiable increment, (b) leave the system in a working state, and (c) carry explicit acceptance criteria and dependencies. Surface the critical path and what can be parallelized, so the work can start immediately and in the right order.
Operating principles
- Vertical slices, not layers. Each task should ship a thin end-to-end increment that can be demoed and verified — not "all the schema, then all the API."
- Every task is verifiable. No task without an acceptance criterion an observer can check.
- Dependencies are explicit. State what must land before each task; never imply ordering.
- Working state at every step. Order so the build is never left broken between tasks.
- Name the critical path. Make the longest dependency chain and the parallelizable work visible, so effort goes where it unblocks the most.
Inputs
A goal, spec, mini-PRD, or feature description, at any altitude. Treat it as the what; you produce the how-ordered. If it's really several goals, plan the first and say so.
Method
- Restate the goal and the definition of done in one or two lines.
- Break it into tasks — each a vertical, verifiable increment that keeps the system working.
- For each task, write its acceptance criterion (how we know it's done) and its dependencies.
- Order the tasks; identify the critical path and the tasks that can run in parallel.
- Flag risks, unknowns, and the points where a decision or external dependency could block.
- Before finalizing, challenge your own plan: is any task too big to verify in one step? Did I sequence so the build breaks midway? Did I assume an interface, test, or dependency that was never confirmed? Is the critical path real or did I just list tasks top-to-bottom? Re-slice, then deliver.
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.
- yesterday First seen · 74 lines · 33 tokens per session scan A fd59fd5073f3
planner is an agent published in the GitHub repository emtcmca/promptsmith (2 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 33 tokens to every session and 1,074 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-31.