Ora 工作流用于规划与执行多步智能体（agent）任务。资料将其划分为四个阶段：规划（plan mode 内）、执行（plan mode 之后）、验证和收尾（Finalize）。
一、规划（在计划模式中）
- 全局扫描（Landscape scan）：始终使用 ora:Ariadne，如果任务涉及外部资料则加用 ora:Clio，目的是理解现状（what exists），而不是如何修改。
- 分类模糊程度：如果请求模糊、涉及多个系统、验收标准不清晰，则先执行 /brainstorm；如果清晰且范围明确，则跳到第 3 步。
- 深入且有针对性探索：在澄清后的范围内使用 Ariadne/Clio。
- 基于分析结果撰写计划。
二、执行（计划模式之后） 在工作树（worktrees）中派生 ora:Hephaestus，独立任务可并行。此阶段很少需要研究，只有当执行暴露出计划无法预料的情况时才进行。 计划模式退出后，不要在 main 上 Edit/Write。所有实现都通过 Hephaestus 运行：任何触及 2 个以上文件或超过 10 行的改动都要派发新一轮。例外情况：拼写错误/注释修正、删除未使用的 import，或由 Aletheia/Hephaestus 输出明确指出的一行语法错误。任何需要先阅读上下文才能进行的代码改动都交给 Hephaestus。
三、验证（不可跳过） 每个 Hephaestus 任务都由 Aletheia 验证。未先经 ora:Aletheia 验证，不得 squash-merge 工作树。 若结果为 GAPS_FOUND，通过 SendMessage 恢复 Hephaestus（不要重新派生）。 重试 2 次后仍失败，则询问用户。 对每个已验证的工作树执行 squash-merge。 在 Aletheia 返回 GREEN 后，不要在 main 中重新 Read 工作树文件。Aletheia 已完成验证。如需检查特定内容，派发 ora:Ariadne 并提出针对性问题，不要用 Read 来验证。不要同时通过工作树路径和合并后的 main 路径读取同一文件——squash-merge 后内容相同。
四、收尾（Finalize） 对 squash-merge 后的波次提交（从 merge base 到 HEAD）运行 /council-review 或 /simplify。 对任何触及 2 个以上文件或超过 10 行的审查问题派发新的 Hephaestus 修复波次。严重程度不重要，阈值取决于范围。默认 1 个修复波次；仅当问题聚集为 3 个以上互不重叠文件的独立模块时，才拆分为并行波次。 执行 git reset --soft <merge-base> 加 git restore --staged，取消提交并取消暂存所有波次提交，使改动显示为工作目录修改。 停止，交由人工审查所有改动并提交。
五、规则 所有智能体都通过 SendMessage 恢复，同一会话可以继续时不要重新派生。 Ariadne 用于本地代码库，Clio 用于外部来源，不要混用。 Hephaestus 仅用于实现，不要用于探索或研究。 Aletheia 仅用于目标回溯验证，不要用于代码质量审查。
适用场景：需要以智能体方式规划并执行多步实现任务，且要求先探索现状、再实现、再验证、最后交由人工提交的流程。
限制与说明：资料未提供该工作流的安装方式、收费情况、支持平台或运行环境要求，均暂未提供。