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 automationsgit 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/automations)<a href="https://agentmods.dev/skills/thewolffish/wolffish-app/automations"><img src="https://agentmods.dev/badge/skills/thewolffish/wolffish-app/automations/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/thewolffish/wolffish-app/automations"><img src="https://agentmods.dev/badge/skills/thewolffish/wolffish-app/automations.svg" alt="Reviewed on agentmods" width="80" 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.00075 | $0.04444 |
| Opus 5 | $0.00037 | $0.02222 |
| Sonnet 5 | $0.00015 | $0.00889 |
| Haiku 4.5 | $0.00007 | $0.00444 |
Grade A, and why
automations 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.
How it starts
The opening of the file, as written. The whole thing — 316 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Automations — your heartbeat, on a schedule
You own this. Reach for it by intent whenever a need or issue touches a
schedule, a recurring job, or the heartbeat — even if the user never names it.
The automation_* tools are the supported way to change anything here; the
heartbeat.md file is for reading, not editing.
An automation is a scheduled job that runs by itself, with no one in the
chat. Together they are Wolffish's heartbeat: the background work that keeps
happening — a morning briefing at 08:00, an inbox sweep every 15 minutes, a
Friday retrospective. Each automation is one entry in
brain/brainstem/heartbeat.md: a ## <schedule> heading and, below it, a plain
instruction. The brainstem parses that file, registers a cron job for each
entry, and when a job fires it runs the instruction as a full autonomous agent
turn. You manage all of this with the automation_* tools — you never have to
hand-edit the file (though it's there if you want to read it).
An entry's body may START with setting-marker lines the user configured from
the Automations page — mode: single|workflow, project: <id> (the run gets
that project's context and its conversation registers under the project),
icon: <emoji> (the card/badge emoji), and the repeatable file: <path> /
dir: <path>. They are settings, not instruction text. The automation_*
tools preserve them automatically; if you ever edit the file directly, keep
them in place.
Files and working folders (file: / dir:). These are what the user
attached to an automation from the Automations page — the automation's own
reference material, exactly like a project's files:
file: <path>— a file COPIED into the workspace when it was attached, so it can't move out from under the run. When the automation fires, the run is told the name, size and path of each one and reads them with its own tools — the content is never pasted into the prompt. Attach and detach happen in the app, not here;automation_listshows what an automation carries.dir: <path>— a working folder. Each fire gets a fresh listing of its top level, the same way a working folder picked in chat does, so the run sees the folder as it is at that moment. This is where an automation that produces or consumes files should work.
When you write an instruction for an automation that has these, write it against them: say "the attached report", "the folder", and let the run look. Don't restate a file's contents into the prompt — it would go stale the moment the file changed, which is the whole reason the attachment exists.
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.
- 4d ago Changed · +7 lines d2979e97be89
- 9d ago First seen · 309 lines · 75 tokens per session scan A 7a28a5f93b46
automations is a skill published in the GitHub repository thewolffish/wolffish-app (5 stars, last pushed 2d ago), licensed MIT. It adds 75 tokens to every session and 4,444 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.
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.
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.