用途
该技能是 CreateWorkflow 工具的完整创作契约，聚焦动态工作流脚本的编写、调试与重新提交。据资料，CreateWorkflow、AmendWorkflow、FillWorkflowHole、SaveWorkflow 和 EvalWorkflowSnippet 在加载本技能之前会拒绝运行，因此它也是使用这些工具的前置条件。资料同时说明，CreateWorkflow 是动态工作流工具，而遗留的 Workflow 工具与 /expert 属于另一个旧特性，二者名称相同但并非同一对象。
核心目标
工作流的存在目的是产出专家级、可直接交付的成果，而非单个回复的更快草稿。用户明确要求使用工作流（如“使用 workflow”“用工作流”等）时，必须使用 CreateWorkflow，即使 Agent 或单次回复本可完成。只有用户显式点名工作流或以 /workflow 发起时才启动工作流，不能仅凭任务看起来像编排就自行决定。深度按风险衡量：错误结论会给用户带来代价的地方才投入校验，每个工作单元获得一个能定论的检查。捷径与专家做法冲突时取专家做法；任务小时可裁剪工作量，错误代价小或命令已定论时可裁剪检查。
主要能力
工具选择与规模判断
资料给出路由表：单个任务交给单个代理用 Agent；若干互不阅读彼此结果的独立查询用并行 Agent；用户未点名工作流的其它多步任务用 Agent 或自己做；用户明确以工作流为手段则强制使用 CreateWorkflow。显式请求具有约束力，剩下的只是脚本规模问题，最小任务也可对应一个小工作流。每个任务都是一次完整模型会话，会话应放在能提升置信度的地方，而不是彼此重复的地方。例如“审查改动的文件”适合每个文件一个审查者加每个发现一个确认者；“写二十首诗”适合二十个诗人而不需要确认者。当后续阶段依赖前序发现时，应写到该点为止，以“洞”（hole）结尾，让发现结果决定后续。
子代理拓扑
每次 agent() 调用都会新建上下文。独立项适合每个子代理只看到自己那一项并行运行；需要彼此答案一致时适合共享一个上下文，但同一子代理的 ask 按 FIFO 排队，会串行化。把 agent() 调用提到循环外会把扇出变成队列，且没有机制会拒绝这种脚本。同一运行中不得有两个子代理共享非空名称，重名会导致运行失败；扇出中写固定名字会每项重复，应使用如 agent(judge-${i.id})；匿名永远安全。具名子代理在修订重跑时可按名称命中缓存，指令未变的 ask 以零 token 导入；匿名子代理从空开始。人设在创建时冻结，应写角色与判断标准，不必重写 harness 自带的子代理契约（引用 path:line、不报告未运行的检查、说明做不到的事、升级而非作假）。所有子代理工具相同，允许做什么写在 ask 里。仅在用户要求或明显适用轻量层（如裁判、路由）时按子代理指定模型，模型 id 来自 ListModels。
流水线与汇合
多于一个阶段的工作流应像流水线运行：各阶段同时工作，每项就绪即进入下一阶段。只有下一步需要全部项时才让阶段等待，例如跨文件去重、统一尺度排序、综合。Promise.all 是汇合也是屏障；并行来自暂不 await。作者应在每个交接点决定项目如何离开阶段：下一步逐项处理且一对一时，把各阶段在单个扇出内逐项串联、最后汇合一次；若由共享工作池服务某阶段、下一阶段工作时仍在发现项、后续阶段会把工作送回，则用通道加每阶段 future；下一步需要全部项时才整体汇合。
新鲜视角
计划或草稿的作者看不到自己填补的空隙，而独立上下文的读者没有这种填补，空隙因此显现。该原则适用于工作流内每个起草环节（计划、修复、发现、最终报告），在计划上收益最大。四条规则：使用独立上下文而非同一头脑的第二意见；要求指出失败而非请求批准，提问应让“批准”需要证据而“反对”成为容易动作；让评审者获得相同证据，如计划涉及代码则让评审者阅读相关文件且不得编辑；为纯文本交付物安排独立读者代理，询问哪里不清楚、文本未支撑什么、用户接下来会问什么，然后修正，并说明读者仅凭文本判断，核实主张是确认者的职责。注意事项：同类模型同提示的评审者盲区相关，收益有限，应给不同视角；一个交付物最多一个机制加一个理由；这些规则针对脚本内子代理，而非提交门槛；作者应自行通读脚本一遍，并在每个 Promise.all 处判断下一步是否需要全部项，不需要则改为流水线。
类型化结果
当控制流要依据答案分支时，给 ask 传类型参数；只需散文时不传。类型必须是脚本中编写的 interface 或类型别名。属性上的 JSDoc 会成为子代理实际读取的字段描述，这是成本最低的质量杠杆，不应跳过。结果应保持窄：结果跨模式边界并插值进下一个提示，过宽会两次消耗 token；传路径而非文件内容，子代理自有文件工具。
获取世界信息与确定性门禁
files.glob 和 git.changedFiles 用于让脚本获知要扇出什么，二者由 harness 执行、记录并在恢复时重放。上限会拒绝而非截断，应缩窄模式而非在静默不完整视图上扇出。读取可捕获，因此可用更粗的兜底作为 catch，git 调用在仓库外都会拒绝，需要这种兜底。仅当脚本自身必须按内容分片或分支时才用 files.read 或 files.grep；读文件是子代理的工作。world.run 是确定性门禁：当检查固定且机器可判定（构建通过、证明检验、测试全绿），以代码运行并按退出码分支，而非让子代理运行并信任其声明。非零退出码是值而非异常，读 exitCode 并把 stderr 作为下一轮反馈，不用 catch；拒绝仅用于世界无法回答（spawn 失败、超时、输出超上限）。命令名必须是编译期字符串字面量，因为用户在确认时批准脚本的命令集；路径、标志、轮次应插值进 args 数组，不得插值进命令。开放式编辑属于子代理，world.run 用于控制流要分支的检查。写门禁前应先选择门禁：查看仓库有哪些检查（package.json scripts、Makefile 目标、CI 配置、README 的验证命令），按能决定多少排序；然后分两层构建，快层可驱动循环轮次，请求蕴含的最强层决定退出，并在最终返回前至少真实运行一次，即使快层已通过。慢层要给足 timeoutMs；更快的替代是另一种检查。仓库中存在却未运行的检查不算“未覆盖”，而是未核实工作。
提交前测试片段
工作流脚本在提交时即固定，但其中的固定逻辑不必如此：先用 EvalWorkflowSnippet 同步运行，不持久化任何内容。通过的内容可原样粘贴进工作流。片段以代码或文件路径发送，第二次尝试只需一次 Edit。片段工作是非子代理部分：glob 实际返回什么、grep 模式是否会超上限、world.run 的 stderr 如何解析、门禁谓词是否符合意图。片段有 files.、git.、world.run 和 log，但没有 agent()。一旦知道哪个检查决定结果，也应在片段中运行一次，以查看其输出、是否如设想那样非零退出以及耗时。
循环
每个循环都应有轮次上限并向前携带反馈，例如在规划者与评审者之间循环，评审未通过则把反馈带入下一轮，最多五轮。跨轮复用同一对子代理可保留上下文、降低成本，但复用会损失新鲜度，所以最后应加一个独立评审者。子代理不能调用 CreateWorkflow，不得嵌套；大的子任务应建模为更多子代理。
适用场景
适用于用户明确要求工作流、需要多子代理协作产出专家级成果的撰写、审查、修复、分析类任务；也适用于调试和重新提交动态工作流脚本、验证片段逻辑、构建确定性命中门禁与流水线编排。
限制
只有显式请求才启动工作流；脚本提交后固定；具名子代理不得重名；world.run 命令名必须是编译期字面量；子代理不能嵌套调用 CreateWorkflow；片段环境没有 agent()；检查上限会拒绝而非截断。资料未提供价格、收费、平台兼容性或具体安装命令，这些事实暂未提供。