分析、审查与规划
这组工作流都默认 不修改 source。它们的价值不是少做一步，而是在授权写入前先把事实、风险、证据或计划收敛清楚。
先按你要的结果选择
analyze：从事实得到结论
当分析结论变成“请按建议修改”时，原 analyze 已完成；新请求必须转到 dev 或 fix，不能沿用只读上下文中的隐含授权。
audit：按对象选择审查路径
audit 不是一种固定清单。当前有 7 类主 target：
README、用户手册或安全审查可能叠加专门 Skill，但它们仍属于 audit 的对象/能力组合，不会新增 canonical workflow。
other：只读规划兜底
只有在请求无法安全归入 dev、fix、analyze、audit、chat 或 resume 时才使用 other。它可以给出计划，但 plan 只是能力，不是第九个 workflow。
一旦计划需要落地到文件，必须根据最终目标重路由：新增或演进走 dev，缺陷修复走 fix，DevCodex 自治理缺陷才走 self-fix。
怎样算完成
analyze：问题得到回答，来源与推断可区分，未读范围不会被伪装成全量结论。audit：覆盖声明真实，finding 有定位和等级，未关闭项没有被隐藏。other：计划可执行，依赖、停止条件和需要重新授权的动作明确。
真实任务怎么选
“分析为什么构建越来越慢，只给结论”走 analyze.default；如果需要查 Node 或 Rspress 官方资料，走 analyze.research。
“审查整个用户站，列出问题但不要改”走 audit.通用文档，并叠加用户手册审查能力。之后若要求修复，开启新的 dev.docs 变更链。
“先给迁移计划，暂时不要改文件”在无法归类时可走 other；计划确认要实施后再路由到 dev。