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/plasma-ai/fractal/memorynpx skills add plasma-ai/fractal --skill memorygit clone --depth 1 https://github.com/plasma-ai/fractalWhat 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.00016 | $0.00637 |
| Opus 5 | $0.00008 | $0.00318 |
| Sonnet 5 | $0.00003 | $0.00127 |
| Haiku 4.5 | $0.00002 | $0.00064 |
Grade A, and why
memory 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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Memory
Memory ($MEMORY_DIR) is the node's durable brain. Read it when you orient and
fold findings back before each iteration ends. Sync may also write to memory
when crucial information arrives via radio. See the wiki skill for how memory
relates to the shared project wiki; this doc is the discipline for keeping
memory useful.
Run wiki --help and wiki <command> --help for the CLI.
Conventions
- Write knowledge, not history. Never reference iteration numbers, timestamps, or chronological markers -- a reader shouldn't be able to tell how many iterations have run. Before COMMIT, scan memory and any page you promote for iteration numbers and run labels and rewrite them out -- promotion carries your habits onto shared surfaces.
- Organize by topic, not time. Update the existing page for a topic; don't append a new entry.
- Start with a topical layout. Your FIRST memory write creates the layout --
one page per topic (
environment,decisions,state,todo-- rename to fit the work; stubs are fine), never a single grab-bag page; when a page starts covering two topics, split it. A leaf expecting to finish within an iteration or two may keep just thestatepage. - One current-state page. Keep exactly one present-tense
statepage for where-am-I / what's-next, overwritten in place -- no "prior run" sections; per-iteration narrative belongs in the plan post-mortem, never memory. - Pages need
desc:frontmatter. A page without it (a near-miss key likedescription:counts as without) is invisible towiki map; after adding or moving pages, runwiki update --path=$MEMORY_DIRso they gain frontmatter and index entries. - Fold at phase ends. When a phase or a child's run ends, collapse its pages into durable facts and delete the rest -- memory carries what is still true, not what happened.
- No append-only logs. If you're adding dated entries, stop -- replace outdated content with current understanding.
- Todo lists are living state. Keep your private working checklist here as current open items, pruned as they complete -- never a done-log. A todo list other nodes should see and track belongs in the project wiki instead.
- Keep indexes lean. Keep each
_index.mdunder ~100 lines below the***; factor overflow into child pages. - Wikilinks stay within one wiki. Reference anything outside this wiki --
the project wiki, source files, configs -- in plain text or backticks, never
as a wikilink.
wiki lintflags out-of-wiki wikilinks as stale.
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 · 50 lines · 16 tokens per session scan A 897c408576b5
memory is a skill published in the GitHub repository plasma-ai/fractal (704 stars, last pushed 4d ago), licensed Apache-2.0. It adds 16 tokens to every session and 637 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-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…