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/ne11nn/cantos-plugin/wrapnpx skills add ne11nn/cantos-plugin --skill wrapgit clone --depth 1 https://github.com/ne11nn/cantos-pluginWhat 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.00045 | $0.03412 |
| Opus 5 | $0.00023 | $0.01706 |
| Sonnet 5 | $0.00009 | $0.00682 |
| Haiku 4.5 | $0.00005 | $0.00341 |
Grade A, and why
wrap 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 2d 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 — 224 lines — stays where its author put it; the contents beside it link to each section on GitHub.
What This Skill Does
End-of-session review. You look at what happened this session, extract anything worth keeping, and update the right files. Then commit.
/wrap is the authoritative end-of-session marker. The user invokes it only when the work is done, reviewed, and approved — never as a mid-session checkpoint. Treat this as the definitive close: the work is final, which licenses decisive consolidation. Don't tentatively jot what happened — lock in the wholistic patches that make this session's lessons permanent and stop their whole class from recurring.
This is the permanent record of the session. Do it right.
Step 1 — Identify the Active Assistant
Look at how this session started. Which assistant morphed in? Options:
folio→ brain file:.assistants/folio/folio.mdlyren→ brain file:.assistants/lyren/lyren.mdpylon→ brain file:.assistants/pylon/pylon.mdcantos(no morph) → no single brain file; update system-level files only- any assistant added during setup → its brain file at
.assistants/<name>/<name>.md
Step 1.5 — Consume the Brain Update Queue
Before reviewing the live conversation, check .tmp/brain-update-queue.md. When the optional brain_update_hook.py Stop hook is wired (see its activation note in .assistants/cantos/cantos.md), it writes candidate rules there at session end; it never auto-applies them, so wrap is where they get routed. The hook is opt-in and may be unwired — in that case the file is simply absent and you review the conversation directly (this step still runs from Step 2 onward).
For each unprocessed entry in the queue:
- Read the candidate (assistant tag, proposed rule, evidence).
- Run it through the three-question routing test in Step 3 below — same as for any candidate surfaced from this session's conversation.
- If applied, move the entry to a
## Appliedsection at the bottom of the queue file with a one-line note on what was edited and where. - If discarded (the candidate was a false positive — wrap notes the reason), move it to a
## Discardedsection. - Never leave entries lingering in the queue — every wrap empties the unprocessed section.
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.
- 2d ago First seen · 224 lines · 45 tokens per session scan A 58486925c780
wrap is a skill published in the GitHub repository ne11nn/cantos-plugin (1 stars, last pushed 2d ago), licensed MIT. It adds 45 tokens to every session and 3,412 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
agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle…
python-package-management
Guide for managing packages in the Agent Framework Python monorepo, including creating new connector packages, versioning, and the lazy-loading pattern. Use this when adding, modifying, or releasing packages.
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
verify-samples-tool
How to use the verify-samples tool to run, verify, and manage sample definitions in the Agent Framework repository. Use this when adding, updating, or running sample verification.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.
build-and-test
How to build and test .NET projects in the Agent Framework repository. Use this when verifying or testing changes.