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/ewebdzine/canonify/kickoffnpx skills add ewebdzine/canonify --skill kickoffgit clone --depth 1 https://github.com/ewebdzine/canonifyWrote 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/ewebdzine/canonify/kickoff)<a href="https://agentmods.dev/skills/ewebdzine/canonify/kickoff"><img src="https://agentmods.dev/badge/skills/ewebdzine/canonify/kickoff.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.00096 | $0.01117 |
| Opus 5 | $0.00048 | $0.00558 |
| Sonnet 5 | $0.00019 | $0.00223 |
| Haiku 4.5 | $0.00010 | $0.00112 |
Grade A, and why
kickoff 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Kickoff - set Canonify up in a repo
The onboarding gate. Run it ONCE in a fresh repo to stand up Canonify: a routing manifest
(CANONIFY.md), a docs/ corpus of canons, and - if you want - an initial set of canons drafted
from the codebase. It is an interactive wizard, not a silent file-creator.
Vocabulary: a canon is one canonical-pattern doc;
CANONIFY.mdis the manifest the gates (/canonify:plan/:build/:commit) route through. This gate creates both. The templates ship with the plugin at${CLAUDE_PLUGIN_ROOT}/templates/.
How to run
-
Detect.
- Confirm this is a git repo (Canonify's staleness checks rely on git).
- Already set up? If
CANONIFY.mdexists at the repo root, do NOT re-run the survey - report what is there and offer to reconfigure (add categories, seed more canons) instead. - Detect the stack to pre-fill sensible category names:
*.csproj/*.sln-> .NET;pyproject.toml/requirements.txt-> Python;package.json-> Node;go.mod-> Go; and so on. Categories are thedocs/<area>/folders (e.g. integrations, services, ui) - the project's own, not a fixed set.
-
Survey (ask a few; auto-detect the rest - keep it short):
- Auto-seed by scanning?
- Scan and propose (recommended): discover the surface (third-party integrations, internal services, key subsystems, UI patterns) and propose a list of canons to confirm before writing any.
- Start empty: just the skeleton; author canons later with
/canonify:create-canon.
- Scheduled doctor backstop? Yes (weekly) / no, run it manually / later. A periodic
/canonify:doctorsweep catches drift that accumulates between commits. - Confirm the stack + category folders you detected.
- Auto-seed by scanning?
-
Act.
- Write
CANONIFY.mdat the repo root from${CLAUDE_PLUGIN_ROOT}/templates/CANONIFY.md.template, filling in the detected categories. - Create the
docs/<category>/skeleton with a shortINDEX.mdper category. - Optionally copy
${CLAUDE_PLUGIN_ROOT}/templates/doc-style.mdinto the repo (e.g.docs/doc-style.md) so authors have the house-style locally. - If scanning: discover -> propose the canon list -> on confirm, run
/canonify:create-canonin bulk over each target (index the code, draft in the house-style, register inCANONIFY.md+ the categoryINDEX, stampverified). Show progress; never silently generate a large batch. - If scheduled doctor: set up a periodic
/canonify:doctorrun via the host's scheduling (a scheduled agent, or a repo cron) at the chosen cadence.
- Write
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 · 78 lines · 96 tokens per session scan A 353f01600c1a
kickoff is a skill published in the GitHub repository ewebdzine/canonify (23 stars, last pushed 2mo ago), licensed MIT. It adds 96 tokens to every session and 1,117 once invoked, about $0.0005 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…