[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DWJ5H37YRYD2AC0791CXEF":3,"skill-same:01M6DWJ5H37YRYD2AC0791CXEF":86},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":30,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6DWJ5H37YRYD2AC0791CXEF","octomind-workflow",null,"Octomind workflow .toml guide: pipeline design, sequential, parallel, loop and conditional steps, validation. Use when designing or debugging a workflow.","Muvon\u002Foctomind-tap","Muvon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25336907?v=4","01M6DWA4KTRX4J73CW5CECKAD0","01M6DWA4QSWFGYE6WDMAMFF1WE",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Foctomind-workflow\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"octomind workflow","octomind","workflow","with","file","use","conditional","toml","octomind cli","parallel","guide","when","syntax","cli","workflows","debugging","loop","design","tap","pipeline","2026-11-10 10:12:30",false,"---\nname: octomind-workflow\ntitle: \"Octomind Workflow Design & Syntax\"\ndescription: \"Octomind workflow .toml guide: pipeline design, sequential, parallel, loop and conditional steps, validation. Use when designing or debugging a workflow.\"\nlicense: Apache-2.0\ncompatibility: \"Requires: octomind CLI with the `workflow` subcommand. Workflows are stdin-driven; every referenced role must be an installed role or tap-agent tag.\"\ndomains: octomind\nrules:\n  - content(workflow)\n  - file(*workflow*.toml)\n  - grep(\\[\\[steps\\]\\], *.toml)\n---\n\n## Overview\n\n`octomind workflow \u003Cfile.toml|name>` is an external orchestrator: it chains `octomind run --format jsonl` subprocesses into a multi-step pipeline, passing outputs between steps by name. This skill covers how to design a pipeline that is efficient and reliable, and the exact TOML syntax. It applies to any domain.\n\n## Mental model\n\nA workflow is a predefined code path: you fix the steps at authoring time and the orchestrator executes them deterministically. If you cannot enumerate the steps in advance, use a single agent run instead.\n\nEach step starts with a fresh context and knows only what its prompt template passes in — no drift, but also no implicit memory. Every step name becomes a `{{name}}` variable holding that step's full output; `{{input}}` is stdin.\n\n```\nstdin ─► octomind workflow file.toml\n            ├─ per step → octomind run --format jsonl (subprocess)\n            ├─ stderr: each step's reply, progress, cost, tokens, totals\n            └─ stdout: empty, or JSONL events with --format jsonl\n```\n\n## Designing the workflow\n\n### Pattern selection\n\nUse the fewest steps that work. Every handoff is lossy, so the burden of proof is on adding a step.\n\n| Task shape | Pattern | Primitive |\n|------------|---------|-----------|\n| Fixed subtasks, each easier than the whole | Prompt chaining | Sequential |\n| Distinct input categories, accurate classifier | Routing | Conditional or graph edges |\n| Independent subtasks known upfront | Sectioning | Parallel |\n| Same task, diverse perspectives | Voting | Parallel + aggregator |\n| N similar items produced by an earlier step | Fan-out | Dynamic parallel (`source` + `match`) |\n| Output improves against clear criteria | Evaluator-optimizer | Loop |\n| Cycles or multi-way routing | State machine | Graph mode |\n| Subtasks unknowable before runtime | Orchestrator-workers | Not a workflow — single agent run |\n\n### When to split a step\n\nSplit only when a different persona, a different model, a gate on the intermediate output, independent verifiability, or parallel speedup demands it. For every boundary, name the artifact that crosses it in one sentence; if it is \"the same content, slightly transformed\", merge the steps.\n\n### Handoff contracts\n\nStep output is an API. End every prompt with \"Output only the \u003Cartifact> — no preamble.\" Gates match substrings or regexes, so the emitting step must produce a machine-checkable sentinel:\n\n- Key:value tokens, never bare words: `VERDICT: APPROVED`, not `APPROVED`.\n- Both outcomes as distinct positive tokens (`VERDICT: APPROVED` \u002F `VERDICT: REVISE`); never define one as the absence of the other.\n- Demand the exact last line in the emitting prompt and anchor with `matches = '(?m)^VERDICT: APPROVED'` when precision matters.\n- Test the gate against a known-good output (must match) and a known-bad one (must not).\n\n### Loops that converge\n\n- `max_iterations` 2–3; worst-case cost is iterations × calls per iteration.\n- The critic gets a finite rubric and a binary verdict on the last line, and is told to approve when every rubric item passes.\n- With `session = \"continue\"`, iteration 2+ replaces the templated prompt with the most recent prior step's raw output, so the critique reaches the reviser while the session keeps its original instructions.\n- Hitting `max_iterations` exits with the last outputs and a warning; the workflow continues. Gate on the verdict afterwards if an unapproved artifact must not ship.\n\n### Context and cost\n\n- Pass only the variables a step needs — usually the immediate predecessor.\n- Summarize evidence, never artifacts that must be reproduced verbatim.\n- In long prompts put data first, instructions last: `\u003Cinput>{{prev}}\u003C\u002Finput>` then the task.\n- Per-step `model`: cheap models for extraction, routing, formatting; strong ones for generation and evaluation. Set `max_cost` to bound runaway spend.\n\n## File format\n\n```toml\nname        = \"my-workflow\"        # required\ndescription = \"Optional description\"\n# max_cost  = 2.5                  # USD cap, checked between steps\n\n[[steps]]                          # sequential (default kind)\nname    = \"outline\"                # unique across the file\nrole    = \"demo:writer\"            # installed role or tap tag (placeholder shown)\nprompt  = \"\"\"\n{{input}}\n\nProduce a structured outline. Output only the outline.\n\"\"\"\nsession = \"fresh\"                  # \"fresh\" (default) | \"continue\"\ntimeout = 0                        # seconds, 0 = none\nretries = 0                        # extra attempts on failure\n# model = \"\u003Cprovider>:\u003Cmodel>\"     # forwarded as --model\n# workdir = \"path\"                 # resolved against the orchestrator cwd at run time\n# skills = [\"skill-name\"]          # forwarded as OCTOMIND_SKILLS\n# capabilities = [\"websearch\"]     # forwarded as OCTOMIND_CAPABILITIES\n```\n\nUnknown keys are ignored silently, so check spelling against this reference.\n\n## Step types\n\nA `[[steps]]` table is sequential unless it sets exactly one of `parallel`, `loop`, or `conditional` to `true`.\n\n| Kind | Required | Behaviour |\n|------|----------|-----------|\n| Sequential | `name`, `role`, `prompt` | One `octomind run` |\n| Parallel | `name`, ≥2 `[[steps.run]]` | Sub-steps run concurrently; the next step waits for all |\n| Loop | `name`, ≥1 `[[steps.run]]`, `exit_when` | Sub-steps repeat until `exit_when` matches or `max_iterations` (default 10) |\n| Conditional | `name`, `condition`, ≥1 `[[steps.run]]`, `on_match` and\u002For `on_no_match` | Runs the listed sub-steps; skipped ones resolve to empty strings |\n\nSub-steps accept the same optional fields as sequential steps. Parallel sub-steps cannot reference each other.\n\nParallel extras: `count = N` (N ≥ 2) on a sub-step replicates it; `max_parallel` caps concurrency; `min_success` (1..total replicas) relaxes the all-must-succeed default. Dynamic fan-out: exactly one template sub-step plus `source = \"\u003Cearlier step>\"` and `match = \"\u003Cregex with one capture group>\"`. Each match spawns a branch; inside it `{{\u003Cblock name>}}` is that branch's captured item, and the accumulated output lands under the sub-step's name.\n\n### Graph mode\n\nSetting `entry = \"\u003Cstep>\"` or any `[[edges]]` switches to explicit routing. Edges have `from`, `to`, and optional `when` (condition shape); the first matching conditional edge wins, and each node needs exactly one unconditional edge declared last. `max_transitions` (required) bounds total hops, and routing ends at `$end`. Every node must be reachable with a route to `$end`. Referencing an output that the current route never produced fails at run time.\n\n### Condition shape\n\n`exit_when`, `condition`, and edge `when` take `output` (step name, default the previous step), plus exactly one of `contains` (substring) or `matches` (Rust regex).\n\n## Variables\n\n- `{{input}}` — stdin; `{{step_name}}` — output of an earlier step. Names match `[A-Za-z_][A-Za-z0-9_-]*`; `input` and `$end` are reserved.\n- Built-in placeholders also expand: `{{DATE}}`, `{{CWD}}`, `{{SHELL}}`, `{{OS}}`, `{{BINARIES}}`, `{{ROLE}}`, `{{SYSTEM}}`, `{{CONTEXT}}`, `{{GIT_STATUS}}`, `{{GIT_TREE}}`, `{{README}}`.\n- A `\u003Ccontext>path\u003C\u002Fcontext>` or `\u003Ccontext>path:start:end\u003C\u002Fcontext>` block in a prompt is replaced with that file's contents.\n\n## Validation rules\n\nChecked before any step runs: valid TOML with at least one step; unique, non-empty step names; every `{{var}}` is a builtin, `input`, or an earlier step; parallel ≥2 sub-steps (or one template with `source`+`match`); loop has `exit_when`; conditional branches name existing sub-steps; regexes compile; `model`\u002F`workdir` non-empty when set; `count` only on parallel sub-steps; `max_cost` positive; graph constraints above. Not checked: role existence for local files (a bad role fails when its subprocess spawns) and workdir existence.\n\nWorkflows fetched from a tap are additionally restricted to public `domain:spec` tap roles, so they stay portable.\n\n## CLI\n\n```bash\noctomind workflow                                  # list tap workflows\noctomind workflow myflow.toml --dry-run            # validate + print plan, no spawn, no stdin\necho \"notes...\" | octomind workflow myflow.toml    # run a local file\necho \"...\" | octomind workflow \u003Cname>              # run a tap workflow\necho \"...\" | octomind workflow myflow.toml --format jsonl   # assistant event per step + final cost event on stdout\n```\n\nAn argument containing `\u002F` or ending in `.toml` is a file; anything else is looked up in taps' `workflows\u002F`. stdin is required and must be non-empty unless `--dry-run`. Without `--format jsonl` stdout is empty: each step's reply, progress, and the totals go to stderr. To consume the final result programmatically, use `--format jsonl` and take the last `assistant` event.\n\nInside a session: `\u002Fworkflow \u003Cname> \u003Cinput>` runs a tap workflow; agents with the `orchestration` capability can use `tap(action=\"workflow\")`.\n\nRetries rerun the whole step — keep `retries = 0` on steps whose role writes files or calls external APIs unless they are idempotent.\n\n## Examples\n\n### Generator ↔ critic loop with a sentinel contract\n\n```toml\nname = \"report-with-review\"\n\n[[steps]]\nname   = \"draft\"\nrole   = \"demo:writer\"\nprompt = \"\u003Cinput>\\n{{input}}\\n\u003C\u002Finput>\\n\\nWrite the report. Output only the report.\"\n\n[[steps]]\nname           = \"refine\"\nloop           = true\nmax_iterations = 3\nexit_when      = { output = \"critic\", matches = '(?m)^VERDICT: APPROVED' }\n\n  [[steps.run]]\n  name    = \"reviser\"\n  role    = \"demo:writer\"\n  session = \"continue\"\n  prompt  = \"Improve this report:\\n{{draft}}\\n\\nOutput only the report.\"\n\n  [[steps.run]]\n  name    = \"critic\"\n  role    = \"demo:critic\"\n  session = \"continue\"\n  prompt  = \"\"\"\nReview against this rubric only: claims sourced; structure follows brief; no filler.\nCritique failing items specifically. If every item passes, approve — do not invent criteria.\n\n\u003Creport>\n{{reviser}}\n\u003C\u002Freport>\n\nEnd with exactly one line: VERDICT: APPROVED or VERDICT: REVISE.\n\"\"\"\n```\n\nIteration 1 sends both templated prompts; from iteration 2 the `continue` rule feeds the critique to the reviser and the revision to the critic.\n\n### Dynamic fan-out\n\n```toml\nname = \"fan-out\"\n\n[[steps]]\nname   = \"plan\"\nrole   = \"demo:planner\"\nprompt = \"List the sub-questions for: {{input}}\\nOne per line as: Q: \u003Cquestion>\"\n\n[[steps]]\nname         = \"q\"\nparallel     = true\nsource       = \"plan\"\nmatch        = '(?m)^Q: (.+)$'\nmax_parallel = 4\n\n  [[steps.run]]\n  name   = \"answers\"\n  role   = \"demo:researcher\"\n  prompt = \"Answer concisely: {{q}}\"\n```\n\n### Common mistake — forward reference\n\n```toml\n[[steps]]\nname   = \"outline\"\nrole   = \"demo:writer\"\nprompt = \"Refine using {{review}}\"   # review runs later → pre-flight error\n```\n\n## Checklist\n\n- [ ] Could a single `octomind run` do this? Every step justified by a splitting gate?\n- [ ] Handoff artifact nameable for every boundary; prompts end with \"output only the artifact\"?\n- [ ] Every gate matches a key:value sentinel the emitting prompt demands on its last line?\n- [ ] Loops bounded at 2–3 with a binary verdict and an approve-when-passing critic?\n- [ ] Cheap vs strong `model` chosen per step; `max_cost` set for open-ended runs?\n- [ ] Every role installed (`octomind complete run`) and each step tested standalone?\n- [ ] `--dry-run` clean; result consumed via `--format jsonl` when scripted?\n\n## References\n\n- `octomind workflow \u003Cfile.toml> --dry-run` — validate and inspect the resolved plan\n- Octomind docs: `doc\u002Fusage\u002F09-workflows.md`; `config-templates\u002Fworkflow*.toml` in the octomind source\n- [Anthropic — Building Effective Agents](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents) — the patterns behind the design layer\n","## Overview\n\n`octomind workflow \u003Cfile.toml|name>` is an external orchestrator: it chains `octomind run --format jsonl` subprocesses into a multi-step pipeline, passing outputs between steps by name. This skill covers how to design a pipeline that is efficient and reliable, and the exact TOML syntax. It applies to any domain.\n\n## Mental model\n\nA workflow is a predefined code path: you fix the steps at authoring time and the orchestrator executes them deterministically. If you cannot enumerate the steps in advance, use a single agent run instead.\n\nEach step starts with a fresh context and knows only what its prompt template passes in — no drift, but also no implicit memory. Every step name becomes a `{{name}}` variable holding that step's full output; `{{input}}` is stdin.\n\n```\nstdin ─► octomind workflow file.toml\n            ├─ per step → octomind run --format jsonl (subprocess)\n            ├─ stderr: each step's reply, progress, cost, tokens, totals\n            └─ stdout: empty, or JSONL events with --format jsonl\n```\n\n## Designing the workflow\n\n### Pattern selection\n\nUse the fewest steps that work. Every handoff is lossy, so the burden of proof is on adding a step.\n\n| Task shape | Pattern | Primitive |\n|------------|---------|-----------|\n| Fixed subtasks, each easier than the whole | Prompt chaining | Sequential |\n| Distinct input categories, accurate classifier | Routing | Conditional or graph edges |\n| Independent subtasks known upfront | Sectioning | Parallel |\n| Same task, diverse perspectives | Voting | Parallel + aggregator |\n| N similar items produced by an earlier step | Fan-out | Dynamic parallel (`source` + `match`) |\n| Output improves against clear criteria | Evaluator-optimizer | Loop |\n| Cycles or multi-way routing | State machine | Graph mode |\n| Subtasks unknowable before runtime | Orchestrator-workers | Not a workflow — single agent run |\n\n### When to split a step\n\nSplit only when a different persona, a different model, a gate on the intermediate output, independent verifiability, or parallel speedup demands it. For every boundary, name the artifact that crosses it in one sentence; if it is \"the same content, slightly transformed\", merge the steps.\n\n### Handoff contracts\n\nStep output is an API. End every prompt with \"Output only the \u003Cartifact> — no preamble.\" Gates match substrings or regexes, so the emitting step must produce a machine-checkable sentinel:\n\n- Key:value tokens, never bare words: `VERDICT: APPROVED`, not `APPROVED`.\n- Both outcomes as distinct positive tokens (`VERDICT: APPROVED` \u002F `VERDICT: REVISE`); never define one as the absence of the other.\n- Demand the exact last line in the emitting prompt and anchor with `matches = '(?m)^VERDICT: APPROVED'` when precision matters.\n- Test the gate against a known-good output (must match) and a known-bad one (must not).\n\n### Loops that converge\n\n- `max_iterations` 2–3; worst-case cost is iterations × calls per iteration.\n- The critic gets a finite rubric and a binary verdict on the last line, and is told to approve when every rubric item passes.\n- With `session = \"continue\"`, iteration 2+ replaces the templated prompt with the most recent prior step's raw output, so the critique reaches the reviser while the session keeps its original instructions.\n- Hitting `max_iterations` exits with the last outputs and a warning; the workflow continues. Gate on the verdict afterwards if an unapproved artifact must not ship.\n\n### Context and cost\n\n- Pass only the variables a step needs — usually the immediate predecessor.\n- Summarize evidence, never artifacts that must be reproduced verbatim.\n- In long prompts put data first, instructions last: `\u003Cinput>{{prev}}\u003C\u002Finput>` then the task.\n- Per-step `model`: cheap models for extraction, routing, formatting; strong ones for generation and evaluation. Set `max_cost` to bound runaway spend.\n\n## File format\n\n```toml\nname        = \"my-workflow\"        # required\ndescription = \"Optional description\"\n# max_cost  = 2.5                  # USD cap, checked between steps\n\n[[steps]]                          # sequential (default kind)\nname    = \"outline\"                # unique across the file\nrole    = \"demo:writer\"            # installed role or tap tag (placeholder shown)\nprompt  = \"\"\"\n{{input}}\n\nProduce a structured outline. Output only the outline.\n\"\"\"\nsession = \"fresh\"                  # \"fresh\" (default) | \"continue\"\ntimeout = 0                        # seconds, 0 = none\nretries = 0                        # extra attempts on failure\n# model = \"\u003Cprovider>:\u003Cmodel>\"     # forwarded as --model\n# workdir = \"path\"                 # resolved against the orchestrator cwd at run time\n# skills = [\"skill-name\"]          # forwarded as OCTOMIND_SKILLS\n# capabilities = [\"websearch\"]     # forwarded as OCTOMIND_CAPABILITIES\n```\n\nUnknown keys are ignored silently, so check spelling against this reference.\n\n## Step types\n\nA `[[steps]]` table is sequential unless it sets exactly one of `parallel`, `loop`, or `conditional` to `true`.\n\n| Kind | Required | Behaviour |\n|------|----------|-----------|\n| Sequential | `name`, `role`, `prompt` | One `octomind run` |\n| Parallel | `name`, ≥2 `[[steps.run]]` | Sub-steps run concurrently; the next step waits for all |\n| Loop | `name`, ≥1 `[[steps.run]]`, `exit_when` | Sub-steps repeat until `exit_when` matches or `max_iterations` (default 10) |\n| Conditional | `name`, `condition`, ≥1 `[[steps.run]]`, `on_match` and\u002For `on_no_match` | Runs the listed sub-steps; skipped ones resolve to empty strings |\n\nSub-steps accept the same optional fields as sequential steps. Parallel sub-steps cannot reference each other.\n\nParallel extras: `count = N` (N ≥ 2) on a sub-step replicates it; `max_parallel` caps concurrency; `min_success` (1..total replicas) relaxes the all-must-succeed default. Dynamic fan-out: exactly one template sub-step plus `source = \"\u003Cearlier step>\"` and `match = \"\u003Cregex with one capture group>\"`. Each match spawns a branch; inside it `{{\u003Cblock name>}}` is that branch's captured item, and the accumulated output lands under the sub-step's name.\n\n### Graph mode\n\nSetting `entry = \"\u003Cstep>\"` or any `[[edges]]` switches to explicit routing. Edges have `from`, `to`, and optional `when` (condition shape); the first matching conditional edge wins, and each node needs exactly one unconditional edge declared last. `max_transitions` (required) bounds total hops, and routing ends at `$end`. Every node must be reachable with a route to `$end`. Referencing an output that the current route never produced fails at run time.\n\n### Condition shape\n\n`exit_when`, `condition`, and edge `when` take `output` (step name, default the previous step), plus exactly one of `contains` (substring) or `matches` (Rust regex).\n\n## Variables\n\n- `{{input}}` — stdin; `{{step_name}}` — output of an earlier step. Names match `[A-Za-z_][A-Za-z0-9_-]*`; `input` and `$end` are reserved.\n- Built-in placeholders also expand: `{{DATE}}`, `{{CWD}}`, `{{SHELL}}`, `{{OS}}`, `{{BINARIES}}`, `{{ROLE}}`, `{{SYSTEM}}`, `{{CONTEXT}}`, `{{GIT_STATUS}}`, `{{GIT_TREE}}`, `{{README}}`.\n- A `\u003Ccontext>path\u003C\u002Fcontext>` or `\u003Ccontext>path:start:end\u003C\u002Fcontext>` block in a prompt is replaced with that file's contents.\n\n## Validation rules\n\nChecked before any step runs: valid TOML with at least one step; unique, non-empty step names; every `{{var}}` is a builtin, `input`, or an earlier step; parallel ≥2 sub-steps (or one template with `source`+`match`); loop has `exit_when`; conditional branches name existing sub-steps; regexes compile; `model`\u002F`workdir` non-empty when set; `count` only on parallel sub-steps; `max_cost` positive; graph constraints above. Not checked: role existence for local files (a bad role fails when its subprocess spawns) and workdir existence.\n\nWorkflows fetched from a tap are additionally restricted to public `domain:spec` tap roles, so they stay portable.\n\n## CLI\n\n```bash\noctomind workflow                                  # list tap workflows\noctomind workflow myflow.toml --dry-run            # validate + print plan, no spawn, no stdin\necho \"notes...\" | octomind workflow myflow.toml    # run a local file\necho \"...\" | octomind workflow \u003Cname>              # run a tap workflow\necho \"...\" | octomind workflow myflow.toml --format jsonl   # assistant event per step + final cost event on stdout\n```\n\nAn argument containing `\u002F` or ending in `.toml` is a file; anything else is looked up in taps' `workflows\u002F`. stdin is required and must be non-empty unless `--dry-run`. Without `--format jsonl` stdout is empty: each step's reply, progress, and the totals go to stderr. To consume the final result programmatically, use `--format jsonl` and take the last `assistant` event.\n\nInside a session: `\u002Fworkflow \u003Cname> \u003Cinput>` runs a tap workflow; agents with the `orchestration` capability can use `tap(action=\"workflow\")`.\n\nRetries rerun the whole step — keep `retries = 0` on steps whose role writes files or calls external APIs unless they are idempotent.\n\n## Examples\n\n### Generator ↔ critic loop with a sentinel contract\n\n```toml\nname = \"report-with-review\"\n\n[[steps]]\nname   = \"draft\"\nrole   = \"demo:writer\"\nprompt = \"\u003Cinput>\\n{{input}}\\n\u003C\u002Finput>\\n\\nWrite the report. Output only the report.\"\n\n[[steps]]\nname           = \"refine\"\nloop           = true\nmax_iterations = 3\nexit_when      = { output = \"critic\", matches = '(?m)^VERDICT: APPROVED' }\n\n  [[steps.run]]\n  name    = \"reviser\"\n  role    = \"demo:writer\"\n  session = \"continue\"\n  prompt  = \"Improve this report:\\n{{draft}}\\n\\nOutput only the report.\"\n\n  [[steps.run]]\n  name    = \"critic\"\n  role    = \"demo:critic\"\n  session = \"continue\"\n  prompt  = \"\"\"\nReview against this rubric only: claims sourced; structure follows brief; no filler.\nCritique failing items specifically. If every item passes, approve — do not invent criteria.\n\n\u003Creport>\n{{reviser}}\n\u003C\u002Freport>\n\nEnd with exactly one line: VERDICT: APPROVED or VERDICT: REVISE.\n\"\"\"\n```\n\nIteration 1 sends both templated prompts; from iteration 2 the `continue` rule feeds the critique to the reviser and the revision to the critic.\n\n### Dynamic fan-out\n\n```toml\nname = \"fan-out\"\n\n[[steps]]\nname   = \"plan\"\nrole   = \"demo:planner\"\nprompt = \"List the sub-questions for: {{input}}\\nOne per line as: Q: \u003Cquestion>\"\n\n[[steps]]\nname         = \"q\"\nparallel     = true\nsource       = \"plan\"\nmatch        = '(?m)^Q: (.+)$'\nmax_parallel = 4\n\n  [[steps.run]]\n  name   = \"answers\"\n  role   = \"demo:researcher\"\n  prompt = \"Answer concisely: {{q}}\"\n```\n\n### Common mistake — forward reference\n\n```toml\n[[steps]]\nname   = \"outline\"\nrole   = \"demo:writer\"\nprompt = \"Refine using {{review}}\"   # review runs later → pre-flight error\n```\n\n## Checklist\n\n- [ ] Could a single `octomind run` do this? Every step justified by a splitting gate?\n- [ ] Handoff artifact nameable for every boundary; prompts end with \"output only the artifact\"?\n- [ ] Every gate matches a key:value sentinel the emitting prompt demands on its last line?\n- [ ] Loops bounded at 2–3 with a binary verdict and an approve-when-passing critic?\n- [ ] Cheap vs strong `model` chosen per step; `max_cost` set for open-ended runs?\n- [ ] Every role installed (`octomind complete run`) and each step tested standalone?\n- [ ] `--dry-run` clean; result consumed via `--format jsonl` when scripted?\n\n## References\n\n- `octomind workflow \u003Cfile.toml> --dry-run` — validate and inspect the resolved plan\n- Octomind docs: `doc\u002Fusage\u002F09-workflows.md`; `config-templates\u002Fworkflow*.toml` in the octomind source\n- [Anthropic — Building Effective Agents](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents) — the patterns behind the design layer\n",{"name":5,"rules":56,"title":60,"domains":32,"license":14,"description":7,"compatibility":61},[57,58,59],"content(workflow)","file(*workflow*.toml)","grep(\\[\\[steps\\]\\], *.toml)","Octomind Workflow Design & Syntax","Requires: octomind CLI with the `workflow` subcommand. Workflows are stdin-driven; every referenced role must be an installed role or tap-agent tag.","master","e9e4a19559669b1627b1ac5ed3f77b8e36cfad95","skills\u002Foctomind-workflow",0,"https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap","https:\u002F\u002Foctomind.run\u002Ftap\u002F","https:\u002F\u002Fgithub.com\u002FMuvon","https:\u002F\u002Fmuvon.io","We bring ideas to life","2026-11-10 20:30:54",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add Muvon\u002Foctomind-tap --skill octomind-workflow",{"tool":78,"command":79},"bunx","bunx skills add Muvon\u002Foctomind-tap --skill octomind-workflow",{"tool":81,"command":82},"pnpm","pnpm dlx skills add Muvon\u002Foctomind-tap --skill octomind-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Foctomind-workflow\u002FSKILL.md",true,[],[87,123,150,170,194,217],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":102,"publishedAt":51},"01M70SFC5CTHRKA9B97N1ARVZ2","seo-content-refresh","Finds decaying pages, picks update, merge, redirect or remove, and briefs each refresh. Use to prioritize existing content and judge whether it helped.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fseo-content-refresh\u002FSKILL.md",[93,96,99],{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":97,"categoryName":98,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000035","市场营销",{"categoryNo":100,"categoryName":101,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者",[103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"seo content refresh","seo","seo content","content refresh","refresh","content","posts","remove","web search","performance","search","traffic","access","drop","websearch","revamp","merge","diagnosis","update","decay",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":51},"01M70SBWQCHGH7HGS51Y0GTKKW","marketing-review-program","Plans how to ask real customers for honest public reviews: site choice, invitation copy, incentive and disclosure rules. Use to start a review program.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fmarketing-review-program\u002FSKILL.md",[129,130],{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":97,"categoryName":98,"taxonomyType":28,"taxonomyTypeDesc":29},[132,133,134,135,136,137,111,113,138,139,140,141,142,143,144,145,146,147,148,149],"program","review","marketing review program","marketing","reviews","get","campaign","choice","how to","only","generated","ask","plan","product","generate","customer","how","request",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":51},"01M70SBB65Z2FC71Q7DEAXGJBG","geo-source-actions","Turns AI citation findings into ranked per-source actions for Reddit threads, listicles, review sites and videos. Records only. Use after a GEO audit.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fgeo-source-actions\u002FSKILL.md",[],[157,158,159,160,161,137,111,113,162,163,141,117,133,164,165,166,145,167,168,169],"actions","geo source actions","source","geo","sources","copilot","domains","llms","threads","youtube","audit","action","data",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":179,"publishedAt":51},"01M70S99D3Y6GF097GTXWBXHPW","commerce-ai-readiness","Audits product feeds, markup and live pages for AI shopping assistants, then lists exact fixes. Use to make a store catalog readable to AI shoppers.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Fcommerce-ai-readiness\u002FSKILL.md",[176],{"categoryNo":177,"categoryName":178,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000031","产品经理",[180,181,182,183,184,185,186,187,188,189,113,190,162,141,115,191,192,145,167,193],"ai readiness","commerce ai readiness","commerce","readiness","feeds","ready","show","shopping","discover","checkout","up","ecommerce","documentation","recommend",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":51},"01M6DWSX45J42KTK6XASKJRGPA","tap-model-training","Train, evaluate and publish the octomind-embed model behind capability auto-activation. Use when capability triggers or skill semantic() phrases change.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-model-training\u002FSKILL.md",[200],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[202,203,49,204,205,190,206,207,208,209,210,211,212,213,214,148,215,216,42,121],"model","training","tap model training","scope","eval","uv","auto","dataset","activate","api","capabilities","publish","change","embedding","re",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":224,"publishedAt":51},"01M6DWSQB7NSW53Z86XM81R1W1","tap-deps-authoring","Write dep scripts for the octomind-tap registry: header comments, platform.sh, mcp vs dep types, npx\u002Fuvx pattern. Use when editing deps\u002F\u003Corg>\u002F\u003Ctool>.sh.","https:\u002F\u002Fgithub.com\u002FMuvon\u002Foctomind-tap\u002Fblob\u002Fmaster\u002Fskills\u002Ftap-deps-authoring\u002FSKILL.md",[223],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},[225,49,226,227,228,229,230,231,232,233,234,235,236,237,238,239,42,240,241,242],"deps","tap deps authoring","authoring","DEP","MCP","run","scripts","pattern","install","registry","platform","repo","editing","tool","types","write","org","for"]