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 skills add thewolffish/wolffish-app --skill proceduresgit clone --depth 1 https://github.com/thewolffish/wolffish-appWrote 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/thewolffish/wolffish-app/procedures)<a href="https://agentmods.dev/skills/thewolffish/wolffish-app/procedures"><img src="https://agentmods.dev/badge/skills/thewolffish/wolffish-app/procedures.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.1 | $0.00073 | $0.02245 |
| Opus 5 | $0.00036 | $0.01123 |
| Sonnet 5 | $0.00015 | $0.00449 |
| Haiku 4.5 | $0.00007 | $0.00225 |
Grade A, and why
procedures 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 8d 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 — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Procedures — saved prompts, run on demand
You own this. Reach for it by intent whenever a need or issue involves
saving, re-running, or organizing a reusable prompt — even if the user never
names it. The procedure_* tools manage procedures; don't route to a manual
prompt re-run when a saved one exists.
A procedure is a reusable prompt the user has saved to run whenever they
want — a "summarize my open PRs", a "draft my weekly update", a "triage my
inbox". Unlike an automation, a procedure has no
schedule: it does not fire on its own. It sits on the Procedures page until
someone runs it — the user by hitting Play, or you with procedure_run.
Each procedure is just { title, prompt }. You manage them with the
procedure_* tools; you never hand-edit storage.
Procedure vs automation — pick the right one
- Procedure — the user wants to save a prompt and run it manually, on demand, again and again. "Save this as a procedure", "make a saved prompt for X", "I want to be able to run this whenever." No timing words.
- Automation — the user wants something to happen on a schedule, by
itself: "every morning", "each day at 9", "in 15 minutes", "from now on".
That's the
automationscapability, not this one. - Neither — a one-off task the user wants done right now is just work you do now. Don't save a procedure for it unless they ask to keep it.
When in doubt, ask: does the user want to re-run this on demand later (procedure) or have it run automatically on a clock (automation)?
How a run works
procedure_run executes the saved prompt through the same machinery a
triggered automation uses:
- It runs to completion on its own. The prompt becomes a fresh, self- contained conversation — no chat history from here carries in. You (as that run) decide what tools to call and do the work end to end.
- It's a sealed background conversation that lands in history. The user can open it later to see exactly what ran.
- This conversation keeps going.
procedure_runis fire-and-forget: it returns the moment the run is queued, so you carry on with the user here. It does not hand you the run's result — don't wait for it. - Tool calls are auto-approved inside the run. Like an automation, a run acts unattended: a procedure that sends messages or deletes files will do so with no one watching. Only run prompts that are safe to execute unattended; confirm anything destructive with the user first.
- Up to three at once, coalesced. Runs go through the bounded run pool shared with automations (three concurrent slots): if every slot is busy, the procedure queues (and a second run of the same procedure while it's in flight is folded in, not run twice). If it didn't start immediately, say so — don't retry in a loop.
- Do NOT poll. You can't pause between tool calls, so looping to "watch" a run just burns turns and can't make it finish sooner. Fire it, tell the user it's running, and move on. If they later ask how it went, point them to the conversation in history.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 8d ago First seen · 191 lines · 73 tokens per session scan A a6fa135b5860
procedures is a skill published in the GitHub repository thewolffish/wolffish-app (5 stars, last pushed yesterday), licensed MIT. It adds 73 tokens to every session and 2,245 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
warpctrl
Control and inspect the currently running local Warp application with the warpctrl CLI. Use this skill whenever the user asks the agent to manipulate Warp's own windows, tabs, panes, sessions, input buffer, themes, or UI surfaces; open a file in Warp; inspect local Warp state; or explain how to invoke Warp Control…
change-keybinding
Customize Warp keyboard shortcuts (keybindings, keymappings) by editing the user's keybindings.yaml file. Use when the user asks to remap a key combination, rebind an action, change a shortcut, or remove a default keybinding (e.g. "change ctrl+space to ctrl+s", "rebind the command palette to cmd+p", "remove the…
create-tab-config
Create new Warp tab config TOML files from natural-language requests. Use when the user wants a new tab config, a new tab layout, or asks for a slash command to generate a tab config.
meeting-scheduler
Schedule a small meeting end-to-end: resolve attendee emails, check the owner's calendar for the slot, dedup-check, then create + email the Google Calendar invite. The mechanical core only — cross-person availability negotiation stays interactive.
morning-briefing
Generate a daily morning briefing: email, calendar, Discord, and news — delivered via voice or Discord DM.
relay
Write a handoff/continuity note for the NEXT Sutando session. Captures what was just in flight, what to check first, what might go wrong, and implicit context the structured snapshot doesn't carry. Drained into session-state.md by src/session-handoff.sh.