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/nerds-odd-e/doughnut/slice-planningnpx skills add nerds-odd-e/doughnut --skill slice-planninggit clone --depth 1 https://github.com/nerds-odd-e/doughnutWhat 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.00083 | $0.02283 |
| Opus 5 | $0.00042 | $0.01141 |
| Sonnet 5 | $0.00017 | $0.00457 |
| Haiku 4.5 | $0.00008 | $0.00228 |
Grade A, and why
slice-planning 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 3d 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 — 222 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GSD phase is a roadmap capability (/gsd-plan-phase,
.planning/phases/NN-slug/). This skill writes slices inside a plan.
Use when planning, splitting an oversized slice, or when a fix /
make-test-pass attempt has overrun the breakdown time-box. If
/gsd-plan-phase output violates Behavior/Structure — rewrite until every
plan unit is one slice.
Output: Written plan under .planning/ + summary ending with
## SLICE PLAN WRITTEN.
Where to put plans (GSD-aligned):
| Location | Use |
|---|---|
.planning/phases/NN-slug/ |
GSD roadmap phases — *-CONTEXT.md, *-PLAN.md, *-SUMMARY.md, … |
.planning/quick/NNN-slug/ |
Ad-hoc plans not yet on the roadmap |
ongoing/ |
Legacy only — do not add new plans |
Primary executable file: *-PLAN.md or PLAN.md. Sub-decomposition: additional
*-PLAN.md in the same directory or clearly marked slice sections — each
still Behavior/Structure.
History: keep resume-useful status and brief learnings while in progress; when
the whole plan is done and shipped as code/permanent docs, clean up spent
planning history (.cursor/rules/planning.mdc).
Git does not use the Nix prefix.
| Elapsed | Action |
|---|---|
| > 5 min | Scrutinize the breakdown — too coarse? Prefer finer decompose, revert WIP, retry on a smaller slice |
| > 10 min | Hard trigger unless good reason (long suite, external wait): stop implementing, revert/stash WIP, cut a smaller Behavior/Structure slice |
For the hard trigger:
- Stop implementing.
- Summarize learnings (discoveries, blockers, partial progress).
git stash -m "WIP: <brief description>"(or revert uncommitted WIP).- Decompose remaining work (steps below).
- Write
.planning/quick/NNN-slug/PLAN.md(next freeNNN). Promote tophases/when roadmap-bound. - Report and wait (or execute the first smaller slice if already authorized).
Order scenarios from common / general toward more specific preconditions.
Solutions: First slices implement a narrow, concrete outcome. Later slices generalize or reuse only after real repetition — not a big generic framework up front.
Regression: If behavior already exists but has no automated test, prefer a dedicated slice: add a regression test and make it pass.
Extending tests: If similar behavior already has tests, extend them; avoid duplicate test code. Fold "test fails → pass" into the feature slice, or use a short slice where the new test fails first. Keep at most one intentionally failing test while driving a change.
Big refactor: If making the test pass needs a large structural change, plan that structure as its own slice before (or as the first cut of) the feature.
E2E-shaped slices: Each slice maps to an end-to-end scenario; different
slices may use different preconditions. Add or extend tests in capability-named
feature files (e.g. note_creation.feature) — never name files or scenarios after
the GSD phase.
Still too big: Split by one small part of the outcome per slice.
Time budget when sizing slices: Each Behavior/Structure unit should be
achievable by an agent/sub-agent in about 5 minutes wall-clock including
targeted test runs (planning.mdc). Prefer many small slices over ones that
routinely blow past 5–10 minutes.
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.
- 3d ago First seen · 222 lines · 83 tokens per session scan A 7c32f97b18cb
slice-planning is a skill published in the GitHub repository nerds-odd-e/doughnut (49 stars, last pushed 3d ago), licensed MIT. It adds 83 tokens to every session and 2,283 once invoked, about $0.0004 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…