workflowlisted

## 目标 把复杂任务拆成可验证、可并行、可汇总的工作流，减少主上下文压力，同时避免并行写入、证据不足和结论互相冲突 负责并行 agent / 多工作流编排，不负责长期 progress 文件。需要计划文件、阶段验收和跨多轮进度记录时，组合 `invoke-plan` ## 使用条件 - 跨大量文件、模块、仓库或文档的搜索、审计、迁移评估 - 需要从正确性、安全性、性能、可维护性、可复现性等角度独立审查 - 需要查询官方文档、GitHub、Issue、PR、源码或 release note 验证结论 - 主上下文会被大量原始文件、日志、搜索结果撑爆 - 子任务之间没有顺序依赖，且写入集不冲突 ## 禁止并行 - 后一步依赖前一步输出 - 多个任务会修改同一文件、git index、数据库、外部服务或同一个日志/报告 - 必须先全局去重、排序、汇总后才能继续 - 任务规模很小，主 agent 可以直接完成 ## 默认流程 1. 主 agent 先侦察，列出文件、模块、查询目标或验证假设 2. 把任务拆成互不重叠的只读子任务 3. 每个子任务的 prompt 必须自包含，写清目标、范围、排除项和输出格式 4. 子任务只返回结构化结论、证据路径、关键摘录和不确定点，不粘贴大段原文 5. 主 agent 汇总、去重、解决冲突，并标出已验证和未验证结论 6. 如需改代码或文档，由主 agent 串行落写 ## 多角度审查 - 对复杂结论至少拆出 2 个独立视角，例如正确性、类型安全、性能、兼容性、安全、用户体验、测试覆盖 - 对高风险结论安排独立验证任务，验证者优先证伪原结论，并给出证据 - 不让多个验证者复读同一个 prompt；每个验证任务必须有不同关注点 - 汇总时保留冲突意见，不用多数票直接覆盖证据更强的一方 ## 文档和源码验证 - 涉及不确定 API、库行为、平台限制、CLI 参数、GitHub 项目状态时，必须查询权威来源 - 优先级：本地源码/README > 官方文档 > GitHub 源码 > Issue/PR/release note > 其他资料 - 搜索结果必须回到具体文件、文档段落、Issue、PR 或 release 作为证据 - 只查了 top-N、抽样或部分路径时，必须说明覆盖范围，不能伪装成全量验证 ## 写入规则 - 默认只读并行、串行写入 - 允许并行写入仅限隔离 worktree、隔离目录或明确不重叠文件 - 禁止并行任务执行 `git add`、`commit`、`push`、`reset`、`restore`、`checkout`、`stash`、`clean`、`merge`、`rebase` - 外部 API、数据库、审批、消息��送等副作用按共享资源处理，默认串行或先 dry run ## 输出要求 - 结论按 `已验证`、`部分验证`、`未验证` 分组 - 每条重要结论带证据路径或链接 - 标出搜索覆盖范围、跳过范围、失败任务和残余风险 - 给出下一步串行执行建议，不把多个子任务结果简单拼接