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/yogasw/wick/wick-notesnpx skills add yogasw/wick --skill wick-notesgit clone --depth 1 https://github.com/yogasw/wickWhat 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.00084 | $0.00895 |
| Opus 5 | $0.00042 | $0.00447 |
| Sonnet 5 | $0.00017 | $0.00179 |
| Haiku 4.5 | $0.00008 | $0.00089 |
Grade A, and why
wick-notes 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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Notes
Notes are the running record of what has been learned about a piece of work: findings, decisions, dead ends, and what to do next. They outlive the conversation that produced them, which is what lets a fresh session pick up where a derailed one left off.
Use the notes connector. It works with or without a ticket — a session
attached to a ticket reads and writes the ticket's notes (shared with every
other session on it); a session attached to nothing keeps its own.
Read them before you work
Your prompt tells you how many notes are waiting. The bodies are not in your prompt — deliberately, because a long-lived ticket would otherwise charge its whole history on every turn.
So when the pointer says there are notes and you are about to do real work rather than answer a passing question:
notes_list
No arguments needed: the scope defaults to this session, which resolves to the ticket's notes when it belongs to one. Reading them is cheaper than rediscovering what they say, and much cheaper than contradicting it.
Write one when you learn something
The test: would a later session, or a person, have to work this out again? If yes, write it down.
notes_add body="Retries fire every 30s because the queue re-enqueues on 5xx.
The 401 comes from the token refresh, not the webhook itself."
Worth a note: a root cause, a ruled-out hypothesis, a decision and why, a constraint you discovered, what you would do next, or a warning that a path leads nowhere. Not worth a note: a summary of what you just said in chat, or anything already obvious from the code.
Write one before handing off, and before saying a fresh session should take over — that is the moment the note is worth the most.
Checkable notes
For something with a done state, make it checkable and close it when it is done:
notes_add body="Confirm the fix on staging" checkable=true
notes_check note_id=<id> done=true
This is not a todo list with deadlines. It is a note that happens to have a box, so a reader can see what has and has not been confirmed.
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 · 103 lines · 84 tokens per session scan A 09f102a45019
wick-notes is a skill published in the GitHub repository yogasw/wick (5 stars, last pushed 5d ago), licensed MIT. It adds 84 tokens to every session and 895 once invoked, about $0.0004 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
omh-buzz
This is a Hermes-native buzz workflow skill.
redteam-api-detail-pack
Domain routing and boundary guidance for authorized API security testing, including BOLA/IDOR, authentication bypass, mass assignment, missing rate limits, and GraphQL issues. Use when a task belongs to the API testing domain and needs scope, evidence, pivot, or exit criteria.
redteam-postex-detail-pack
Domain routing and boundary guidance for authorized post-exploitation testing after initial access, including privilege escalation, persistence, lateral movement, data collection, and cleanup considerations. Use when a task belongs to the post-exploitation domain and needs scope, evidence, pivot, or exit criteria.
android-pentest
安卓应用渗透测试 — APK分析、Hook、自动化测试、运行态驱动、签名恢复、抓包分析.
n8n:nathan
Deploy a temporary n8n test instance (or generate a local docker run command) via the internal "Nathan" bot, from the repo instead of Slack. Use after opening a PR to offer the user a live test instance, or whenever someone asks to spin up / deploy a test instance for a branch.
workflow-builder
Load before calling build-workflow. Default path for all single-workflow work: new one-off workflows, existing-workflow edits, verification repairs, and workflow-local data tables. Write or edit a workspace source file, run workflow-sdk validate via workspaceexecutecommand, then call build-workflow with filePath. When…