using-workflows

使用工作流

你需要判断当前情况需要哪种配方，填入其参数，运行它，并让闭环持续推进。你不是配方。

BYPASS — 先检查

一项有界任务、单一上下文、没有阶段、没有收敛条件 → 直接处理（内联完成，或通过 using-tmux-agent-tools 使用一个工作器）。无需配方，也无需运行目录。拿不准时就绕过——配方是为循环而存在，不是走形式。

例外：跨多个来源或多轮次的研究（查找、比较价格、收集来源）不属于绕过范围——转到 haiku-research-round。只需调用一次工具即可获得的事实，直接内联处理。

真正让我们吃过亏的危险信号（若仍要提及并继续，必须说明理由）：

• 「我记得那支 recipe 的内容」— 配方会不断演进；运行前先阅读头部注释（参数约定）。绝不可猜测参数。
• 「先做完再补 run record」— 若符合下方运行目录的要求，先创建目录。
• 「这个小改不用 gate」— 对任何配方进行行为层级的编辑，确实需要先进行一轮共识门控。

子 Agent 豁免：委派的工作器不会进入此路由器——调度器已完成路由；工作器遵循其任务说明。

触发条件

具有循环结构的工作：包含多个阶段并带有收敛条件。审计链、共识评审、计划→构建生命周期、发现项分类。

来自 Continuity 触发条件（全局 CLAUDE.md/AGENTS.md）

全局规则要求在任务开始时，将具有循环结构的工作路由至此处。抵达后：

1. 将触发词（审计 / 共识验证 / 发现项分类 / 根因深度分析 / 计划→构建）匹配至下方 SELECT 中的配方。
2. 运行时分工：Claude 通过 Workflow 原生调用配方；Codex 通过 references/codex-adapter.md（claude-workflow-runner）运行配方——该 runner 只执行机械操作，因此以 opus 的 low effort 运行（最低档；见 MODEL FLOOR）。
3. 写回责任：每个配方产物/结果都必须写入调用方的 .workflow/<YYYYMMDDHHMM>-<slug>/ 运行目录（Continuity 规则要求你创建的目录）——绝不可写入其他位置。一个任务 = 一个运行目录，约定和配方共用此目录。

选择

实时发现——绝不凭记忆复述配方列表：

ls ~/.claude/workflows/*.workflow.js .claude/workflows/*.workflow.js 2>/dev/null

核心循环（唯一的循环——没有调度外环；不要凭空编造）：

audit (docs-vs-code | design-vs-code | root-cause-deep-dive)
  → findings-triage        connector ①: askUser → human VERBATIM ·
  │                        briefs → lifecycle · directFix → partitioned run
  → feature-lifecycle-auto thin shell: feature-plan-consensus | plan-pipeline
  │                        → gate ✋ (autoBuild=false: human reads the plan)
  │                        → spec-implement-dual-review-verify
  → re-run the ORIGINATING audit, SAME args
  │                        connector ②: lives in YOU, not in code
  → confirmed == 0 AND no unverified/unaudited (§9.2) → converged, report · else → back to findings-triage / re-check

循环之外的入口点：

• 奇怪的 bug → root-cause-deep-dive-audit · 文档／设计出现偏差 → 对应的审计
• 某个产物需要第二个模型给出判定 → consensus-gate — 仅一轮，只用于不可逆／行为层面的变更；不是默认环节
• “这个项目接下来该做什么” → project-direction-review
• 配方集群清点／机器偏差 → workflow-manifest
• 研究（事实、价格、来源；通常需要多轮）→ 每轮使用 haiku-research-round；你始终是指挥者：阅读每轮结果，选择下一轮问题。 用户指定工具时（例如 codex-cu），你自己运行一个目标来获得可用配方，然后将工具和配方传入 args.tools；不要自行探索其他目标。侦察者遇到的阻碍只是线索（judgment-rubrics §2）。 直接工具错误须立即报告。在报告“目标无法做 X”之前，侦察者要先检查另一种实现 X 的途径。若错误是由你的工具步骤造成的，请修正，然后重新运行侦察者。

阶段配方（feature-plan-consensus、plan-pipeline、 spec-implement-dual-review-verify）通常通过 feature-lifecycle-auto 调用；只有在你只需要该阶段时才直接调用。 参数自动填充：cli 是可选项（用户裁定 2026-09-02：绝不依赖 codex）。任何已安装的 agent-tmux 配置文件都可作为有效的审查关卡——codex、 claude-fable-opus / claude-fable-gate*、cursor（grok）、agy*——选择 一个与实质性作者不同的配置；使用 ls ~/.config/agent-tmux/profiles 实时发现列表。 省略该参数时，每个阶段都会在独立上下文中使用全新的 Claude opus 审查者。绝不硬编码名称，也绝不因外部 CLI 未安装而阻塞运行。context = 单行（仓库绝对路径 + 技术栈 + 范围）。优先使用名称调用，而不是 scriptPath。 工作流 Agent 使用 mod 工具驱动 CLI 工作器：mcp__tmux-agent__assign （尚无工作器）或 tell（工作器由较早的调用返回；consensus-gate 第 2 轮及之后必须将其作为 worker 传入，否则会启动新工作器），然后使用 mcp__tmux-agent__await 等待终态结果，结果会返回给该 Agent（截至 2026-10-11，此行为有效；tmux-agent-tools ≥ a68ecd4）。 收集器仍会就同一结果向主会话发送一条通知。agent() 内部的 runtime: tmux/<profile> 行不会被拦截。cli 配方（consensus-gate、plan-pipeline、feature-plan-consensus）均以此方式工作；启动或努力程度标志需放在 cli 指定的 agent-tmux 配置文件 .conf 中。

模型下限（用户裁定 2026-09-02）

除下文所述的工作器、L1/TK 审查角色和机械执行席位（L0 运行器和 CLI 中继：sonnet medium）外，每个配方 Agent 的努力程度至少为 opus low；默认工作器为 opus medium，审查者为 high。规划、综合、修订和判定绝不使用 sonnet 或 haiku——由其中任何一个编写的计划都不算计划。sonnet 5.5+ 可以运行审查阶梯的 L1 预筛选（model-dispatch.md §Review ladder；按用户 2026-10-09 裁定，plan-pipeline 和 spec-implement-dual-review-verify 在脚本中执行此步骤，后者还会执行一次 pr-review-toolkit TK 步骤）；判定仍由 opus（L2）或 fable（L3）作出。 除此之外，经指挥者决定，sonnet/haiku 5.5+ 可以用于实现和只读数据 收集（用户裁定 2026-10-10）；配方参数负责传递此选择：spec-implement… 的 model、pr-review-triage-resolve 的 fixModel、feature-plan-consensus 的 discoverModel。

ADVISOR GATE（用户裁定，2026-09-02）

配方无法调用工具；门禁由你——指挥者——把关。在以下节点，只要 advisor 工具可用，就必须使用，并在采取下一步操作前将裁定记录到运行目录中：

1. 首次启动 Workflow 之前——简述、配方、参数（模型下限、是否省略 cli 或说明理由、轮数上限、严格时间限制）。
2. 配方返回的每个人工审核门禁处（needsUser、autoBuild=false、计划无问题 → 构建）——审核计划本身、计划规模，以及是否构建。
3. 因中止（用量限制、流程阶梯耗尽）而恢复或重新启动之前——使用同一轮运行，还是缩小范围。 没有 advisor 裁定 → 不得启动、恢复或构建。2026-09-02 的 quick-share 运行（32 个计划 Agent、输入 token 共 182M、计划 64 KB、3.5 小时内零代码）之所以未被拦截，是因为“计划修订版 N”和“批评轮次 N+1”之间没有设置门禁。

跨运行时执行

两种运行时都通过此路由器运行配方；区别仅在于执行载体。Claude Code 使用 Workflow() 原生执行 .workflow.js。Codex 则通过 ADAPTED: claude-workflow-runner 执行（一个范围受限的 Claude runner 胶囊——具体机制见 references/codex-adapter.md），并遵守以下约束（由 Codex 编写，gate-v2，2026-07-19）：

• Codex 必须在分派唯一一个 Claude runner 之前，冻结配方名称、参数、验收标准、作者运行时和审核者配置。
• Runner 必须恰好调用一次原生 Workflow(...)，将其返回结果保存在 recipe_result 下，写入 schema-v1 result.json，然后停止。
• 之后的任何例外情况都必须将嵌套层级限制为 2，声明子级配置文件和轮数上限，使用唯一会话，并要求结果必须等待，且禁止子级再启动其他任务。
• args.cli 可选：设置时，根据被审核内容的实际作者解析该参数（如果目标由 Codex 编写，则选择非 Codex 配置）；若不明确，则省略——配方中新建的 Claude opus 审核者默认充当第二视角。
• 人工审核门禁必须返回 status: paused 和 next_action，保留 recipe_result，停止 runner，并且仅通过新的、明确获批的调用恢复。
• 证据必须写明：recipe <name> executed natively on Claude runtime via runner (commanded by Codex)；适配器或子级失败绝不算配方 PASS。

运行时矩阵（Claude Code 对全部 13 个配方均为 NATIVE；Codex 列如下）：

配方	Codex
3 个审计、findings-triage、project-direction-review、workflow-manifest（共 6 个，内部不使用 tmux）	ADAPTED: claude-workflow-runner
haiku-research-round（不使用 tmux）	UNTESTED——目前只在 Claude 上原生运行过；停止并报告
pr-review-triage-resolve（不使用 tmux；除非设置了 externalAgentType，否则 T3 级使用全新的 Claude opus）	UNTESTED——目前只在 Claude 上原生运行过；停止并报告
consensus-gate（仅简单裁定结果）	ADAPTED: direct-claude-review——见 references/codex-adapter.md
consensus-gate（作为配方）、生命周期及其 3 个阶段（设置了 cli 时）（共 5 个；这些阶段会驱动内部的 tmux-agent mod worker）	在嵌套 runner（深度 2）测试通过前，UNAVAILABLE-NATIVE——停止并报告；不得擅自变通

DEFER

• 仅在顶层串联配方——workflow() 嵌套上限为 1，生命周期 shell 会占用此额度。
• 仅当工作跨越多天、有 2 个或更多阶段，或必须支持中断后交接时，才使用运行目录（.workflow/<slug>/、codex-dynamic-workflows 约定）。聊天内工作：只需一个结果文件，或无需文件。
• 修改配方：行为层级 → 先运行一轮 consensus-gate；措辞修改 → 直接修改。权威版本 = agent-scripts 仓库包（skills/using-workflows/workflows/）→ 重新部署到 ~/.claude/workflows/；在机器端进行的实时修改，必须在同一次更改中同步回该仓库包。

未找到

没有合适的配方 → 这项工作可能不是循环式工作；跳过。确实出现了新的循环模式 → 向用户提议新配方；切勿临时编造半成品配方。各配方的参考资料：workflows/README.md（规范版本：agent-scripts bundle skills/using-workflows/workflows/README.md；部署副本位于 ~/.claude/workflows/README.md）。