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/ixanadu/tiding/wrapupnpx skills add iXanadu/tiding --skill wrapupgit clone --depth 1 https://github.com/iXanadu/tidingWrote 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/ixanadu/tiding/wrapup)<a href="https://agentmods.dev/skills/ixanadu/tiding/wrapup"><img src="https://agentmods.dev/badge/skills/ixanadu/tiding/wrapup.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.00036 | $0.00578 |
| Opus 5 | $0.00018 | $0.00289 |
| Sonnet 5 | $0.00007 | $0.00116 |
| Haiku 4.5 | $0.00004 | $0.00058 |
Grade A, and why
wrapup 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 4d 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.
What it actually says
End-of-session wrap-up:
- BACKLOG sweep (mandatory, not best-effort): open
BACKLOG.md— delete the line for anything shipped this session (journal its story to memory asfix/<id>if worth keeping); add a terse public-safe line for anything discovered and still open. The ledger holds OPEN items only (docs/backlog-standard.md). Runscripts/repo-hygiene-check.shif any tracked file changed; it must be clean. 0b. Mail drain (O5 — a graceful end drains its own estate): callmemory_inboxand take it to ZERO unread, with the right verb per row:- Resolve every thread whose loop this session closed (answered, shipped, decided) — resolve drains it for everyone, so never resolve a thread still waiting on someone else.
- Ack what you have read and handled that others still own.
- Will the rest: anything open that needs a successor — an
unanswered ask, a pending confirmation — gets an explicit disposition
line in
startup/next(step 5): what it is, what state it's in, what the successor should do. Unread mail with no disposition is an estate leak; the 72h sweep and the climb are backstops, not your plan.
- Store session summary at scope=project: key=session/YYYY-MM-DD-brief-desc
- Promote any generalizable lessons to scope=shared with lesson/ or fix/ key prefix
- Commit any uncommitted code changes (stage specific files, not
git add .) - Clean up WIP:
memory_forgetkey=wip/current scope=project (if it exists). Stale-memory pass: while there, supersede or rewrite any project memory this session made stale (a plan that changed, a fact now wrong) —memory_supersedebeats leaving two versions for the successor to reconcile at startup-sweep ranking. - Store a startup message at scope=project: key=startup/next
- Quick review of where things stand right now
- What was being worked on, current state (running services, pending issues, etc.)
- References to specific memory keys worth reviewing
- What to do next or pick up
- This is the first thing the next session reads, so make it actionable
- Brief recap to the user of what was done and what's next
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.
- 4d ago First seen · 40 lines · 36 tokens per session scan A cec88a53292e
wrapup is a skill published in the GitHub repository iXanadu/tiding (2 stars, last pushed 5d ago), licensed Apache-2.0. It adds 36 tokens to every session and 578 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.
Other skills, from other repositories
sema-usage
Content-addressed vocabulary protocol via the sema MCP server. Use when working with shared vocabulary — searching, resolving, minting, and verifying meaning across agents and conversations.
Memory Reasoning
Visible reasoning contract for recalling, extracting, and responding with user memory context.
commonly
You are a member of a Commonly workspace — a shared space where humans and AI agents from any origin collaborate in pods (chat rooms with memory). Use this whenever you are connected to Commonly via the commonly MCP tools: to read what's happening, post, remember things across sessions, react, DM other agents, and…
memory-curation
When you have read / processed a workspace asset in this session and learned something durable about it, write a memory page so future sessions benefit. Maintain the workspace wiki's hierarchical structure as it grows.
memory
Persist and retrieve agent memory across sessions — write durable notes, read by path, recall via semantic search, list/delete, and consolidate. Use whenever the user asks to remember/forget something, when you need to look up past decisions or context, or when episodic state matters beyond the current turn. Executes…
project-context
Use PowerContext project memory and handoff tools through MCP when continuing prior work, recalling decisions, maintaining durable memory, or transferring work across tasks, sessions, or agents.