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/markmhendrickson/neotoma/endnpx skills add markmhendrickson/neotoma --skill endgit clone --depth 1 https://github.com/markmhendrickson/neotomaWrote 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/markmhendrickson/neotoma/end)<a href="https://agentmods.dev/skills/markmhendrickson/neotoma/end"><img src="https://agentmods.dev/badge/skills/markmhendrickson/neotoma/end.svg" alt="Measured on agentmods" 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 | $0.00053 | $0.01308 |
| Opus 5 | $0.00026 | $0.00654 |
| Sonnet 5 | $0.00011 | $0.00262 |
| Haiku 4.5 | $0.00005 | $0.00131 |
Grade A, and why
end 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 5d 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
end
Purpose
Run a session-close audit so nothing intended for follow-up or for Neotoma storage falls through the cracks. Distinct from /store-data (single per-record persistence) and /store-neotoma (full chat-transcript persistence): /end is the meta-step that decides which of those to invoke, and what remaining tasks need to be tracked.
Scope
Applies once per session, at user request. Does not modify code. Does file Neotoma entities (tasks, issues, plan updates) and may delegate to store-neotoma for chat persistence.
Phase 1: Remaining-work audit
Scan the current conversation and produce a structured list under these headings. List items only; do not write to disk yet.
- Open work — TODOs the assistant introduced, partial implementations, files modified but not verified, tests not run, lint/type-check skipped, PRs/commits not made.
- Decisions or proposals not acted on — recommendations the user accepted that have not been executed; designs sketched but not implemented.
- Trackable follow-ups — bugs noticed in passing, refactors deferred, documentation drift spotted, dependencies needing updates.
- External obligations — anything waiting on CI, a remote agent, a scheduled task, or a third party.
- User feedback or preferences expressed this session — candidates for memory (
feedback/user/project/reference).
For each item, classify: do-now (small enough to finish in this session), track (file as task/issue/plan entry), or drop (acknowledged, no action).
Phase 2: Neotoma storage audit
Determine what should be in Neotoma from this session and what already is.
- Per-turn lifecycle compliance — confirm each turn this session followed the Neotoma turn lifecycle (user message + assistant message stored, PART_OF + REFERS_TO edges). If any turn was skipped (which is forbidden), list it.
- Substantive entities surfaced — list every concrete entity discussed or produced this session: plans, decisions, skills, rules, bugs, contacts, transactions, events, code artifacts, etc. For each, check via
retrieve_entity_by_identifierorretrieve_entitieswhether it is already stored. - Files or attachments — any files the user pasted, screenshots, transcripts, or external URLs fetched. Check whether each has a corresponding
source_id/ content-addressed source row. - Memory-worthy facts — items that should be written to the auto-memory directory (
~/.claude/projects/.../memory/) per the auto-memory protocol.
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.
- 5d ago First seen · 86 lines · 53 tokens per session scan A d92390fd3f04
end is a skill published in the GitHub repository markmhendrickson/neotoma (31 stars, last pushed yesterday), licensed MIT. It adds 53 tokens to every session and 1,308 once invoked, about $0.0003 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
agent-memory
Teach cross-session memory patterns using MEMORY.md — what to save, how to organize it, how to maintain it over time, and how to structure topic files as memory grows. Works in any Claude Code project with no external dependencies. Trigger words: remember this, save for later, across sessions, persistent memory, don't…
agent-identity
Set up persistent agent identity files (AGENT.md, USER.md, MEMORY.md) and teach the agent to read them at every session start. Works in any Claude Code project — no external dependencies required. Trigger words: who am I, identity, remember me, agent name, my principles, who are you, what are my values.
remember
Routes user requests containing "remember", "recall", "checkpoint", "session", "todo", or "where were we" to the correct OpenEmpiric (OEM) MCP tool. Use when the user wants to persist, retrieve, or contextualize knowledge from project memory.
atomicmemory
Persistent semantic memory across Claude Code sessions — user preferences, project context, prior decisions, codebase facts. Call memorysearch before answering questions that reference past work. Call memoryingest after the user shares durable facts.
atomicmemory-cli
Use the installed AtomicMemory CLI for memory search, ingestion, packaging, diagnostics, and agent-safe JSON output.
core-memory
Use when working with Core Memory from OpenClaw, including finalized-turn writes, memory retrieval, bridge behavior, semantic bead fields, promotion, claims, associations, or integration debugging.