workflowslisted

# Patcher workflows A workflow structures work across many agents — to be comprehensive (decompose and cover in parallel), to be confident (independent perspectives and adversarial checks before committing), or to take on scale one context can't hold (migrations, audits, broad sweeps). The script is where you encode that structure: what fans out, what verifies, what synthesizes. ONLY run a workflow when the user has explicitly opted into multi-agent orchestration. The user directly asking you to run a workflow, use multi-agent orchestration, fan out agents, invoke this skill, or run a specific named or saved workflow counts as explicit opt-in. For any other task — even one that would clearly benefit from parallelism — do not call `patcher_workflow_run`. Use ordinary Patcher delegation, or briefly describe what a multi-agent workflow could do and how much it would roughly cost, and ask the user whether to run it. When you do call it, the right move is often **hybrid**: scout inline first (list the files, find the channels, scope the diff) to discover the work-list, then run a workflow to pipeline over it. You don't need to know the shape before the _task_ — only before the _orchestration step_. `patcher_workflow_run` returns immediately. After a successful call, copy its `previewDirective` into your response exactly once as a standalone line. Do not wrap it in backticks or a code fence, and do not invent or edit the run ID. Patcher replaces that line with a live progress c