| name | smithers-orchestrate |
| description | Drive Smithers durable workflows from OpenClaw. Use for multi-step, long-running, background, human-in-the-loop, retryable, or repeatable work. Prefer creating or improving a Smithers workflow over repeating ad-hoc agent turns, and use evals plus optimization to improve workflows over time. RULE 0: if `SMITHERS_INSIDE_RUN` is set in your environment you are ALREADY a worker agent inside a Smithers node, so never invoke the Smithers CLI or `smithers_*` tools to launch or steer a run; do the node's task directly. The rest applies only when it is unset. |
Smithers From OpenClaw
Smithers is the durable control plane for long-running agent work. A workflow is
executable, typed, inspectable, resumable, retryable, and optimizable. When the
user asks for a process that has stages or may recur, capture it as a Smithers
workflow instead of doing another one-off OpenClaw turn.
Rule 0: If You Are Already Inside a Smithers Run, Do Not Use Smithers
Check this before anything else. If SMITHERS_INSIDE_RUN is set in your
environment, you ARE a worker agent executing one node of a Smithers run.
Smithers sets that variable on every agent it spawns. This rule overrides every
rule below. Do the node's task directly with your ordinary tools and finish your
turn: never call smithers_run, smithers_create_workflow, any other
smithers_* tool that launches or watches a run, or the smithers CLI, and
never poll a run in a sleep loop. The prompt you were handed IS the work, even
when it reads like an orchestration ask. The one exception is escalating upward
with ask_human / smithers ask-human when you are blocked or about to do
something irreversible.
Default Behavior
Use Smithers when work is multi-step, backgroundable, repeatable, risky, or needs
human approval. If a matching workflow exists, run it. If none exists, call
smithers_create_workflow with a concrete description of the goal, inputs, done
condition, verification commands, and approval points.
Do not tell the human to run Smithers commands. You operate Smithers, watch the
run, relay approval gates in plain language, then resolve them with
smithers_approve, smithers_deny, or smithers_human_answer.
Self-Improving Workflow Loop
Treat every useful workflow as something that should improve from evidence:
- Add or update eval cases under
.smithers/evals/<workflow>.jsonl when a
workflow handles a new class of task or fails a case.
- Run
smithers_eval before changing workflow prompts or logic so you know the
baseline.
- Change the workflow or prompt.
- Run
smithers_eval again and compare the report.
- When evals show prompt-level gaps, run
smithers_optimize and save the
artifact. Re-run evals with the artifact before treating it as better.
Do not run an endless hidden improvement loop. Improve when there is a concrete
workflow, concrete eval cases, and a measurable gap.
Keep The Human In The Loop
For long-running work, do not go dark. Use smithers_ps, smithers_inspect, and
smithers_output to report progress. If a workflow has or needs a live UI, open
or build it through the normal Smithers UI path so the human can watch the run.
Tool Map
smithers_run: start a workflow.smithers_create_workflow: author a workflow when none fits.smithers_ps / smithers_inspect / smithers_output: observe and report.smithers_approve / smithers_deny / smithers_human_answer: clear gates
only after asking the human.smithers_eval: measure workflow behavior on real cases.smithers_optimize: improve workflow prompts from eval evidence.
