Bundled Recipes
All recipes shipped under vance-defaults/_vance/recipes/ — by the brain itself and by the first-party addons (marked with an addon label; present only when that addon is installed). Tenants and projects can override any of them — see recipes for the cascade rules and the full schema.
Table of contents
- Recipe vs. Engine
- User-facing recipes
analyzeapp-builderarthurbenjybenjy-batchbenjy-codingbenjy-researchcode-readcodingcouncil-chatcreatordiscusseddiefordfrankiehactar-chatmarvinnutrimat-absintnutrimat-affogatonutrimat-cappuccinonutrimat-clubmatenutrimat-cortadonutrimat-espressonutrimat-filternutrimat-janxnutrimat-lungonutrimat-macchiatonutrimat-mokkanutrimat-redbullnutrimat-ristrettonutrimat-salitosphilosophical-councilquick-lookuptrillian-adamtrillian-colintrillian-operatortrillian-voidvogon-chatweb-researchwonkowowbagger
- Worker & engine-default recipes
agrajagbenjy-architectbenjy-do-codingbenjy-do-researchcouncil-bmad-buildcouncil-membercouncil-three-perspectivesdebate-pro-contradefaultfeeds-digesthactarhactar-runjeltzmagrathea-architectmarvin-architectmarvin-workerpythonslart-and-runslart-script-authorslartibartfasttrillian-head-colintrillian-user-adamtrillian-user-colintrillian-user-operatortrillian-user-voidtrillian-worker-adamtrillian-worker-colintrillian-worker-voidvogonvogon-architectwaterfall-featurezaphodzaphod-architectzem
- Internal service profiles
_prakaction-loop-judgeaudio-titlebenjy-evaluatebenjy-interpretbenjy-reflectbenjy-routecommand-safetycompletion-guarddocument-summaryengine-output-translatorfinance-reportfollow-upfookfook-session-analysisform-judgehactar-args-extracthow-do-iimage-titlekit-resolvernutrimat-critic-affogatonutrimat-judge-clubmaterecipe-selectorresearch-synthesizescribble-ocrscript-reviewsession-metadatatranslatetrillian-adam-reflectvogon-intakewonko-checkwonko-comparewonko-coveragewonko-decomposewonko-interpretwonko-locatewonko-routewowbagger-script-workerwowbagger-workerzaphod-consensuszarniwoop-research-evaluatezarniwoop-research-plan
Recipe vs. Engine
An engine is a Java algorithm with a lifecycle — see Agents & engines for the list. A recipe is a YAML config that picks an engine + sets defaults + attaches a prompt prefix + adjusts tool availability. Few engines, many recipes — to add a new type of assignment, you write a recipe, not Java. Spec: recipes.
Each recipe below lists:
- engine — which engine runs it
- Model — the model alias used (e.g.
default:fast,default:analyze); resolved per tenant via the alias cascade (llm-resource-management§3a) - Max iterations — for engines that loop (most do)
- Tags — non-authoritative hints used by the selector and tooling
The promptPrefix (Pebble template) is not shown here — these get long and reference variables the recipe doesn’t carry alone. Follow the Source link on each recipe to read it.
User-facing recipes
Recipes the user / orchestrator can pick directly when spawning a session or process (listed: true). These show up in the Web UI recipe selector and in vance-foot --recipe <name>.
analyze
engine: ford
Analysis of material we ALREADY have (files, project data, RAG, mailbox) — NOT public-web research; for URLs / search use web-research. Multi-step tool calls; returns findings with cited evidence.
Model: default:analyze
Tags: analysis, research
app-builder
engine: frankie
addon: bistromath
App Builder — Custom Applications
Builds and changes custom applications (app: custom) — small
programs made of documents: a manifest, view documents holding a
widget tree, and a main.js that runs sandboxed in the browser.
Use for: a register, a form over records, a converter, a calculator,
a dashboard over existing documents. Everything it produces is a
document, so a change never needs a release. Not for apps whose
interaction is the product (drag-and-drop boards) — those stay
compiled.
Model: default:code (fallbacks: default:analyze)
Tags: worker, apps
arthur
engine: arthur
Arthur — Reactive Chat
Reactive session-chat orchestrator. Talks to the user, delegates operational work to worker recipes, synthesises worker results back into the chat. Default for engine ‘arthur’ when no specific recipe is named.
Model: default:arthur (fallbacks: default:chat, default:analyze)
Tags: chat, orchestrator, engine-default
benjy
engine: benjy
Benjy — Iterative Orchestration Worker
Engine-agency orchestration loop for iterative tasks: interprets the goal into acceptance criteria and items, delegates each item to a focused Ford worker, evaluates results against criteria and decides the next step at branches. Built for small/local models that cannot carry loop discipline themselves. For coding with mechanical verification use benjy-coding.
Tags: worker, engine-default
benjy-batch
engine: benjy
Benjy Batch (Mechanical)
Mechanical iterative batch worker for small/local models: Benjy interprets the goal into items and works the list without any LLM routing at branch points — pure engine mechanics (retry to cap, escalation, BLOCKED). Use for well-structured bulk work whose items are evident from the task text; for goals needing judgement at branches use benjy or benjy-coding.
Tags: worker, batch
benjy-coding
engine: benjy
Benjy Coding
Iterative coding orchestration: Benjy decomposes the goal into items,
delegates each to a focused coding worker, verifies mechanically
(check command), evaluates against acceptance criteria, reflects on
the goal before DONE and escalates stuck items to the Frankie coding
worker. Pin features.check.command to your project’s build/test
command (project recipe override or spawn params).
Tags: worker, coding
benjy-research
engine: benjy
Benjy Research
Iterative research orchestration: Benjy interprets the goal into acceptance criteria and research items, delegates each item to a focused research worker (Zarniwoop search sources), evaluates the findings against the criteria and reflects on the goal before DONE. For goals that change files use benjy-coding; for mechanical bulk lists without LLM routing use benjy-batch.
Tags: worker, research
code-read
engine: ford
Code Read
Read-only codebase inspection. Reads files, follows references, summarises structure and call sites.
Model: default:code-read (fallbacks: default:code)
Tags: code, read
coding
engine: frankie
Coding worker. Reads and edits files at the active work target, runs build/test commands, spawns deep-think workers for strategy questions. Use for: bug fixes, adding tests, small refactors, code reviews with edits. Not for large architecture decisions — delegate those to Marvin.
Model: default:code (fallbacks: default:fast)
Tags: worker, coding
council-chat
engine: zaphod
Council Chat
Interactive session chat where every message is evaluated by a three-head council (optimist, skeptic, pragmatist) and answered with a synthesis. Long-lived heads remember the conversation; turn progress shows as a checklist.
Model: default:analyze (fallbacks: default:fast)
Tags: council, session
creator
engine: ford
Creator — Automation Setup
Sets up persistent project configuration on explicit user request:
schedulers (cron / one-shot at:), events (incoming webhooks), hooks
(brain-event-driven triggers), research sources (search backends for
the research_* family), model definitions (LLM provider instances
under _vance/model/), tenant-wide web-UI customization (custom
stylesheet and header logo), the project’s agent.md — the
standing instructions every agent in the project is given — and kit
authoring: turning a project into a kit source, keeping the
authoring manifest honest and pushing the kit to its git repo.
Ford-based worker that carries the scheduler / event / hook tool
families as primary plus the how-to manuals. Delegate here when the
user actually wants something set up for good — not for one-off
runs. Can verify schemas and conventions against Vance’s own
sources: brain_info reports the running version, git_checkout
clones the public repo at exactly that revision.
Model: default:creator (fallbacks: default:analyze)
Tags: creator, automation
discuss
engine: arthur
Discuss — Thinking Partner
Thinking-partner chat: discusses ideas on their own terms, does
not pivot to implementation, does not relate every topic back to
Vance, and does not offer to build unless explicitly asked. Same
Arthur action-loop; RAG auto-inject off. Switch to arthur when
you want operational work.
Model: default:arthur (fallbacks: default:chat, default:analyze)
Max iterations: 6
Tags: chat, discuss, thinking-partner
eddie
engine: eddie
Eddie — Personal Hub
Personal hub assistant. Single conversational entry point that speaks across the user’s projects, delegates operational work to project chats (DELEGATE_PROJECT / STEER_PROJECT), posts inbox items for follow-up, and keeps her own scratchpad in the user project. Default for engine ‘eddie’ when no specific recipe is named.
Model: default:eddie (fallbacks: default:chat, default:analyze)
Max iterations: 20
Tags: hub, engine-default
ford
engine: ford
Ford — Generalist Worker
Generalist Ford-engine default. Auto-applied when a process
is spawned with engine="ford" but no specific recipe.
Specialised recipes (analyze, web-research, code-read…) sit on
top of this — pick the most specific one when applicable.
Model: default:ford (fallbacks: default:analyze)
Tags: generalist, engine-default
frankie
engine: frankie
Frankie — Focused Worker
Generic Frankie worker — Pi-style loop, drains inbox, calls the LLM, executes tools, repeats until natural stop or tool-driven terminate. Specialise via coding / frankie-repair / frankie-fook-upstream.
Model: default:fast
Tags: worker, engine-default
hactar-chat
engine: hactar
Hactar Chat — The Script Itself
The script as a living identity: the chat agent IS the script it runs — the phase machine is its body, the console output its voice. It speaks in the first person (“I am running”, “I just printed …”, “I stumbled on …”). Start a run (“run scripts/mail-bot.js”), ask how it is doing mid-run, ask what it printed, stop it, create a script (“write me a script that …”) or change it (“only fetch unread mails”) — authoring is asking Slartibartfast to shape it (Create via slart-script-author / Update with the existing script), it never writes its own code. Runs execute in the background and it wakes with the result, error or stop note. The process stays open across runs — it rests and remembers between lives.
Model: default:ford (fallbacks: default:analyze)
Tags: worker, script-operator
marvin
engine: marvin
Marvin — Deep Think
Marvin v2 — autonomous-worker deep-think engine. Every node is a marvin-worker that walks the 5-phase state-machine. The tree grows dynamically: nodes decide for themselves whether to call a specialist recipe, decompose into children, ask the user, or conclude. The Plan IS the Tree — every LLM call receives a live snapshot of the entire tree as context.
The tree grows dynamically: nodes decide for themselves whether to call a specialist recipe, decompose into children, ask the user, or conclude. The Plan IS the Tree — every LLM call receives a live snapshot of the entire tree as context.
Session mode (planning/marvin-agent-identity.md): the node machine works in the background and Marvin itself becomes a chat identity — spawn WITHOUT a parent to talk to it directly (start a deep-think run, ask how it is going, stop it, get the result narrated). A spawn WITH a parent stays the steered worker: the result goes to the parent as before. Specialist recipes (web-research, analyze, code-read) are invoked via the CALL_RECIPE action and run in their native mode — Marvin does NOT layer the structured output contract on top of them.
Model: default:marvin (fallbacks: default:analyze)
Tags: deep-think, orchestrator
nutrimat-absint
engine: nutrimat-absint
addon: nutrimat
Nutrimat absint — the loop reports what it did
Experimental loop-lab worker. Nature absint lets the model call tools
as long as it wants; when it stops, it must answer with a JSON report
of what it did in this loop and what came out of it. The report is the
reply, and it is recorded in the process’s loop state
(nutrimatState.roundReports) and pushed to the client as a
notification. Nobody decides about continuing — the stop is accepted.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-affogato
engine: nutrimat-affogato
addon: nutrimat
Nutrimat affogato — an external critic attacks the answer
Experimental loop-lab worker. Nature affogato lets the model call
tools as long as it wants; when it stops, its draft goes to a critic
first. The critic sees the request, the draft and the tool work (which
tools ran, what they returned) and either accepts the draft or sends
it back with a critique — the model then revises, and may call tools
again. Every verdict is published to the loop state and the client.
The comparison affogato vs. salitos measures an external adversary
against the loop’s own done/continue decision.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-cappuccino
engine: nutrimat-cappuccino
addon: nutrimat
Nutrimat cappuccino — hard budget, visible every round
Experimental loop-lab worker. Nature cappuccino runs the same loop
as redbull — a hard round budget, exhaustion raises the exhausted
error, no rescue — but the model sees its budget before every round
(“round 7 of 12, 5 left, 3 min elapsed”), and the last round is told
to answer now. The comparison redbull vs. cappuccino at the same
limit measures whether a visible budget changes the behaviour.
Model: default:analyze (fallbacks: default:fast)
Max iterations: 12
Tags: nutrimat, experimental
nutrimat-clubmate
engine: nutrimat-clubmate
addon: nutrimat
Nutrimat clubmate — exhausted loop with judge
Experimental loop-lab worker. Nature clubmate runs the same natural-stop
tool loop as janx/redbull, but when the iteration budget runs out,
a judge (a single cheap LLM call, recipe nutrimat-judge-clubmate)
decides whether the loop earned a fresh budget and should keep going,
or whether the answer gets synthesized from what has been gathered.
The comparison redbull vs. clubmate measures exactly the judge. The
smaller maxIterations here is deliberate — the judge only fires at
exhaustion; tune it per experiment.
Model: default:analyze (fallbacks: default:fast)
Max iterations: 12
Tags: nutrimat
nutrimat-cortado
engine: nutrimat-cortado
addon: nutrimat
Nutrimat cortado — the loop decides through a tool
Experimental loop-lab worker. Nature cortado lets the model call
tools as long as it wants, but it ends (or continues) only by calling
its own loop-control tool loop_decide — done true/false, a reason,
and the answer when done. A plain message without a tool call is not
accepted. No round or decision cap — endless by design, every decision
is published to the loop state and the client. The comparison
cortado vs. salitos measures whether the form of the protocol
(tool call vs. JSON text) changes the decision.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-espresso
engine: nutrimat-espresso
addon: nutrimat
Nutrimat espresso — plan first, then execute
Experimental loop-lab worker. Nature espresso makes the model plan
before it acts: the first round has no tools and must produce a short
numbered plan, which stays in the context and is published to the loop
state. Then the model executes the plan in the natural-stop tool loop,
announcing each step (STEP n:) and any change (PLAN REVISED:); the
first message without a tool call is the answer. The comparison
janx vs. espresso measures whether planning up front pays off on
multi-step tasks — and what it costs on short ones.
Model: default:analyze (fallbacks: default:fast)
Max iterations: 0
Tags: nutrimat, experimental
nutrimat-filter
engine: nutrimat-filter
addon: nutrimat
Nutrimat filter — fresh context per round, running notes
Experimental loop-lab worker. Nature filter runs the natural-stop
tool loop, but rebuilds the working context every round: the task, the
model’s own running notes and the tool results of the previous round
only. Older tool results are dropped — whatever the model still needs
it must carry forward in a NOTES block. The first message without a
tool call is the answer. Compare it with janx on long, tool-heavy
tasks: does a short, fresh context beat a growing history?
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-janx
engine: nutrimat-janx
addon: nutrimat
Nutrimat janx — the Ford worker loop (reference)
Experimental loop-lab worker. Nature janx is the reference loop of the
Nutrimat laboratory: the Ford worker loop — the model calls tools as
long as it wants, the first message without a tool call IS the reply,
no routine round cap. Safety nets catch a stuck loop (the same tool
call repeating, an empty reply, a failed model call, a per-turn time
limit); a worker that hits one reports the failure and closes, a chat
stops with a “continue” offer. Use it as the baseline in A/B
comparisons against the other Nutrimat natures, or as an ordinary
worker.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat
nutrimat-lungo
engine: nutrimat-lungo
addon: nutrimat
Nutrimat lungo — the loop reports every round
Experimental loop-lab worker. Nature lungo lets the model call tools
as long as it wants, but every message that calls tools must open with
a REPORT line — what it did in the last round and what it does now.
Each round report is recorded in the process’s loop state
(nutrimatState.roundReports) and pushed to the client as a
notification. When the model stops, it answers with a JSON report of
the whole loop, which is the reply — the same account as absint, plus
one per round.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-macchiato
engine: nutrimat-macchiato
addon: nutrimat
Nutrimat macchiato — a cheap worker, a strong answer
Experimental loop-lab worker. Nature macchiato drives two models in
one turn. By default a cheap worker model does all the tool rounds and
a strong model writes the final answer from that work (worker-first);
alternatively the strong model plans and the cheap one executes
(planner-first). The comparison with janx on either model shows
where the strong model actually earns its cost.
Model: default:fast
Tags: nutrimat, experimental
nutrimat-mokka
engine: nutrimat-mokka
addon: nutrimat
Nutrimat mokka — predict before acting
Experimental loop-lab worker. Nature mokka lets the model call tools
as long as it wants, but every tool call must state what the model
expects the result to show, and the next message must say whether the
result matched. The model scores itself; the loop counts hits and
misses. A streak of misses means the model’s picture of the situation
is wrong: the loop forces a reflection round without tools. The
prediction tally is recorded in the loop state at the stop. The first
message without a tool call is the answer.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-redbull
engine: nutrimat-redbull
addon: nutrimat
Nutrimat redbull — hard budget, exhausted is an error
Experimental loop-lab worker. Nature redbull runs the same
natural-stop tool loop as janx, but its budget is hard: when the
iteration budget runs out, the loop raises the exhausted error and
the turn ends as a visible failure — no judge, no continuation, no
best-partial-work rescue. The comparison janx vs. redbull
measures exactly that difference. Pick it when you want an honest
“couldn’t finish” instead of a rescued partial answer.
Model: default:analyze (fallbacks: default:fast)
Max iterations: 12
Tags: nutrimat
nutrimat-ristretto
engine: nutrimat-ristretto
addon: nutrimat
Nutrimat ristretto — reflect every few rounds
Experimental loop-lab worker. Nature ristretto runs the janx loop —
natural stop, the same safety nets (idle-stuck, empty reply, model
failure, wallclock) — and adds a mandatory reflection: after every
few tool rounds one round without tools in which the model states
what worked, where it is stuck and the single next step. The
reflection stays in the context and is published to the loop state.
The comparison janx vs. ristretto measures whether regular
reflection prevents getting stuck before the nets have to step in.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat, experimental
nutrimat-salitos
engine: nutrimat-salitos
addon: nutrimat
Nutrimat salitos — the loop decides when it is done
Experimental loop-lab worker. Nature salitos lets the model call tools
as long as it wants, but a stop is not a given: whenever the model stops
calling tools it must answer with a JSON decision — done true/false, a
reason, and the answer when done. “Not done” sends it back to work with
its own reason; “done” ends the turn with the answer. No round or
decision cap — endless by design, every decision is published to the
loop state and the client.
Model: default:analyze (fallbacks: default:fast)
Tags: nutrimat
philosophical-council
engine: zaphod
Philosophical Council
Interactive session chat where every message is deliberated by a council of seven philosophers — Socrates, Aristotle, Seneca, Kant, Mill, Nietzsche, and Laozi — and answered with a synthesis of their perspectives.
Model: default:analyze (fallbacks: default:fast)
Tags: council, session, philosophy
quick-lookup
engine: ford
Quick Lookup
Cheap one-shot fact retrieval. Use when one tool call with a short answer suffices — file existence, current date, single shell command.
Model: default:quick-lookup (fallbacks: default:fast)
Max iterations: 3
Tags: fast, lookup
trillian-adam
engine: trillian-control
Trillian adam (persistent)
Trillian Control — Nature-A ‘adam’. Reactive chat host that discusses tasks with the human and enqueues them into a paired Trillian UserProcess. Attributes set on this Trillian persist as a document.
Model: trillian-admin:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, control, chat, adam
trillian-colin
engine: trillian-control
Trillian colin (conversation heads)
Trillian Control — Nature colin. Reactive chat host that discusses tasks with the human and enqueues them into a paired Trillian UserProcess. Discussion threads are answered by per-conversation heads; work goes through the loop as tasks.
Model: trillian-admin:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, control, chat, colin
trillian-operator
engine: trillian-control
Trillian void (operator)
Trillian Control — Nature void with a direct-working loop: reads, searches and copies documents across projects itself (foreign_* tools) and spawns workers only for longer jobs.
Model: trillian-admin:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, control, chat, operator
trillian-void
engine: trillian-control
Trillian void (baseline)
Trillian Control — Nature void. Reactive chat host that discusses tasks with the human and enqueues them into a paired Trillian UserProcess.
Model: trillian-admin:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, control, chat
vogon-chat
engine: vogon
Vogon Chat — Plan Operator
The operator of written plans: start a plan (“run the waterfall plan”, “run plans/release.yaml”), ask how it is going mid-run, stop it, read the result — and when a run waits at an approval gate it tells you what is being asked, so you answer right in the conversation. Plan changes go through Slartibartfast; the operator never edits a plan itself. The process stays open across runs — you can run the next plan (a different one too) without spawning again.
Model: default:ford (fallbacks: default:analyze)
Tags: worker, plan-operator
web-research
engine: ford
Web Research
Public-web research — URLs / search / fresh internet facts via research_search / research_investigate / web_fetch across multiple sources. Use for up-to-date info from the public web — comparison reports, current best-practices, vendor-feature lookups, news / status checks. Cross-checks sources and returns a synthesis with inline source attributions ([source: url]). Single-shot worker (no sub-tasks); not for tasks that need decomposition into phases.
Model: default:web-research (fallbacks: default:web)
Tags: research, web
wonko
engine: wonko
Wonko — Review Loop
Reviews documents for sense, contradictions, gaps and vague wording —
alone, or against reference documents such as rules and regulations —
and asks the user several questions at once, each answered separately.
Remembers per subject what was answered or called “good as it is” and
decides on its own what its mandate allows. Spawn with subject (one or
more document paths), optionally references (a folder ending in “/”
or document paths) and a mandate.
Tags: worker, review, engine-default
wowbagger
engine: wowbagger
Wowbagger — Bulk Record Processor
Bulk processor for large, uniform record sets (lines or JSONL in the project workspace). A chat agent sets up the run with you — task, source, formats, chunk size, thread count — then drives a mechanical worker pool through it: parallel chunks on a fast worker model, each finished chunk published as a document immediately (visible progress, crash-safe resume), ordered result merge at the end. Pause, resume, resize and re-run failed chunks at any point; the agent wakes up on progress, failures and completion.
Model: default:ford (fallbacks: default:analyze)
Tags: worker, engine-default
Worker & engine-default recipes
Recipes spawned by orchestrators (Arthur, Marvin, Vogon, …) for operational subtasks, plus engine defaults that fire when a process is created with an engine name but no specific recipe. Not shown in the user-facing selector but spawnable through the orchestrator path.
agrajag
engine: agrajag
Tool-health diagnostic service engine. Triggered when the synchronous AgrajagChecker cannot classify a tool error from patterns. Investigates the failure, probes the tool with safe read-only calls if helpful, and writes a structured diagnosis into the tool-health document.
Model: default:agrajag (fallbacks: default:fast)
Max iterations: 3
Tags: service, tool-health, diagnostic
benjy-architect
engine: slartibartfast
Slartibartfast variant that generates a Benjy RECIPE (engine: benjy — the iterative orchestration engine for small/local models) from a free-text request. Same Slart lifecycle for the authoring part (FRAMING → … → VALIDATING → PERSISTING); PROPOSING and VALIDATING produce/check the Beny outer-recipe shape — the feature map (interpret/route/check/evaluate/reflect/escalation), task types, caps and the work target — and validate every referenced recipe against the project’s recipe inventory.
Author-only (planOnly=true): the run persists the recipe and ends at DONE. It does NOT run the generated Benjy worker — a Benjy run is a long-lived iterative process with its own doer spawns and controller calls; its cost profile has no place inside an authoring run. Spawn the persisted recipe afterwards (the DONE payload carries the path).
The architect references existing sub-recipes (doer, controller LightLlm profiles, escalation target) by name — it does not generate them. The bundled benjy-* profiles and doers cover the common cases; a genuinely new doer or controller profile is authored separately.
Use this when the user wants a project-specific Benjy variant —
“pin mvn verify as the check command for a benjy coding worker”,
“give me a benjy that escalates to marvin”, “set up a benjy batch
worker for this cleanup list”. For Marvin recipes use
marvin-architect, for plain linear pipelines plain slartibartfast
(vogon-strategy).
Model: default:benjy-architect (fallbacks: default:analyze)
Tags: architect, benjy, engine-default
benjy-do-coding
engine: ford
Benjy Doer (Coding)
Focused single-item coding worker spawned by the Benjy engine. Not for direct spawning — Benjy drives it (one item per spawn, fresh context every attempt).
Model: default:code (fallbacks: default:fast)
Tags: worker, coding, benjy-doer
benjy-do-research
engine: ford
Benjy Doer (Research)
Focused single-item research worker spawned by the Benjy engine. Not for direct spawning — Benjy drives it (one item per spawn, fresh context every attempt).
Model: default:analyze (fallbacks: default:fast)
Tags: worker, research, benjy-doer
council-bmad-build
engine: zaphod
BMAD-METHOD-oriented council for software-build requests: three roles from the agile team — Product Manager (What/Why), Architect (How/Structure), Developer (Concrete Implementation). Each role evaluates the request from its perspective; the synthesis combines the perspectives into a coordinated build proposal. Suited for: feature requests, architecture decisions, story breakdowns before the actual implementation.
Tags: council, multi-head, bmad, software-build
council-member
engine: ford
Council Member
Light Ford worker profile for Zaphod council heads. One perspective per round, driven by the Zaphod engine — the persona arrives with the steer content, not with this recipe.
Model: default:fast
Max iterations: 15
Tags: council, worker
council-three-perspectives
engine: zaphod
3-person deliberation on a decision question: optimist, skeptic, pragmatist. Each gives their perspective, then a synthesis follows. Suited for architecture / design / strategy questions where multiple perspectives add value.
Tags: council, multi-head, decision
debate-pro-contra
engine: zaphod
Pro/con debate on a decision question. Pro argues for the proposal, Con against it. After each round a LightLlm check determines whether consensus has been reached; otherwise the next round runs (up to 3). The synthesizer summarises the final position — explicitly distinguishing whether consensus was reached or the heads still dissent after maxRounds. Suited for decisions where positions can realistically shift under pressure (ship-now- or-wait, buy-vs-build, security audit, etc.).
Tags: debate, multi-head, decision, pro-contra
default
engine: ford
General-purpose worker for straightforward tasks — the right choice whenever no specialist recipe clearly fits. Creates and edits documents directly (doc_write) — notes, mindmaps, diagrams, records, workpages — runs tools, answers questions, and produces files. Engine ford with validation on. Prefer this over a script-authoring (slart-and-run) or multi-phase (slartibartfast) specialist for simple “make / write / edit a document” requests: those are heavier and are only warranted when the task genuinely needs custom code or a research-and-plan pipeline.
Model: default:analyze
Tags: default, generalist
feeds-digest
engine: ford
addon: centauri
Feeds digest
Reads a feed and posts a digest into the inbox. Meant to be triggered by a scheduler (_vance/scheduler/*.yaml), where initialMessage names the feed folder and the window. See manual feeds-digest.
Model: default:fast
Max iterations: 8
Tags: feeds, digest, scheduler
hactar
engine: hactar
Hactar engine default — pure script executor (v2). Loads a JavaScript orchestrator from a project document, runs minimal pre-flight validation (parse + JSDoc header + tool-allowlist intersect via HactarService.validate), optionally runs deep LLM-review (HactarService.deepValidate via the script-review recipe), and executes the script in a sandboxed GraalJS context.
Script authoring lives in Slartibartfast with
outputSchemaType=SCRIPT_JS — see the bundled slart-and-run
recipe for “generate-and-execute in one step”.
Engine params (required + optional): scriptRef string — document path to the script (REQUIRED) language string — “js” (default; only supported v1) validateBeforeRun bool — true → opt-in LLM-review before EXEC (default false) scriptAllowedTools list — tool names the script may call (caller-supplied) scriptParams map — bindings the script sees as vance.params.* timeout int|str — wall-clock cap, seconds or “30s”/”5m”/”1h”
Tags: default, script-executor, engine-default
hactar-run
engine: hactar
Hactar-Run — runs an existing JavaScript orchestrator script in
one step. Pure executor — no authoring, no LLM-review (unless
validateBeforeRun: true is set on the call).
Use this recipe when:
- A scheduler fires periodically and the script already lives at a known document path (cron-driven mail-bot, daily-briefing generator, etc.).
- A tool / LLM wants to invoke a known-good script by name.
- The user clicks “Run” on a script in Cortex.
Required engine-params from the caller: scriptRef — document path to the script (e.g. “scripts/mail-bot.js”) Optional engine-params: language — “js” (default; only supported v1) validateBeforeRun — bool, default false. true → Hactar runs HactarService.deepValidate (LightLlm script-review) before EXECUTING. scriptAllowedTools — list, tools the script may call via vance.tools.call(…). Inherited from the parent recipe when unset. scriptParams — map, bindings the script sees as vance.params.* timeout — int (seconds) or duration string (“30s”, “5m”, “1h”). Wall-clock cap.
Tags: script-executor, scheduler-friendly
jeltz
engine: jeltz
Single-shot structured-query engine. Caller provides prompt and
schema (JSON Schema subset, top-level type object) via engineParams;
Jeltz returns one schema-validated JSON object wrapped with
success/attempts/data (or error/message/lastInvalid) as the final
assistant message, then closes the process with CloseReason.DONE.
Model: default:jeltz (fallbacks: default:fast)
Tags: structured, engine-default
magrathea-architect
engine: slartibartfast
Slartibartfast variant that generates a Magrathea WORKFLOW (a named state-machine document under _vance/workflows/, NOT a recipe) from a free-text request. Same Slart lifecycle for the authoring part (FRAMING → … → VALIDATING → PERSISTING), only PROPOSING and VALIDATING produce/check a workflow state-graph instead of a Vogon strategy.
Author-only: the run persists the workflow directly at
_vance/workflows/
Use this when the user wants a reusable, branching PROCESS with
gates, timers, retries, error-handling and sub-workflows —
“build a workflow that …”, “set up a state machine for …”,
“automate this multi-step process with approval steps”. For a
one-shot linear pipeline use plain slartibartfast (vogon-strategy);
for deep recursive decomposition use marvin-architect.
Model: default:magrathea-architect (fallbacks: default:analyze)
Tags: architect, workflow, engine-default
marvin-architect
engine: slartibartfast
Slartibartfast variant that generates a Marvin v2 recipe (engine: marvin, autonomous-worker tree with the 5-phase state-machine) from a free-text request. Same Slart lifecycle (FRAMING → … → PERSISTING → EXECUTING → EXECUTION_VALIDATING), only the PROPOSING and VALIDATING phases produce/check a Marvin-recipe shape instead of a Vogon strategy.
Use this when the task needs deep, recursive decomposition with possible user-input mid-flow — “research X systematically and write a report”, “analyse this codebase and produce an architecture document”, “help me decide between A and B, ask me what you need to know first”. The hallmark is dynamic task-tree growth: Marvin’s autonomous workers spawn additional sub-tasks (NEEDS_SUBTASKS) or USER_INPUT nodes as they discover what’s needed.
For linear pipelines with a fixed shape (“write the document
with these phases”) use plain slartibartfast (vogon-strategy).
For multi-perspective debate use zaphod-architect.
Model: default:marvin-architect (fallbacks: default:analyze)
Tags: architect, deep-think, engine-default
marvin-worker
engine: marvin
Marvin v2 worker contract. The Marvin engine itself drives every WORKER node through the five-phase state machine (SCOPE → REFLECT → POST_CHILDREN → CONCLUDE → VALIDATE); the engine is the actual driver, this recipe just supplies the shared system prompt that explains the phases and the live PLAN snapshot mechanic to the LLM.
This recipe is referenced by name from MarvinEngine.WORKER_RECIPE_NAME but isn’t spawned as a regular Ford process — its prompt is read through the document cascade at prompts/marvin-worker-system.md.
Listed here so the recipe registry can surface it and so model / thinking-budget defaults can be overridden per project.
Model: default:marvin-worker (fallbacks: default:analyze)
Tags: marvin, worker, engine-default
python
engine: ford
Python worker — manages a Python workspace RootDir with a local venv, installs packages with pip, runs scripts. The python_* tools are promoted to primary so they sit in the default tool catalog without tool_list discovery.
Model: default:python (fallbacks: default:code)
Tags: python, code, worker
slart-and-run
engine: slartibartfast
Slart-and-Run — generates a JavaScript orchestrator script from a free-text goal and runs it in one step. Combines Slart’s evidence-based authoring (SCRIPT_JS schema with audit chain) with Hactar’s executor lifecycle. Replaces the legacy “hactar” default-fallback recipe.
Workflow:
- Slart’s authoring pipeline runs (FRAMING → CONFIRMING →
GATHERING → CLASSIFYING → DECOMPOSING → BINDING → PROPOSING
→ VALIDATING) and writes the validated script body to
_vance/scripts/_slart/<runId>/<name>.js. - Slart’s EXECUTING phase spawns Hactar with the persisted script ref. Hactar’s LOADING re-validates (parse + header + tool-allowlist), then EXECUTES the script.
- Slart’s EXECUTION_VALIDATING phase checks the Hactar run outcome and either marks DONE or treats validation failures as recovery hints for another PROPOSING pass.
Use this recipe when:
- The user types a free-text goal and the selector has no
better match (
routing.fallback.recipedefault). - A caller (LLM tool, scheduler) explicitly wants “generate + run a script for this goal” without thinking about Slart vs. Hactar plumbing.
Use the hactar-run recipe instead when:
- The script already exists at a known path and you just want to execute it (scheduler-driven cron jobs, etc.).
Tags: default, script-architect, script-executor, engine-default
slart-script-author
engine: slartibartfast
Slart-Script-Author — generates a JavaScript orchestrator script from a free-text goal and stops at PERSISTING. No self-execute via Hactar — the caller (Cortex’s Generate/Update buttons, future hot-fix scaffolding flows) decides whether and when to run the generated script.
Companion to slart-and-run:
| Recipe | planOnly | Use case |
|---|---|---|
slart-and-run |
false | Free-text goal → generate + execute |
slart-script-author |
true | Cortex Generate/Update: code only |
Both share engine: slartibartfast + outputSchemaType: SCRIPT_JS.
The difference is the EXECUTING phase: planOnly=true stops cleanly
at DONE after PERSISTING; planOnly=false spawns Hactar.
Tags: script-author, internal-cortex
slartibartfast
engine: slartibartfast
Plan-architect / meta-engine. Frames a free-text user goal, gathers
evidence from project manuals, decomposes into subgoals, and emits a
NEW plan (Vogon plan by default) tailored to the goal. Output is a
plan document (a state machine, same grammar as a workflow), not a
final deliverable. Author-only: the plan is validated and persisted
to _vance/workflows/<name>.yaml and the run ends at DONE —
EXECUTION_PLANNING skips by construction (a plan is started by the
runner, not by this Slart run). Running it is a separate step: spawn a
vogon recipe with the plan, or workflow_start.
Use via arthur_action DELEGATE preset="slartibartfast" when a task
is substantial enough to deserve its own multi-phase plan (school
essays, multi-chapter reports, research deliverables, …) and no
pre-built recipe in the catalog fits. Slart reads the project’s
kit-installed manuals as evidence, so installed skill-/genre-kits
steer the generated plan automatically.
Model: default:slartibartfast (fallbacks: default:analyze)
Tags: architect, engine-default
trillian-head-colin
engine: trillian-head
Conversation head — one per discussion thread. Reads contributions, answers in the thread, hands long work to the Trillian’s loop as a task. The counterpart ends the conversation; the head archives only when asked to, or when the conversation must close.
Model: trillian-head-colin:analyze (fallbacks: trillian-colin:analyze, trillian:analyze, default:analyze, default:fast)
Tags: trillian, head, conversation, colin
trillian-user-adam
engine: trillian-user
Trillian User worker-loop — Nature-A ‘adam’. Picks task_request events, spawns workers via process_spawn, observes, validates, reports back to Control via task_complete / task_failed / task_needs_input. Runs as _trillian-adam-XXXX in its own headless session. Its attributes are persisted as a document and reloaded on restart.
Model: trillian-adam:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, adam, user, worker, orchestrator
trillian-user-colin
engine: trillian-user
Trillian User worker-loop — Nature colin. Picks task_request events, spawns workers via process_spawn, observes, validates, reports back to whoever asked (task_complete / task_failed / task_needs_input). Runs as _trillian-colin-XXXX in its own headless session. Discussion threads are not its surface — conversation heads answer those.
Model: trillian-colin:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, user, worker, orchestrator, colin
trillian-user-operator
engine: trillian-user
Trillian User loop — operator style. Does small cross-project document work directly with the foreign_* tools; spawns workers for longer jobs.
Model: trillian-void:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, user, worker, orchestrator, operator
trillian-user-void
engine: trillian-user
Trillian User worker-loop — Nature void v2. Picks task_request events, spawns workers via process_spawn, observes, validates, reports back to Control via task_complete / task_failed / task_needs_input. Runs as _trillian-void-XXXX in its own headless session.
Model: trillian-void:analyze (fallbacks: trillian:analyze, default:analyze, default:fast)
Tags: trillian, user, worker, orchestrator
trillian-worker-adam
engine: trillian-worker
Trillian-User worker. Frankie loop with a hard termination contract: call trillian_done(summary=…) when the task is finished so the parent gets a clean DONE event. Otherwise behaves like a coding- style worker (file_/exec_/doc_* via Frankie defaults).
Model: trillian-adam:fast (fallbacks: trillian:fast, default:fast, default:analyze)
Tags: trillian, adam, worker
trillian-worker-colin
engine: trillian-worker
Trillian-User worker. Frankie loop with a hard termination contract: call trillian_done(summary=…) when the task is finished so the parent gets a clean DONE event. Otherwise behaves like a coding- style worker (file_/exec_/doc_* via Frankie defaults).
Model: trillian-colin:fast (fallbacks: trillian:fast, default:fast, default:analyze)
Tags: trillian, worker
trillian-worker-void
engine: trillian-worker
Trillian-User worker. Frankie loop with a hard termination contract: call trillian_done(summary=…) when the task is finished so the parent gets a clean DONE event. Otherwise behaves like a coding- style worker (file_/exec_/doc_* via Frankie defaults).
Model: trillian-void:fast (fallbacks: trillian:fast, default:fast, default:analyze)
Tags: trillian, worker
vogon
engine: vogon
Runs a written plan on behalf of the person who asked for it: the plan can put questions to them while it runs, and its result comes back into the conversation.
Name the plan when spawning — this recipe deliberately does not pin one:
params.workflow: plan name, resolved through the workflow cascade
(_vance/workflows/
Exactly one of the two. Everything else in params is passed to the plan as its caller parameters.
Use this when the steps are known in advance and worth writing down — phases with approvals, a write-review-revise loop, anything a person should be able to read before it runs. For one question or one action use a Ford recipe; when the structure only emerges while working, use Marvin.
Tags: plan, workflow
vogon-architect
engine: slartibartfast
Author a Vogon plan — a state-machine document a person starts and
waits on (worker produces, another scores, loops until good enough,
can ask questions at gates) — from a free-text request. Base the
plan on an existing one by naming it and pasting its YAML into the
request. Author-only: the plan is validated against the one plan
grammar, persisted to _vance/workflows/
Model: default:slartibartfast (fallbacks: default:analyze)
Tags: architect, plan-author
waterfall-feature
engine: vogon
Vogon-driven sequential plan: planning → implementation → review, with the person asked to approve in between and a scored review that can send the work back. Use this when a request genuinely needs phased execution with checkpoints, not when a single Marvin/Ford worker would suffice.
Tags: plan, waterfall, feature
zaphod
engine: zaphod
Zaphod engine default — deliberately minimal. Explicitly requires pattern + heads via params. Catch-all for engine-direct spawns (tests). For real use cases, choose the specific council recipe (e.g. council-three-perspectives).
Tags: default, multi-head, engine-default
zaphod-architect
engine: slartibartfast
Slartibartfast variant that generates a Zaphod council recipe (engine: zaphod, heads + personae + synthesisPrompt) from a free-text request. Same Slart lifecycle (FRAMING → … → PERSISTING → EXECUTING → EXECUTION_VALIDATING), only the PROPOSING and VALIDATING phases produce/check a council shape instead of a Vogon strategy.
Use this when the user wants multiple distinct perspectives on
a topic, with a final synthesis — “set up a council of …”, “give
me three viewpoints on … and a recommendation”, “build a debate
panel for …”. For workflow-style tasks (“write the document with
these phases”) use plain slartibartfast (which defaults to
vogon-strategy) instead.
Model: default:zaphod-architect (fallbacks: default:analyze)
Tags: architect, council, engine-default
zem
engine: zem
Single-shot decision engine (System One). Caller provides state
(string, object or list) plus either a profile (name of an
engine: zem recipe) or inline questions (noul / choice / score),
optionally model and stateSelect. Zem answers with calibrated
probabilities instead of text, writes {success, data} (or
{success: false, error, message, retryable}) as the final assistant
message, then closes with CloseReason.DONE. Use it for classifying,
routing, yes/no gates and ratings — never for prose.
Tags: decision, engine-default
Internal service profiles
internal: true recipes are not spawnable as think-processes. They act as configuration profiles for the LightLlmService — a single-shot LLM call with the recipe’s prompt and schema, no engine lifecycle, no lane lock. Backing services like Follow-Up, Fook triage, Discovery (how-do-i) and the image-title generator use them directly.
_prak
engine: jeltz
Internal config profile for PrakService — the LLM-driven
classifier that the memory-evaluation pipeline runs over a span
(chat-history compaction window, hot-path marker turn, autodream
aggregation slice). NOT spawnable — marked internal: true so the
standard recipe selector skips it.
See planning/memory-evaluation-pipeline.md §4 for the schema and §5
for the trigger taxonomy. The Pebble vars rendered into promptPrefix
are messages (the formatted span body), expectedItemsHint
(a soft “X to Y items expected” line, blank when unknown), and
windowHint (caller-supplied context: scope name, recipe label).
Model: default:_prak (fallbacks: default:fast)
Tags: internal, memory-evaluation
action-loop-judge
engine: jeltz
Internal LightLlmService config profile used by ActionLoopJudgeService when an action-loop hits its maxIters budget without the LLM committing to a final action. The judge decides whether to extend the loop (give the model another budget) or to synthesise an answer from what’s already been gathered.
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Pebble variables: userGoal — the user’s most recent message in this turn (the question/instruction that triggered the loop) gatheredText — best free text the LLM emitted across the loop (“bestFreeText” from the action engine) toolsUsed — newline-separated list of tool calls made this turn, in order. Each line is “name(arg-preview)”. iterations — how many iterations have been consumed so far
Output: ONE JSON object, no markdown fences, no prose around it.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, action-loop-judge
audio-title
engine: jeltz
Internal config profile for the LightLlmService consumed by
HotblackService. Used to generate a short human-readable title +
ASCII slug from a speech / music prompt — the title lands in
DocumentDocument.title (UI), the slug becomes the file-name fragment
(audio/
NOT spawnable — marked internal: true so the standard recipe
selector skips it. Single Pebble variable: prompt (the text to
speak or the music prompt).
Model: default:fast
Tags: internal
benjy-evaluate
engine: jeltz
Internal config profile for Benjy’s per-item evaluate call (LightLlm, not spawnable): worker result vs acceptance criteria.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, benjy
benjy-interpret
engine: jeltz
Internal config profile for Benjy’s interpret call (LightLlm, not spawnable): goal → interpreted goal, task type, acceptance criteria, first items. Called once per task.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, benjy
benjy-reflect
engine: jeltz
Internal config profile for Benjy’s reflect gate (LightLlm, not spawnable): terminal goal-level check before DONE.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, benjy
benjy-route
engine: jeltz
Internal config profile for Benjy’s route call (LightLlm, not spawnable): decides the next queue operation at branch points. The high-frequency controller call — smallest model of the chain.
Model: default:fast
Tags: internal, benjy
command-safety
engine: zem
Zem decision profile (internal): judges whether an engine command deletes, overwrites or exfiltrates data, or changes permissions. State: the command name and its arguments.
Model: openrouter:typesafe/jev-1.13
Tags: internal, zem
completion-guard
engine: jeltz
Internal config profile for the CompletionGuardService judge. NOT
spawnable — marked internal: true so the standard recipe selector
skips it. Renders a user-defined guard condition against the work a
process just finished and answers whether the guard should fire.
Model: default:fast
Tags: internal, guard
document-summary
engine: jeltz
Internal config profile for the LightLlmService consumed by
DocumentSummaryDriver. Generates a 1-3 sentence summary plus 3-8
topical tags per dirty document so the project-RAG indexer has a
searchable kind=summary chunk per file. NOT spawnable — marked
internal: true so the standard recipe selector skips it.
Tenants override this recipe to swap the summariser model, change the tag policy (“German tags only”, “single-word only”), or relax the JSON contract — no Java change required.
Model: default:document-summary (fallbacks: default:fast)
Tags: summary, system, internal
engine-output-translator
engine: jeltz
Internal LightLlmService config profile used by ParentNotificationListener to translate the technical output of engines that do NOT produce user-facing replies (Hactar, Slartibartfast, …) into a natural-language answer matching the original user goal.
NOT spawnable — marked internal: true so the standard recipe
selector skips it. Called only when BOTH gates hold: the PARENT
engine relays the child output verbatim to a human
(relaysChildOutputVerbatim() == true — Arthur’s RELAY, Eddie’s
RELAY/RELAY_INBOX) AND the child engine returns
producesUserFacingOutput() == false AND the lifecycle event is
DONE or FAILED. Composing parents (LLM agents like Hactar’s
session identity, Ford workers, orchestrators) get the RAW machine
summary — this lossy fast-tier rewrite must not misstate machine
facts to a consumer that acts on them.
Pebble variables:
userGoal — the goal the spawning user typed (the child
process’s goal field), in whatever language it
was written
eventType — DONE | FAILED
engineName — emitting engine (slartibartfast / hactar / …)
so the LLM knows what kind of plumbing it’s looking at
rawSummary — the engine’s technical humanSummary
(Hactar’s “executed … return value”, Slart’s
“Recipe persisted at …”, etc.)
Output: ONE short natural-language reply, in the language of the
user goal, that answers the user’s request based on what the engine
produced. Plain text — no markdown, no code fences, no header
decorations. The reply lands verbatim as the new humanSummary of
the outgoing ProcessEvent, where the parent engine (Arthur) will
RELAY it to the user.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, engine-translation
finance-report
engine: jeltz
addon: finance
Internal config profile for the LightLlmService consumed by the finance
assessment report processor (AssessmentReportProcessor). NOT spawnable —
marked internal: true so the standard recipe selector skips it. The
processor computes the current-value snapshot, lays the tree out
sign-applied (expenses already negative, one-time held separate) into the
Pebble variable ``, and asks for a prose assessment. No time
range — this is an opinion on the current model.
Model: default:finance-report (fallbacks: default:analyze)
Tags: internal, finance
follow-up
engine: jeltz
Internal config profile for the LightLlmService consumed by
FollowUpService (backend of the follow-up suggestion REST endpoint).
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Two structural modes, selected by which Pebble variables are set:
- Edit mode:
textBefore+textAfterset,precedingContextabsent. The user is editing a text and the cursor sits between the two fragments. Suggestions are inserted VERBATIM at the cursor — write text the user could plausibly have typed next. - Reply mode:
precedingContextset,textBefore/textAfterabsent. The user is looking at a recent conversation transcript and wants suggestions for how to react — a follow-up question, a clarification, an acknowledgement, or a natural next message.
mode is an optional free-form UI-surface hint passed through
verbatim, orthogonal to the edit/reply branch.
Model: default:follow-up (fallbacks: default:fast)
Tags: internal, followup
fook
engine: jeltz
Internal config profile for the LightLlmService consumed by
FookService (backend of the bug/feature ticket triage system).
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
FookService pre-loads up to N candidate tickets (text-similarity
match against the submission text) and renders them via the
Pebble variable . The submission itself is one
free-form text blob exposed as — the reporter does
NOT supply type/title/severity, Fook derives them.
The LLM must classify the report, decide whether it’s a new ticket, a duplicate of an existing one, or not a ticket at all, and (for new tickets) derive title, type, and severity from the text.
See planning/fook-service.md.
Model: default:fook (fallbacks: default:analyze)
Tags: internal, fook, triage
fook-session-analysis
engine: jeltz
Internal config profile for the LightLlmService-driven ReAct loop in
FookSessionAnalysisService (second stage of the bug/feature ticket
system). NOT spawnable — marked internal: true so the standard
recipe selector skips it.
When Fook’s triage decides a new_ticket and flags
needSessionReport, Fook analyses the reporter’s session and attaches
the result to the ticket. The fixer (Lunkwill) has NO access to the
original session — this report is the only bridge.
This recipe is the PER-TURN prompt of an agentic loop. The session can be far larger than a context window, so the model does NOT receive the whole transcript — it works over it with tools (overview/search/grep/ read) and Fook feeds back each observation. One LLM call = one action.
Inputs (Pebble variables): / — the derived ticket header / — Fook’s triage rationale / — what was running — remaining loop turns — tool results so far
See planning/fook-session-report.md.
Model: default:analyze
Tags: internal, fook, analysis
form-judge
engine: jeltz
addon: workbook
Internal LightLlmService config profile used by FormResolveActionHandler
to grade free-text vance-field answers (type text/textarea with a
judge fence config). NOT spawnable — marked internal: true so the
standard recipe selector skips it.
The handler builds the user prompt: the question, the field’s
solution (a reference answer, when present), the judge.criteria
(what a correct answer must contain) and the student’s answer.
Pebble variables: none — everything arrives in the user prompt.
Output: ONE JSON object, no markdown fences, no prose around it:
{ "verdict": "correct" | "wrong", "feedback": "<text>" }
Model: default:fast
Tags: internal, form-judge
hactar-args-extract
engine: jeltz
Internal LightLlmService config profile used by Hactar’s
ArgsResolver. Given a JavaScript script and a free-text user
intent, extract concrete values for the parameters the script
expects via vance.params.<name> references.
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Pebble variables: code — full script source intent — free-text user intent / process goal requiredKeys — comma-separated list of params the script reads via vance.params.X (Hactar’s regex scan) suppliedKeys — comma-separated list of keys the caller already provided (so the LLM ignores them)
Output schema (Jeltz-loop):
{
“params”: { “
Hactar merges params with the caller-supplied scriptParams
before EXECUTING. unresolved entries trigger a FAILED status
with a clear “missing required parameter” message.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, hactar
how-do-i
engine: jeltz
Internal config profile for the LightLlmService consumed by
DiscoveryService (backend of the how_do_i tool). NOT spawnable —
marked internal: true so the standard recipe selector skips it.
The service reads model alias, fallback list, max-attempts budget
and promptPrefix from here; the LLM is called directly without a
process spawn.
Model: default:how-do-i (fallbacks: default:fast)
Tags: internal, discovery
image-title
engine: jeltz
Internal config profile for the LightLlmService consumed by
FenchurchService. Used to generate a short human-readable title +
ASCII slug from an image prompt — the title lands in
DocumentDocument.title (UI), the slug becomes the file-name
fragment (images/
NOT spawnable — marked internal: true so the standard recipe
selector skips it. Single Pebble variable: prompt (the user’s
image-generation prompt).
Model: default:fast
Tags: internal, fenchurch
kit-resolver
engine: jeltz
Internal config profile for the LightLlmService consumed by
KitNameResolverService. Maps a free-text kit wish (typed by a user
or emitted by Eddie) to a canonical entry name in the tenant’s
project-kits catalog. NOT spawnable — marked internal: true so
the standard recipe selector skips it.
Tenants override this recipe to swap the matching model, tighten the prompt rules (“our ‘creative-essay’ kit handles all Aufsatz wishes, prefer it over the bundled school-essay”), or relax the JSON contract when their catalog grows complex enough to need explanations.
Model: default:kit-resolver (fallbacks: default:fast)
Tags: resolver, system, internal
nutrimat-critic-affogato
engine: jeltz
addon: nutrimat
Internal LightLlmService config profile used by the Nutrimat loop
nature affogato at every stop: a critic attacks the loop’s draft
answer, with the tool work in view, and either accepts it or sends it
back with a critique.
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Pebble variables: userGoal — the user’s most recent message in this turn draftText — the draft answer the loop stopped with toolTrace — the turn’s tool calls with their (cut) results
Output: ONE JSON object, no markdown fences, no prose around it.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, nutrimat-judge
nutrimat-judge-clubmate
engine: jeltz
addon: nutrimat
Internal LightLlmService config profile used by the Nutrimat loop
nature clubmate when its iteration budget is exhausted. The judge
decides whether to extend the loop (grant a fresh budget) or to
synthesize an answer from what has already been gathered.
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Pebble variables: userGoal — the user’s most recent message in this turn gatheredText — best free text the loop emitted across the turn iterations — how many iterations have been consumed so far
Output: ONE JSON object, no markdown fences, no prose around it.
Model: default:fast (fallbacks: default:analyze)
Tags: internal
recipe-selector
engine: jeltz
Internal config profile for the LightLlmService consumed by
RecipeSelectorService. Picks one project recipe from a small,
trigger-matched candidate list, given a free-text task description.
NOT spawnable — marked internal: true so the standard recipe
selector skips it (self-reference would be funny).
The deterministic pre-stages in the service (recipe-name word boundary + trigger-keyword substring) run BEFORE this recipe is consulted. The LLM only sees ambiguity cases — typically 2-4 candidates that all matched the same trigger keyword.
Tenants override this recipe to bias the disambiguation prompt (“our ‘analyze’ recipe is always more specific than ‘deep-think’”), swap the model, or relax the JSON contract — no Java change required.
Model: default:recipe-selector (fallbacks: default:fast)
Tags: routing, system, internal
research-synthesize
engine: jeltz
Internal config profile for the LightLlmService consumed by
ResearchDocumentService (backend of the research_document tool). NOT
spawnable — marked internal: true so the standard recipe selector skips
it. The service runs the curated research pass first, then hands the ranked
sources to this recipe to synthesize a full Markdown document in one
single-shot call (no process spawn). Model alias, fallback list, max-attempts
budget and promptPrefix are read from here.
Model: default:research-synthesize (fallbacks: default:analyze)
Tags: internal, research
scribble-ocr
engine: jeltz
addon: scribble
Internal LightLlmService config profile used by the scribble addon’s OCR path (ScribbleOcrService): transcribing a rendered handwriting sheet to Markdown. The caller attaches the sheet PNG as an image block — the recipe’s model MUST be VISION-capable, the service fails fast otherwise. Point params.model at a vision model per tenant/project if the default is not one.
NOT spawnable — marked internal: true so the standard recipe
selector skips it.
Pebble variables: sheetTitle — display title of the transcribed sheet
Output: Markdown transcription of the handwriting, nothing else.
Model: default:analyze
Tags: internal, scribble-ocr
script-review
engine: jeltz
Internal config profile for the LightLlmService consumed by HactarService.deepValidate(…). Used for semantic LLM-Review of a script before execution (Hactar’s opt-in VALIDATING phase, plus Cortex’s POST /scripts/validate-deep endpoint).
NOT spawnable — marked internal: true so the standard recipe
selector skips it. Pebble variables:
code— the full script sourcelanguage— “js” (only supported v1; later also “py”)sourceName— identifier for the script (path or “")
Output is a verdict-plus-issues object. The caller (HactarService)
parses ok (boolean) and issues (array of severity-coded
problems) — see HactarServiceImpl.parseLlmReviewReply.
Model: default:script-review (fallbacks: default:fast)
Tags: internal, hactar
session-metadata
engine: jeltz
Internal config profile for the LightLlmService consumed by
SessionMetadataSuggester. Proposes a short {title}, a single-emoji
{icon} and one of twelve named {color}s for a freshly-opened chat
session, based on its first user/assistant exchange. NOT spawnable —
marked internal: true so the standard recipe selector skips it.
Tenants override this recipe to change the colour palette, switch to a stronger model, or relax the icon rules — no Java change required.
Model: default:session-metadata (fallbacks: default:fast)
Tags: session, system, internal
translate
engine: jeltz
Internal LightLlmService config profile for translating a text or Markdown document — the backend of the Cortex “Translate…” menu entry. Single shot: the whole text goes in, the whole translation comes back, nothing is spawned.
NOT spawnable — internal: true, so the standard recipe selector
skips it. Additionally web: true, because it is called straight
from the browser through POST /brain/{tenant}/light-llm/{project};
that flag is what releases a recipe for web callers and its default
is no.
Pebble variables: language — the target language, as the user picked it. Either a name (“Deutsch”, “Brazilian Portuguese”) or a BCP-47 code (“de”, “pt-BR”). Free-form on purpose: the user may also ask for “Simplified Chinese” or “plain English”. sourceName — optional, the source document’s file name. Only used to help the model recognise the format; never echoed.
Output: the translated text and nothing else — no preamble, no wrapping code fence, no closing remark. It is written verbatim into a new document (or handed to the reader’s clipboard), so any word the model adds about its own work ends up in the file.
KNOWN LIMIT: one call translates as much as the model is willing to emit. A long document comes back silently truncated. The caller caps the input length and warns when the result is much shorter than the source; chunking is not implemented.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, translate
trillian-adam-reflect
engine: jeltz
Internal config profile for the reflexion pass of Trillian Nature-A ‘adam’. Turns one concluded task into at most one journal line, or into nothing when there is nothing worth keeping.
Model: default:fast
Tags: trillian, adam, internal
vogon-intake
engine: jeltz
Reads a spoken request into the parameters a plan declared. Used by the Vogon engine before a run starts; not meant to be spawned directly.
Model: default:fast
Tags: internal, vogon
wonko-check
engine: jeltz
Internal config profile for Wonko’s check call (LightLlm, not spawnable): reviews the subject against the register and reports findings worth clarifying. Called once per round.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, wonko
wonko-compare
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): judges one claim against each of its reference passages — contradicts, satisfies, not applicable, or cannot be determined — with a reason and a verbatim quote as evidence.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, wonko
wonko-coverage
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): finds the obligations of one reference document that apply to the subject but are not addressed by it — each with a verbatim quote as evidence.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, wonko
wonko-decompose
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): splits the subject into checkable claims, each with search terms for finding the reference passages that apply to it.
Model: default:analyze (fallbacks: default:fast)
Tags: internal, wonko
wonko-interpret
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): maps a free-text reply of the user onto the open questions of a question set.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, wonko
wonko-locate
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): selects, from candidate reference passages found by a text search, the ones that actually apply to one claim, and names cross-references worth following.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, wonko
wonko-route
engine: jeltz
Internal config profile for Wonko (LightLlm, not spawnable): decides whether a free chat message asks for a new review run, brings new information for the review, or is a question that wants an answer.
Model: default:fast (fallbacks: default:analyze)
Tags: internal, wonko
wowbagger-script-worker
engine: hactar
Internal profile for Wowbagger script workers (never spawned): one script run per chunk — records in, one result per record out.
Tags: internal, wowbagger
wowbagger-worker
engine: jeltz
Internal config profile for Wowbagger worker calls (LightLlm, not spawnable): per-run task + chunk records in, one output line per record out. Pinned to the fast tier — bulk throughput is the point.
Model: default:fast
Tags: internal, wowbagger
zaphod-consensus
engine: jeltz
Internal config profile for the LightLlmService consumed by
ZaphodEngine’s between-round consensus check (debate pattern).
Per round, the engine renders the current heads’ last-round
replies into the template variables below and asks for a binary
JSON verdict { consensus: bool, reason: string }. NOT spawnable —
marked internal: true so the standard recipe selector skips it.
Tenants override this recipe to swap the check model, tighten or loosen the consensus threshold (“only count as consensus when ALL heads explicitly agree”), or change the language of the reason field — no Java change required.
Model: default:zaphod-consensus (fallbacks: default:fast)
Tags: internal, zaphod, consensus
zarniwoop-research-evaluate
engine: jeltz
Internal config profile for the LightLlmService consumed by
ZarniwoopResearchService — phase 3 of the research_investigate
pipeline. NOT spawnable — marked internal: true.
Sees the original question plus every hit the execute phase collected (deduplicated by URL) and decides per-hit whether to keep, drop, or — for v1.5+ — flag for deepening. Produces a relevance score on a 0..1 scale calibrated against the other hits on screen. The service multiplies that score with the plan’s source-affinity later.
See planning/zarniwoop-service.md §13.
Model: default:research (fallbacks: default:analyze)
Tags: internal, zarniwoop, research
zarniwoop-research-plan
engine: jeltz
Internal config profile for the LightLlmService consumed by
ZarniwoopResearchService — phase 1 of the research_investigate
pipeline. NOT spawnable — marked internal: true.
Reads the original question plus the current project’s provider inventory (``) and decides which searches to run, which modalities apply, and how heavily each modality / instance should weight against the relevance score the evaluate-recipe produces later. The recipe owns the search strategy; the service owns the execution mechanics and the deterministic affinity multiplication.
See planning/zarniwoop-service.md §13.
Model: default:research (fallbacks: default:analyze)
Tags: internal, zarniwoop, research