2026-08-29 · Updated 2026-08-29 · 6 min read
Downloadable validated workflow YAML examples
The five workflow YAML templates shipped inside YYLO's Workflow Runner as downloadable files: byte counts, ordered step ids, SHA-256 digests, the lint and dry-run record captured on 2026-08-29 against the committed runner template, and the seed command plus repository anchor behind every file.
By Juno AI INC · workflow-runner · templates
Picking a starting workflow is a reading decision, and the template catalog already owns it: what each shipped name is for, which seam it demonstrates, and how the committed test suite exercises it. This page is the shelf beside that catalog. Every one of the five YAML definitions the runner materializes on demand is downloadable here as a standalone file, and each file travels with the facts a pasted snippet never carries — its exact size in bytes, its step ids in order, its SHA-256 digest, the lint and dry-run record captured when it was published, and the seed command that rewrites those bytes from the runner version the record names. Read the catalog to choose; come here to hold the artifact.
One provenance note before the files. Each entry below was extracted from the committed Workflow Runner template in the YYLO source tree — not retyped, summarized, or adapted — so a downloaded file and the file a runner writes are the same bytes, and the digest is the proof that they stayed that way.
The five files, pinned by digest
- agent-chain — agent-chain.yaml, 678 bytes, 27 lines.
workflow_id: example_agent_chain; steps in order:first_agent,continue_agent. Digestsha256:ecc7cb5a…a5d4f7; seeds with--init-example agent-chain. - command-pipeline — command-pipeline.yaml, 420 bytes, 15 lines.
workflow_id: example_command_pipeline; steps in order:collect,summarize. Digestsha256:59ef2e02…c0bcc4; seeds with--init-example command-pipeline. - daily-ops — daily-ops.yaml, 753 bytes, 26 lines.
workflow_id: example_daily_ops; steps in order:preflight,operator_check,archive_note. Digestsha256:1020672c…25e4a7; seeds with--init-example daily-ops. - production-triage-handoff — production-triage-handoff.yaml, 3,295 bytes, 68 lines.
workflow_id: production_triage_handoff; steps in order:discover_issues,start_tmux_handoff,handoff_summary. Digestsha256:d69b8ded…0a2e0f; seeds with--init-example production-triage-handoff. - parallel-kanban-review — parallel-kanban-review.yaml, 3,485 bytes, 80 lines.
workflow_id: parallel_kanban_review; steps in order:plan_kanban_tasks,resolve_task_ids,run_parallel_kanban,prepare_master_review,master_review. Digestsha256:da32d1ea…fc4e30; seeds with--init-example parallel-kanban-review.
The short digests above are display prefixes — eight characters from the head of the hex value, six from its tail. The full-length digests, the ordered step lists, the validation record, and the instrument pin ship beside the files as manifest.json, serialized deterministically from the same committed registry behind this page's checks.
What the validation record says
The record is dated and instrumented. On 2026-08-29, each of the five files was written out with its seed command from the committed workflow_runner.sh template — digest sha256:9b7be279…00d468 — in the YYLO source tree, at @yylo/cli 0.2.1-rc.1, the version the site's facts record from the package manifest. Two checks then ran against every file. Lint validated each definition with the same schema validation a launch applies — plus lint's own anti-pattern rules — and reported OK: no issues found, exiting zero. A dry run rendered each command and wrote its manifest without dispatching anything, marking every step dry_run and exiting zero — two, two, three, three, and five steps across the five files.
The record's scope is exactly that, and honesty about the boundary matters more than the checkmarks. It certifies the files as shipped: each parses under the runner's contract, every template expression renders against the variables and steps its own file declares, and no lint rule fires. The moment you edit a downloaded file the record stops speaking for it — re-check your edited copy before it runs anything, with the commands the operational reference documents. And what a real run leaves behind — the manifest, the response artifacts, the recovery of an interrupted attempt — belongs to the auditable-workflow treatment; a dry run proves a file renders, never that its work succeeded.
Check the bytes you hold
Verification is two commands, either from the download or from an installed project. Against the download:
Or let a runner at the version named above rewrite the file, and compare the two digests:
Match the printed hex against the full digest in the manifest, not the display prefix above. A download that differs from the manifest means one of those two files is not what this page published. A seed output that differs from the download means the runner's embedded template is not the one these files were cut from — the shipped set moved upstream, this page owes a refresh, and until that refresh lands the published file and its digest remain the record. Either way the next move is to read, not run: nothing downstream of a mismatch is worth executing.
Where each file's source lives
All five files have one birthplace: the template table inside workflow_runner.sh in the YYLO repository. The README's managed workflows and evidence section shows the seed commands in use and spells the contracts behind the workflow templates; the runner's own help text is where all five names appear listed together. The per-file anchor is the seed command at the end of each entry — run it against a runner carrying the template version the record names and it writes the exact bytes the digest pins, so the shortest path from this page back to the source of record has no intermediary: same bytes, same instrument. That a workflow definition can make that round trip at all is the property worth noticing. A definition held as plain YAML — readable, diffable, runnable under whichever engine the project configures — is the portability position the portable-workflow guide develops, and these five files are its worked instances.
Frozen at publication
Each file here is frozen at its published digest, and the freeze is the point: a digest that moves underneath its reader verifies nothing. When a future runner release changes a shipped template, the changed file appears here with a new digest, a fresh validation record under the new instrument, and a new manifest version — and every previously published digest stays comparable, because the bytes it named never change. The buttons below lead to the repositories behind this page's evidence; the runner that owns these templates lives in the first of them, and the next version of the templates will be written there. What this page guarantees is only ever about the bytes it pinned, on the date it pinned them.
No keyword evidence selected these files. This route owns no demand row in the corpus behind this site's wider program — the shipped template set is the entire justification, and the files' worth is what a reader can verify with the two commands above, not any estimate of how many people might want them.