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 niels-emmer/myace --skill plan-trackinggit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/niels-emmer/myace/plan-tracking)<a href="https://agentmods.dev/skills/niels-emmer/myace/plan-tracking"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/plan-tracking/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/niels-emmer/myace/plan-tracking"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/plan-tracking.svg" alt="Reviewed on agentmods" width="80" 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.00027 | $0.00658 |
| Opus 5 | $0.00014 | $0.00329 |
| Sonnet 5 | $0.00005 | $0.00132 |
| Haiku 4.5 | $0.00003 | $0.00066 |
Grade A, and why
Plan Tracking 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 9d 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 — 28 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
A multi-step task loses steps when its plan only exists in working memory — a subtask gets implicitly dropped, a "come back to this" note never gets revisited, or the scope quietly drifts without anyone noticing it drifted. Writing the plan down, and updating it as steps complete, makes progress and remaining work visible to the user and to any agent picking the task back up.
When to use it
Any task that will take more than roughly 3 sequential steps, spans multiple files or subsystems, or is likely to be interrupted and resumed. Not needed for a single, self-contained edit — the overhead isn't worth it for something that's done in one pass.
Steps / checklist
- Write the plan before starting, as a short ordered list of concrete steps — not vague phases like "implement the feature" but specific, checkable actions ("add the
visibilitycolumn + migration", "updateauthorize_accessto check it", "add tests for the new denial case"). If the environment has a structured todo/plan tool, use it; otherwise a plain markdown checklist in the working notes is fine. - Keep exactly one step marked in-progress at a time. This makes it obvious, at a glance, what's actually being worked on right now versus what's queued.
- Update state as you go, not in a batch at the end. Mark a step complete the moment it's actually done (built, run, confirmed) — not before, and not deferred until a later "cleanup the tracking" pass that may not happen.
- Surface scope changes explicitly. If a step turns out to need sub-steps that weren't in the original plan, add them to the visible plan rather than silently expanding scope and hoping it's fine.
- Never mark a step done that isn't. A step is complete when it's actually been verified to work, not when the code for it has been written. Marking things done prematurely defeats the entire purpose of tracking — it becomes a list that can't be trusted.
- On handoff or session end, leave the plan in a state a fresh reader can act on — what's done, what's in progress, what's still pending, and any blocker that's stalling progress. Pair this with the
memory-systemskill's decision log if the session is ending and the task isn't finished.
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.
- 9d ago First seen · 28 lines · 27 tokens per session scan A 81bdfd14b65c
Plan Tracking is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 5d ago), licensed MIT. It adds 27 tokens to every session and 658 once invoked, about $0.0001 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-09-03.
Other skills, from other repositories
idea
Use when capturing ONE new idea the user voices and wants recorded — "save this idea", "I have an idea", "log this idea", "/idea", "idea: ...". Creates a provenance-tracked folder (one folder per idea) in your ideas repo, dedups against an index, optionally mirrors to a GitHub Project view filtered by label:idea. NOT…
pm-feedback
A feedback-analysis aid that turns spreadsheet data, CSV files, pasted text, or review screenshots into organized product insights. It groups themes, identifies sentiment, examines trends and sources, calculates NPS, and extracts user types.
weekly-planning
A planning workflow that turns a completed weekly review and existing backlog into prioritized outcomes for one ISO calendar week.
gh-issues
Use when creating, searching, updating, or managing GitHub issues via CLI. Triggers: "issue", "create issue", "gh issue", "task tracking", "context", "handoff", "resume task", "session context", "save progress", "active tasks", "in-progress", "my tasks", "open issues". Covers: gh commands, bulk operations, JSON/jq…
pm-brainstorm
A structured brainstorming session for exploring a specific product problem or opportunity and narrowing the results to ideas worth pursuing.
ceo-council
Use when needing strategic project analysis from multiple independent expert perspectives. Triggers on business decisions, growth strategy, product direction, competitive analysis, or any situation where diverse C-level opinions reduce blind spots.