2026-08-29 · Updated 2026-08-29 · 7 min read
Reusable, tested workflow templates for coding agents
Seed agent automation from five tested workflow templates shipped inside Workflow Runner — what each one is for, which seam it demonstrates, and the lint, dry-run, and committed tests behind them.
By Juno AI INC · workflow-runner · templates
Every automation program hits the same wall in the same place: the first workflow. The procedure is known — gather context, dispatch an agent, check the result, summarize what happened — but the file has to be written from nothing, and nothing is where defects breed: unbound seams, wrong failure defaults, prompts that reference evidence nobody captured. The alternative is to start from files that already ran. YYLO ships five named workflow templates inside its runner script, each written for a distinct operational shape and exercised by the committed test suite of the package that carries it. This page is their catalog: what each one seeds, which seam it demonstrates, what its validation status is, and where the source bytes live.
The five quoted spans below were taken from the committed YYLO README, matched against its source text (whitespace-normalized) on 2026-08-29; the gallery taxonomy, the per-template annotations, and the seeding procedure are original work on this page, and the header's evidence date is their version stamp. Two neighbors bracket this page. Keeping a definition movable once it exists — format, seams, engine isolation — is the portability guide's job. Deciding whether an ordered workflow or a parallel fan-out should own the job at all belongs to the runner-choice guide. This page sits one step earlier than both: it is the shelf the first file comes off.
The gallery, one command away
The templates are not a folder to browse; they are named entries the runner materializes on demand. From an initialized project root, where the runner is installed at .juno_task/scripts/workflow_runner.sh, a single command writes any of the five to a path you choose. The write is deliberately conservative: writing to an existing path is refused outright, --force is the explicit opt-in, and nothing lands in the project until you ask for one by name.
What each name is for
agent-chain is the minimal agent shape: one dispatch investigates, a second dispatch resumes the first one's recorded conversation and summarizes next actions, and the summary renders the session id together with the final response. Everything it demonstrates is the session seam — the id is a value like any other, addressable by later steps and by continuation commands after the run.
command-pipeline drops agents entirely: one command prints, the next command renders the previous step's captured stdout into its own input, and the summary prints one step's status and the other's output. It is the cleanest demonstration that a workflow is a pipeline for any process, not a wrapper for chat agents — and the right seed when the automation is plumbing.
daily-ops adds the tolerance knob: a preflight command, an operator agent marked so its failure does not fail the run, and a final note step that prints the operator's session id for later continuation. The date it binds — yesterday, UTC — is computed at run time, so the same file works every day without edits.
production-triage-handoff is the first of the two hybrids: "Use production-triage-handoff when production discovery should fan out into capped tmux handoff panes (--tmux panes --tmux-handoff --max-panes-per-session 4) with a fixed {{ out_dir }}/parallel artifact root." A workflow step writes the issue list as JSONL plus a prompt template; the next step hands both to the parallel runner in tmux handoff mode; the last step records the attach instructions and lists the aggregation artifacts. The discovery step ships as an openly labeled stub — the JSONL contract is the durable part, and your own detector replaces the sample rows.
parallel-kanban-review is the second hybrid and the most complete file in the set: "Use parallel-kanban-review when a planning agent creates kanban tasks, parallel workers write aggregation artifacts, and a master review reads the latest aggregation_*.json." Read it as four responsibilities in one definition — an agent turns a topic into board tasks, a parsing step refuses to continue when the plan omits its task ids, workers run concurrently against the board, and a closing review step consumes the batch record before humans make merge decisions.
The third fan-out shape is not a workflow file
The gallery's two hybrids both put the parallel runner inside a workflow step. The third shape inverts it: the fan-out items are themselves complete commands. "Use raw command YAML mode in parallel_runner.sh when the fan-out items are complete commands or multiple workflow files that should run concurrently." That mode is how one definition seeds many — a command file lists the workflow invocations, and the parallel runner becomes the scheduler around them. It is also the boundary of what a template can promise: concurrency between independent files is scheduling, not orchestration, and the choice between the two patterns has its own guide, linked above.
What tested means for a template
Tested is a strong word, so pin it to its evidence. The runner's own statement of why its tests are subprocess tests: "The runner is backed by subprocess tests because cron workflows depend on real process boundaries for command rendering, failure continuation, artifacts, stdout controls, live observer visibility, response capture, session visibility, and continue handoff." The same suite carries the templates. Concretely, the committed tests write each of the five names on demand and refuse an accidental overwrite of an existing path; assert the agent-chain file's resume seam by content; and dry-run the two hybrid files across their full step lists, checking the dry-run manifest and its rendered steps. What that buys is a floor, not a ceiling: the shipped files are proven against the shipped runner at exactly that depth. Your modifications are yours — which is what the next section is for.
Validate the file you now own
A template becomes yours the moment you edit it, and the loop is three commands deep:
The commands are shown bare; inside an initialized project, invoke the runner at its installed .juno_task/scripts/workflow_runner.sh path. The README's own summary of the discipline: "Use workflow_runner.sh lint before cron runs to catch noisy stdout/stderr templates, and workflow_runner.sh doctor/dr after runs to diagnose manifest/artifact response issues." Lint reads the file without running it; the dry run renders every command and writes its manifest without dispatching anything; after a real run, doctor reads the artifacts the run left behind. Re-run the pair after every edit — a definition that was valid when seeded can stop being valid the moment a seam is renamed by hand.
Where the source lives, and where this page sits
The bytes behind this catalog are not pasted here; they live in the repositories behind the buttons below, inside the runner script and its test suite, behind the versions the generated package facts on this site pin. A visit to that source is the qualified next step this page exists for — reading the template you are about to trust beats trusting a copy from any site, including this one. For the deeper material, the boundaries stand: what makes any of these files movable — the seams, the identity policy, the engine isolation — stays with the portability guide, and choosing between an ordered definition and a fan-out stays with the runner-choice guide, both linked above. A page of downloadable validated YAML files, each carrying its own source anchor and lint evidence, has now shipped as the archive companion to this catalog at the downloadable examples page; until you need its digests and validation record, the init command is the copy mechanism, and the gallery above is the inventory.