Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →awslabs/cao-workflow
Author and run CAO Python workflow scripts — multi-step, parameterized, fan-out orchestrations executed by `cao workflow run`.
Passed 17 of 20 test cases with the skill, and 3 of 20 without it.
and 19 more in the full report
16 fixed4 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/19/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 16 test cases the skill fixed. Same model, same prompt, with and without the skill.
When checking the result of an agent step handle in a workflow script, what does the `.replayed` boolean flag signify regarding `.terminal_id`?
| Checked | Without skill | With skill |
|---|---|---|
| The response states that replayed being true means the stored step result was returned without running. | Passed | Passed |
| The response states that terminal_id refers to a terminal that no longer exists when replayed is true. | Missed | Passed |
The instructions your model reads when the skill loads.
A CAO workflow is a Python script you write, validate, and — only after asking the user —
run through cao workflow run. Each script drives one or more agent steps through CAO's
shared substrate, so you can fan work out across agents, collect their results, and resume a
run that was interrupted.
Your job as an author ends at a validated script file on disk. Authoring does NOT run the workflow. Never claim a workflow ran, or will run, when all you did was write it. Running is a separate step the user must approve (see Lifecycle step c).
Reach for this skill when the user asks to build or run a multi-step or parameterized workflow — for example:
reports/ and summarize the findings."If the work is a single one-off agent call, you don't need a workflow. Workflows earn their keep when there are multiple steps, fan-out, parameterization, or a need to resume.
Author scripts import from the cao_workflow package. This package runs only in the script
subprocess and imports nothing from cli_agent_orchestrator.* — it talks to CAO over HTTP.
Its public surface:
step(provider, agent, prompt, *, recovery, step_id=None, timeout=None, **opts) -> StepHandle —
run one agent step and declare what re-running it would mean. recovery is keyword-only
with no default, so omitting it is a TypeError at the call. See "Declaring a recovery
policy" below before you pick a value.run_step(provider, agent, prompt, *, step_id=None, timeout=None, **opts) -> StepHandle —
the same call, declaring no policy. That is the only difference between the two. A
recovery= passed to run_step lands in **opts; the server validates it, the shim does
not — see below.StepHandle has five fields: .step_id, .terminal_id, .output, .status, and
.replayed. .replayed qualifies .terminal_id. When it is True the server returned
a stored result and ran nothing, and .terminal_id is the ORIGINAL id — it names a terminaltest cases passed, vs 3 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.