Skip to main content

​
Saved Prompts, Run on Demand

A procedure is a prompt you write once and run whenever you want — “summarize my open PRs”, “draft my weekly update”, “triage my inbox”. It’s the on-demand twin of a heartbeat job: same execution machinery, but no schedule. A procedure never fires on its own — it sits on the Procedures page until you hit Play or ask Wolffish to run it. Saved procedures are plain data — a flat list of { title, prompt, mode, icon, projectId } records in brain/procedures.json. You never hand-edit that file. Manage them on the Procedures page, or just talk to Wolffish through its procedures capability (procedure_list, procedure_view, procedure_create, procedure_edit, procedure_delete, procedure_run).

​
Procedure or Automation?

Procedures and automations are siblings that share one runner but differ on what starts them. Choosing between them comes down to a single question: do you want to re-run this yourself, or have it run on a clock?
No timing words? It’s a procedure. “Every day”, “in 15 minutes”, “from now on” → that’s an automation. And a one-off you just want done right now is neither — it’s simply work Wolffish does in the moment; nothing gets saved.

​
The Procedures Page

Open Procedures from the app menu. Each saved procedure is a card showing its emoji icon, its title, when it was last edited, and a preview of its prompt — most-recently-edited on top. A procedure bound to a project shows the project’s name on its card. The page refreshes itself live when the store changes underneath it — ask Wolffish mid-chat to save or tweak a procedure and its card appears or updates in place. In the editor, the title is required — it’s the card’s name — and the prompt is a Markdown field. An emoji picker sets the card’s icon (every procedure has one; new ones start as 📋), and a project selector optionally binds the procedure to a project — its runs then execute with the project’s instructions and file list, and their conversations register under the project. Edits save automatically about half a second after you stop typing, so there’s no Save button, just Done.
A procedure carries no state of its own — there’s no “enabled” toggle and no last-run field. It’s inert data: it exists until you delete it, and “running” is a property of the run, not of the saved procedure.

​
Running a Procedure

Start a run two ways:
  • Play on the card, or
  • Ask Wolffish — “run my morning brief” — which fires it with procedure_run.
Either way, the prompt runs as a fresh, self-contained background conversation — never inside the chat you’re in — in the procedure’s own mode (its Single/Workflow stamp, not whatever your chat happens to be set to). That’s the one rule that shapes every procedure prompt: a run carries no memory of your current chat, so the prompt has to stand on its own. A run stays out of your way while it executes — deliberately so. A procedure is just a saved prompt doing its job, so there’s no card, no overlay, and nothing to dismiss; the app remains fully usable, and only a run that fails raises a toast naming what broke. The run is stamped with the procedure’s emoji and marked with a Play icon (origin tag [procedure]) in History, so you can spot whose run it was at a glance. Out of your way is not out of reach. Since v1.0.236 a procedure run creates its conversation before it starts rather than surfacing only once it’s over: the row appears in the conversations rail immediately with a live processing pulse, you can open it and watch the reply arrive, and the Stop button works on it — the same button, the same gesture, for a run nobody typed. Progress is written to disk while the run works, so quitting or crashing halfway leaves a real transcript instead of a bare prompt, and reopening the app mid-run finds it still going.
  • Sealed and isolated. A run is its own conversation — it can’t skew your live chat’s context, hijack its Stop button, or overwrite it. It runs to completion on its own; Wolffish doesn’t sit and wait on the result.
  • Up to three at once, coalesced. Procedure runs share the bounded run pool with automations — three concurrent slots. If every slot is busy, the run queues and starts the moment one frees — and asking to run the same procedure again while it’s in flight folds in rather than running twice.
A procedure run auto-approves every tool call — exactly like a heartbeat job, the Amygdala confirmation dialog is bypassed. A procedure that sends messages or deletes files does so with no one watching. Only save prompts that are safe to run unattended; the same What to Schedule decision layer applies here.

​
Through Wolffish

You rarely need to touch the page — just ask:
  • “Save this as a procedure” / “make a saved prompt for my weekly update” → creates one
  • “What procedures do I have?” → lists them by number and title
  • “Show me my inbox-triage procedure” → prints its full prompt
  • “Rename it to Weekly Update” / “tweak the prompt to also include GitHub” → edits title and/or prompt
  • “Run my morning brief” → fires it now, in the background
  • “Delete the PR summary procedure” → removes it (Wolffish confirms first)
Behind those phrasings is the procedures capability. You reference a procedure by its number (from the list), its exact title, or its id:
  • procedure_list — every procedure: number, title, one-line prompt preview
  • procedure_view — one procedure’s full title and complete prompt
  • procedure_create — save a new one (title + self-contained prompt, optional mode)
  • procedure_edit — change a title, prompt, and/or mode (omit whichever you keep)
  • procedure_delete — permanently remove one (asks you to confirm)
  • procedure_run — run one now, in a fresh background conversation
It’s fire-and-forget: procedure_run returns the moment the run is queued, so Wolffish keeps talking to you while the run does its thing. Don’t expect it to hand back the result mid-chat — check the run in History when it’s done.

​
Writing a Good Procedure Prompt

A run executes with Wolffish’s full toolset but no chat context, so write the prompt the way you’d brief yourself cold:
  • Be concrete and self-contained. “Summarize my unread GitHub notifications and append the digest to today’s daily log” beats “summarize them” — there’s no “them” in a fresh conversation.
  • Say where the output goes — a file, memory, or you on a channel (telegram_send / whatsapp_send, only if that channel is connected).
  • Keep it safe to run unattended. Favor read / summarize / notify over irreversible actions, since a run auto-approves its tool calls. Apply the What to Schedule checklist to a procedure just as you would to a scheduled job.

​
Where They Live

Procedures are stored as a single JSON file at brain/procedures.json in your workspace — a flat list, written atomically so it’s never torn by a crash or a concurrent edit. Each record is { id, title, prompt, mode, icon, projectId, createdAt, updatedAt } (projectId only when bound); the list shows the most-recently-edited first. Treat the file as managed data: create, edit, and delete through the page or through Wolffish rather than hand-editing it.

​
See Also

  • Heartbeat & Scheduling — the scheduled counterpart: run a prompt on a timer instead of on demand
  • What to Schedule — the safety decision layer for anything that runs unattended, procedures included
  • Built-in Capabilities — the procedures capability and its tools, listed alongside every other built-in
  • Self-Authoring Skills — when a repeated workflow deserves a real new tool, not just a saved prompt