slim-task

name	slim-task
description	Use when the user invokes /slim-task or requests structured multi-phase task execution (structured task, SOP execution, parallel sub-agent dispatch) with blind-audit quality review.
argument-hint	[task description] [--lang zh-CN|en-US|...] [--worktree] [--base <branch>] [--interactive]
user-invocable	true

多阶段 SOP 编排器。主 Agent 只做检查/决策/派发/验证（主检子执），实现 Agent 做实际编码，审计 Agent 做独立盲审。任务按 DAG 拓扑序最大化并行。

全局护栏

1. 主 Agent 禁止直接写代码 — 只做需求澄清、方案设计、任务拆分、派发、汇总、提交确认
2. Phase 2 审批前禁止任何代码变更
3. 影响范围即合约 — 禁止修改影响范围表之外的任何文件
4. 审批点前置收敛 — 人工决策集中在三处关键边界：Phase 1（需求审批）、Phase 2（方案+DAG 审批）、Phase 6（commit + push 双授权）。这三处必须调用 AskUserQuestion。Phase 2 审批通过后，Phase 3-5 为执行段，默认自动推进（见「自动推进与异常暂停协议」），仅异常时暂停。--interactive 模式下恢复每阶段检查点
5. 禁止未经确认的 commit/push — Phase 6 commit 与 push 分别独立授权（两次决策卡）
6. UI 改动必检 — 涉及 UI 时必须调用 frontend-design 或 ui-ux-pro-max Skill
7. 完全独立 — 本插件不依赖任何其他插件的基础设施
8. 语言一致性 — 面向用户的内容全部使用 ${LANG}（默认 zh-CN）；Conventional Commits 前缀保持英文；代码标识符/API 名/框架关键字保持原文
9. Worktree 模式硬约束 — 禁止 commit 仓库共享配置文件；禁止 auto-merge 回 main 或 push 到 origin/main
10. 审计隔离 — 实现 Agent ≠ 审计 Agent；审计 Agent prompt 严禁注入实现 Agent 的对话历史、思考记录、自评结论
11. 分支命名规范 — 工作分支必须符合 <type>/<slug> 格式，type 限定为：feat / fix / refactor / docs / chore / test / perf；slug 仅含小写字母、数字、连字符；Phase 6 commit 前强制校验，不合规则阻断并提示重命名
12. Workflow 编排授权 — 本 SKILL 在 Phase 4-5 指示主 Agent 调用 Workflow 工具做确定性编排；用户执行 /slim-task 即构成对该工具的 opt-in 授权，无需额外询问

术语约定

术语	含义
实现 Agent	Phase 4 中执行编码的子 Agent
审计 Agent	Phase 5 中做质量检查的独立子 Agent（scope/practice/engineering）
修复 Agent	Phase 5 中修复 issue 的独立子 Agent

阶段总览

Phase	目标	关键产出	阶段转换
0	会话初始化	语言/Worktree 配置 + .gitignore 自检	自动 → Phase 1（仅条件性授权 .gitignore/worktree）
1	需求澄清	精炼需求摘要	审批 gate → Phase 2
2	方案设计 + DAG 预览	方案 + 影响范围表 + DAG 拆分	审批 gate → Phase 3
3	文档固化	任务文档	自动 → Phase 4（文档自审通过即推进）
4	DAG 并行执行	实现 Agent 交付物	自动 → Phase 5
5	独立审计盲审	三维 audit.json	自动 → Phase 6（全 pass）/ 自动修复（≤3轮）/ 3轮未过停下交人工
6	提交确认	commit + 可选 push/PR	两次独立决策卡

执行段定义：Phase 3-5 为「执行段」，默认全自动推进，仅「自动推进与异常暂停协议」定义的异常触发暂停。--interactive 模式下每个 Phase 末尾恢复标准检查点。

流程决策图

flowchart TD
    P0[Phase 0 会话初始化] --> WT{--worktree?}
    WT -->|是| EW[EnterWorktree 隔离] --> P1
    WT -->|否| P1[Phase 1 需求澄清]
    P1 --> G1[/审批 gate 1: 需求/]
    G1 --> P2[Phase 2 方案设计 + 影响范围表 + DAG 预览]
    P2 --> G2[/审批 gate 2: 方案+DAG/]
    G2 --> EXEC[执行段自动接管]
    EXEC --> P3[Phase 3 文档固化] --> P4DECIDE{DAG 节点数}
    P4DECIDE -->|单节点| INL[单 Agent 直派] --> P5
    P4DECIDE -->|2-3 节点| FANOUT[Phase 4 指令式 fan-out] --> P5
    P4DECIDE -->|≥4 节点| WF[Phase 4-5 Workflow 确定性编排]
    P5[Phase 5 三维盲审] --> UI{涉及 UI?}
    UI -->|是| VIS[追加视觉审查 Skill] --> AUD
    UI -->|否| AUD{三维 audit.json 全 pass?}
    AUD -->|有 issue, <3 轮| FIX[修复 Agent 独立 context] --> P5
    AUD -->|3 轮未通过| STOP((停下交人工))
    AUD -->|全 pass| P6[Phase 6 决策卡 1: commit]
    WF -->|全 pass| P6
    WF -->|3 轮未通过| STOP
    P6 --> COMMIT[执行 commit] --> P6P[决策卡 2: push/PR]
    P6P --> WTM{Worktree 模式?}
    WTM -->|是| NOPUSH[禁止 push main / 询问保留 worktree] --> END
    WTM -->|否| PUSH[按用户选择执行 push/PR] --> END((结束))

阅读约定：菱形=分支决策，圆角矩形=终止，平行四边形=人工审批 gate。执行段（Phase 3-5）分支判断失败即触发异常暂停，禁止跨级跳转。

检查点标准协议

检查点分两类，语义截然不同：

类型	出现位置	行为
审批 gate	Phase 1 / Phase 2 / Phase 6	必须调用 AskUserQuestion，等待用户显式授权
自动 transition	Phase 0 / Phase 3 / Phase 4 / Phase 5	默认不询问用户，满足推进条件即进入下一阶段；仅异常时暂停

--interactive 模式：所有「自动 transition」点降级为审批 gate，恢复每阶段 AskUserQuestion 检查点。该模式供用户需要逐阶段把控时显式开启。各阶段检查点形态详见 references/params-and-interactive.md。

审批 gate 强制规则（Phase 1 / 2 / 6）

• 必须调用 AskUserQuestion 工具发起决策卡，禁止用纯文本提问（如"要不要继续"、"看起来如何"、"是否 OK"）替代
• 自由文本回复（如用户答"不错"、"可以"）不自动视为采纳，必须再次发起决策卡或显式询问
• 决策卡至少包含 3 个选项：①采纳进入下阶段（明确进入 Phase N+1）；②修改后重审（回到当前 Phase 调整）；③终止流程（结束整个 slim-task 会话）
• 选项标签按 ${LANG} 配置语言输出

Phase 6 特殊规则：必须执行两次独立的 AskUserQuestion 决策卡 —— ①Commit 决策卡（确认 commit message 与变更范围）；②Push/PR 决策卡（commit 完成后立即发起，确认是否 push 及是否创建 PR）。两次决策卡严禁合并为单次询问。

历史指令不构成授权：用户在更早消息中的笼统指令（如"提交推送拉 PR"、"全部弄完"）不能跳过任何审批 gate 的 AskUserQuestion 调用。每个审批 gate 必须在执行时刻重新获取授权。

---

自动推进与异常暂停协议

Phase 2 审批通过后，执行段（Phase 3-5）默认全自动接管，无需用户逐阶段确认。这是「审批即自动接管」的核心。

正常路径（全程不询问用户）

以下条件全部满足时，Phase 3 → 4 → 5 → Phase 6 入口连续自动推进：所有操作均为可逆操作（写文件、创建分支，未触及 commit/push）；实际改动文件均在 Phase 2 审批的影响范围表内；无外部系统副作用（无网络写操作、无 commit/push、无生产环境变更）；各阶段产出物完整（文档自审通过、审计 json 齐全）。

异常暂停触发条件（任一满足立即暂停，向用户报告）

执行段出现以下任一信号即暂停，把控制权交回主线程发起 AskUserQuestion。每条暂停都必须展示足够用户决策的信息 + 明确的可选动作，禁止只说"出错了"。完整的展示内容、用户可选动作、自动回滚机制见 references/exception-pause.md，主 Agent 触发暂停时据此构造决策卡。

#	触发条件
1	影响范围表外的文件被修改
2	Phase 5 修复循环触达 3 轮仍有未关闭 issue
3	子 Agent 返回失败/空结果，或 Workflow 派发的 agent 返回 null
4	子 Agent 升级回传（遇多条合法路径无法自治）
5	文档自审失败且自动修正后仍不通过
6	三维 audit.json 任一缺失或为空对象（违反盲审完整性，见 Red Flags）
7	用户主动中断（见下方主动暂停入口）

暂停≠终止：暂停后用户可选择修复方向继续，或终止。异常暂停不绕过任何质量约束。异常 #1/#3/#5 支持自动回滚到 Phase 2 审批态（详见 reference）。

执行段进度透明

执行段虽自动推进，但禁止静默——每个关键节点必须向用户输出一行进度（Workflow 模式用 log()，指令式模式用普通文本）：Phase 3 文档自审通过→报「✓ 文档固化完成，进入执行」；Phase 4 每层启动/完成→报「Layer N：派发 X 个任务 / 完成 Y/X」；Phase 5 每轮审计→报「审计第 R/3 轮：scope/practice/engineering」+ 结果摘要；进入 Phase 6 前→报「✓ 三维审计通过，准备提交确认」。

用户主动暂停入口

执行段进行中，用户随时可中断（Esc / TaskStop 后台任务 / 直接发话叫停）。主 Agent 感知中断后不得无视继续，立即进入异常 #7：保存当前 checkpoint，展示进度，发起恢复决策卡。禁止"等这一步跑完再说"式拖延。

Checkpoint 落盘与恢复

执行段是长流程，须防 context 压缩/会话断开/崩溃导致全部重跑。

• 落盘时机：每个 Phase 转换、每层 DAG 完成、每轮修复结束、每次异常暂停前
• 落盘内容：见 references/checkpoint-schema.md（phase / dag-progress / fix-round / files-modified / pending-decision）
• 落盘路径：.claude/slim-task/checkpoints/{task-slug}-{phase}.json（覆盖写最新态）
• 恢复逻辑：会话重入时先扫该目录，存在 checkpoint 则向用户展示「检测到中断于 Phase N，从断点恢复 / 重新开始」决策卡；恢复时跳过已完成层，重入未完成的修复循环（复用已落盘 round 计数，不清零）
• 清理：Phase 6 commit 成功后删除本 task 的 checkpoint 目录

---

Phase 0: 会话初始化

1. 参数解析：从 args 提取 --lang / --worktree / --base / --interactive；各参数合法值域与非法处理见 references/params-and-interactive.md
2. 语言决策（优先级）：命令行 --lang > 仓库 .claude/slim-task.json 的 language 字段 > 默认 zh-CN；首次确定后写入 .claude/slim-task.json（不存在则创建）持久化为后续默认值
3. .gitignore 自检（首次运行必检）：检查仓库 .gitignore 是否含 .claude/slim-task.json 与 .claude/slim-task/（运行时配置 + Phase 5 审计落盘）；任一缺失则经 AskUserQuestion 决策卡确认后追加（禁止静默写入），用户拒绝则继续但提示后续 commit 须人工排除这些路径；仓库无 .gitignore 时提示用户在根创建并加入上述两条
4. Worktree 决策：--worktree 未出现则跳过保持当前工作树；出现则：a. AskUserQuestion 确认基线分支（默认 head 当前分支；可选 origin/main 或自定义）→ b. 调用 EnterWorktree(name=slim-<task-slug>-<timestamp>) → c. 检查 .gitignore 是否含 .claude/worktrees/，缺失则比照 step 3 流程补齐
5. 记录 ${BASE_REF}：当前工作分支名（非 worktree 模式）或 --base 指定分支（worktree 模式），写入 .claude/slim-task.json 的 baseRef 字段，供 Phase 6 push 决策卡使用
6. 分支命名前置校验：检查当前工作分支名是否匹配 ^(feat|fix|refactor|docs|chore|test|perf)/[a-z0-9-]+$；不合规则此刻（代码未写、改名零成本）通过 AskUserQuestion 提示 git branch -m <new-name>，阻断后续直到合规。前置于此避免 Phase 6 代码写完才改名引发 rebase 冲突
7. 输出初始化摘要：LANG=... | WORKTREE=<path 或 none> | BASE_REF=<branch> | GITIGNORE=<ok 或 patched/skipped>

阶段转换：自动 transition → Phase 1。Phase 0 无独立审批 gate（.gitignore 追加与 worktree 基线分支已在 step 3/4 内通过 AskUserQuestion 做条件性授权）。--interactive 模式下追加标准检查点「采纳 → Phase 1 / 修改配置 / 终止」。

---

Phase 1: 需求澄清

原则：一次一问、多选优先、迭代推进、明确退出。

Step 1 — 维度扫描：解析用户输入的任务描述，识别以下维度的缺失/歧义：

优先级	维度	典型问题
P0	目标/意图	要实现什么、为什么做
P1	范围/边界	包含什么、排除什么
P2	验收标准	怎样算完成、成功指标
P3	技术约束	性能要求、兼容性、依赖限制
P4	隐含假设	需要用户确认的推断

Step 2 — 迭代澄清循环（问到清楚为止）：

1. 若维度扫描结果为 0 个歧义点 → 跳过循环，直接到 Step 3
2. 按优先级选取最高未解决维度，构造单一问题：优先提供 2-4 个具体多选选项 + 1 个"其他（请补充）"；每轮最后一个选项固定为「已足够清晰，无需继续」；经 AskUserQuestion 发送（选项按 ${LANG}）
3. 吸收回答 → 更新维度状态；若回答引入新歧义，追加到待解决列表
4. 退出判定（满足任一即退出循环）：所有 P0-P2 维度已有明确答案 / 用户选「已足够清晰，无需继续」/ 澄清已达 5 轮（防无限打转，强制转 Phase 2 并提示「已澄清 5 轮，进入方案设计；如仍有歧义可在 Phase 2 审批时要求回 Phase 1」）
5. 未退出 → 回到步骤 2

Step 3 — 输出：精炼需求摘要（bulleted list，按 ${LANG}），包含关键假设列表。

审批 gate：执行审批 gate 强制规则，选项为「采纳 → Phase 2 / 补充澄清（重入循环）/ 终止」。用户选「补充澄清」时重入 Step 2 循环继续迭代。这是三处关键人工边界之一，无论 --interactive 与否都必须执行。

---

Phase 2: 方案设计 + DAG 预览

2a 最佳实践调研

• 优先使用 AI 内置知识推荐最佳实践、设计模式、已知陷阱
• 仅当内置知识可能过时时（新版本 API、新发布的库、近期安全公告）使用 WebSearch 补充

2b 代码库扫描

• 派发 Explore 子 Agent（subagent_type: Explore）扫描代码库，查找相关代码、可复用工具函数、现有设计模式、潜在冲突点；可同时派发多个 Explore Agent 扫描不同维度

2c 方案输出

向用户展示（按 ${LANG}）：

1. 方案描述（1-3 段，含推荐理由和替代方案对比）
2. 影响范围表（必须）：

操作	文件路径	理由
修改	src/xxx.ts	具体原因
新增	src/yyy.ts	具体原因
不可触碰	src/zzz.ts	超出范围

1. 破坏性变更评估（必须）：逐项判定是否破坏并附说明 —— 公开 API/接口签名、数据库 schema/数据格式、配置文件/环境变量、依赖版本、用户可见行为
2. 业务影响分析：对现有功能的影响等级（无 / 低 / 中 / 高）+ 受影响的上下游模块/调用方
3. 回滚方案：上线后如何安全回退（git revert 是否充分 / 是否需数据迁移回退脚本）
4. 风险与权衡

2d DAG 拆分预览

在审批前先做 DAG 拆分，使「批准方案」与「批准任务拆分」合并为一次决策：

1. 将方案分解为原子子任务
2. 分析依赖关系，构建 DAG（有向无环图）
3. 识别 DAG 层级：Layer 0（无前置依赖，可立即并行）、Layer 1（依赖 Layer 0）、Layer N（依此类推）
4. 每个子任务必须包含：Objective（要完成什么）、File boundary（允许修改的文件列表，必须是影响范围表子集）、Dependencies（前置子任务 ID）、Output format（完成标准）
5. 向用户展示 DAG 层级结构 + 节点清单（按 ${LANG}），标注预计执行模式：节点数=1→单 Agent 直派；2-3→指令式 fan-out；≥4→Workflow 确定性编排

审批 gate：执行审批 gate 强制规则，选项为「批准方案+DAG → 执行段 / 修改方案或拆分 / 终止」。这是三处关键人工边界之一，无论 --interactive 与否都必须执行。此 gate 通过后，Phase 3-5 执行段自动接管，不再逐阶段询问用户。

---

Phase 3: 文档固化

DAG 拆分已在 Phase 2d 完成并随方案一并审批。Phase 3 仅做文档固化，是执行段的第一步。

3a 文档固化

在项目中写入 docs/tasks/{YYYY-MM-DD}/{task-slug}.{lang}.md，内容包含：Phase 1 的需求摘要；Phase 2 的方案设计 + 影响范围表 + DAG 拆分；执行时间戳 + Worktree 路径（若启用）。

文档自审（写入后立即执行，通过则继续，未通过则修正后再继续）：

#	检查项	判定标准
1	无 placeholder	不存在 TODO、TBD、???、<待补充> 等占位符
2	无内部矛盾	需求摘要与方案设计不冲突；影响范围表与方案描述一致
3	无歧义表述	每条需求可被不同读者产生相同理解
4	无遗漏	Phase 1 所有已确认维度在文档中均有对应描述

阶段转换：自动 transition → Phase 4。文档自审通过即推进，不询问用户。自审修正后仍不通过时，按「自动推进与异常暂停协议」异常 #5 暂停。--interactive 模式下追加标准检查点「采纳 → Phase 4 / 修改文档 / 终止」。

---

Phase 4: DAG 最大化并行执行

执行模式分流（按 DAG 节点数）

Phase 2d 已确定执行模式。三档分流：

节点数	模式	机制
1	单 Agent 直派	主 Agent 派发单个实现 Agent（非主 Agent 自己写代码，仍遵守护栏 1）；复用下方「指令式 fan-out 协议」，退化为单层单 Agent
2-3	指令式 fan-out	主 Agent 用 Agent 工具逐层并行派发（见下方「指令式 fan-out 协议」）
≥4	Workflow 确定性编排	主 Agent 调用 Workflow 工具，Phase 4-5 合并为一段确定性脚本（见下方「Workflow 编排协议」）

选择阈值的根因：Workflow 拉起开销与 token 成本较高，小任务用指令式 fan-out 更省更透明；≥4 节点时确定性编排（自动 barrier、修复轮次硬计数、三维审计强制并行）的收益压过成本。

指令式 fan-out 协议（1-3 节点）

1. Layer 0 启动：所有无依赖任务同时派发（Agent 工具，run_in_background: true）；1 节点时该层仅一个 Agent。每个实现 Agent 的 prompt 按 references/impl-agent-prompt.md 的结构化模板（Objective / File Boundary / Task Boundary / Language / Output JSON）填充
2. Barrier 硬约束：本层每个 Agent 必须用 TaskOutput(task_id, block=true) 逐一等待，全部返回后才派发 Layer N+1；禁止收到任一通知就推进。设最大等待（建议 3600s），超时按异常 #3 处理
3. 文件边界校验：每个 Agent 汇报 modified_files 后，主 Agent 核对其 ⊆ 影响范围表；越界即按异常 #1 处理（不等到 Phase 5 才发现）
4. 失败处理：任一 Agent 报告失败/超时 → 停止后续层派发，按异常 #3 处理
5. 升级回传：子 Agent 遇多条合法路径无法自治 → 按异常 #4，由主 Agent 据回传选项发起 AskUserQuestion
6. 主 Agent 职责：监控完成通知，逐层落盘 checkpoint，汇总执行结果

阶段转换（指令式/单 Agent 模式）：自动 transition → Phase 5。本层全部成功即推进，不询问用户；失败按异常暂停 #3。--interactive 模式下追加标准检查点「进入 Phase 5 审计 / 回退修复 / 终止」。

Workflow 编排协议（≥4 节点）

主 Agent 调用 Workflow 工具，将 Phase 4（DAG 并行执行）与 Phase 5（三维盲审 + 修复循环）合并为一段确定性脚本。控制流（逐层 barrier、修复轮次计数、三维审计并行）由 JS 引擎保证，单个 agent() 内部仍是模型驱动。

完整的**输入契约 + 脚本骨架 + 输出契约（status → 主 Agent 动作映射）**见 references/workflow-orchestration.md，主 Agent 进入 ≥4 节点分支时读取并据此生成脚本。要点：脚本的 parallel([scope, practice, engineering]) 三路缺一即违反护栏 10，while (round < 3) 上限禁止改大；每个 agent() 都是隔离 context，天然满足盲审隔离。Workflow 返回后，主 Agent 按输出契约表把 status 映射到对应异常暂停（见「自动推进与异常暂停协议」）或进入 Phase 6。

阶段转换：Workflow 模式下 Phase 4-5 已合并，主 Agent 直接处理 Workflow 返回值，按输出契约表分流（pass → Phase 6；其余 → 对应异常暂停）。--interactive 模式下，Workflow 返回 pass 后追加标准检查点「进入 Phase 6 / 派修复 Agent / 终止」。

---

Phase 5: 质量检查（独立审计 Agent 盲审）

核心反作弊原则

写实现的 Agent ≠ 审实现的 Agent。主 Agent 只做派发与汇总，不做实质审查。

Rationalizations 反例表

主 Agent 与审计 Agent 在执行 Phase 5 时常见的"偷懒理由"清单。任何与下表语义相近的内部独白都视为绕过，必须立即停下并改走右列动作。表外但同类的理由同样视为绕过。

偷懒理由（Rationalization）	真实含义	强制动作
"用户上次已授权 commit，本次延用"	把历史授权当本次授权	必须重新调 AskUserQuestion，历史消息不构成本次授权
"改动很小 / diff 不到 50 行，跳过 Phase 5"	用规模豁免流程	任何代码改动都进 Phase 5，size 不是豁免条件
"我大致看了 diff，应该没问题"	用主观判断替代独立审计	必须由独立子 Agent 重读 + 输出 audit.json
"lint/test 在 Phase 4 已经跑过了"	把过往验证当本次验证	engineering-auditor 必须重新执行 lint/build/typecheck，禁止缓存或复用历史输出
"审计 Agent 报了 issue 但看起来无关紧要"	主观降级 issue 严重度	issue 一律进入修复循环，严重度仅决定优先级，不决定是否处理
"修复 3 轮还有 issue，剩下的留给用户"	用上限规避根因分析	触达 3 轮上限必须 停下 让用户人工介入，禁止 silent skip
"审计 Agent 可以共用 Phase 4 的 context 节省 token"	破坏盲审隔离	审计 Agent 必须 general-purpose 独立派发，不复用任何 Agent ID 或 prompt
"范围表里没列这个文件但顺手改了"	用便利性绕过影响范围合约	视为越界，scope-audit 必须报 issue；如确需扩展须回到 Phase 2 重审范围表
"我自己读一遍代码当 review，不派审计 Agent 了"	主 Agent 自审	主 Agent 严禁实质审查；必须独立派发三维 auditor
"用户没问 audit 报告，跳过展示直接进 Phase 6"	用沉默替代质量关	必须按 ${LANG} 展示统一审计报告；全 pass 才自动进 Phase 6
"Worktree 模式所以审计可以更宽松"	用隔离强度换取流程豁免	Worktree 不改变 Phase 5 任何强度要求
"审计 Agent 自己也说 issues=[]，那应该没问题"	用单一审计源代替三维交叉	三维 audit.json 必须独立产出，缺一不可
"执行段自动推进了，质量门也可以一起跳过"	把「免确认」误读为「免质量」	自动 transition 仅免去用户确认动作，三维盲审/影响范围/修复循环等质量约束全部不变
"Workflow 脚本里少派一个 auditor 也能跑"	篡改确定性脚本绕过三维	Workflow 脚本的 parallel([scope,practice,engineering]) 三路缺一即违反护栏 10，禁止删减

Red Flags - STOP 清单

以下任一信号一旦出现，立即停止当前动作，回到全局护栏重新校验：

1. 主 Agent 正在直接 Edit / Write 业务代码文件（违反全局护栏第 1 条）
2. Phase 5 三维 audit.json 中有任一文件不存在或为空对象
3. audit.json issues=[] 但 git diff 行数 > 200 且未附执行日志
4. 任一审计 Agent 的 prompt 中出现 Phase 4 实现 Agent 的 ID、对话片段、自评摘要
5. 修复循环计数 ≥ 3 且仍存在未关闭 issue
6. 范围表外的文件出现在 git diff 中且 scope-audit 未报 issue
7. Phase 6 即将 commit 但未先展示 Phase 5 统一审计报告、或审计未全 pass 即推进
8. 出现"基于历史指令"、"上次已确认"、"用户应该是想要"等推断式授权语言
9. Workflow 脚本被改成少于三路 auditor、或 while 上限被改大于 3

隔离硬约束

• 审计/修复 Agent 一律 general-purpose 独立派发，不复用 Phase 4 任何 Agent ID，prompt 严禁注入实现 Agent 的对话历史/思考/自评（同护栏 10）
• 禁止向审计 Agent 暴露的信息类型（逐项排除，构造 prompt 时核对）：① Phase 4 实现 Agent 的对话/思考/自评；② 本地 debug/temp 文件与编译产物；③ commit message / 文件 rename 历史；④ 未消毒的 diff 上下文
• Diff 消毒：注入审计的 diff 必须用 git diff --unified=0 --no-ext-diff --ignore-all-space -- <影响范围内文件>，仅含改动行号+内容，剥离上下文与无关痕迹（消毒命令详见 references/audit-diff-sanitize.md）
• prompt 构造规范：三个 auditor 的 prompt 用同一模板填充，参数白名单 {任务描述, 影响范围表, 清洁diff, 项目规范引用}，黑名单永久排除 {实现Agent ID, 实现prompt, 实现对话}；禁止手工字符串拼接夹带黑名单项
• 审计产物落盘：.claude/slim-task/audits/{task-slug}/

三维审计派发

三个 auditor 独立并行派发（缺一不可），各自输出 JSON 落盘到审计目录：

维度	Agent	prompt 注入	职责	输出
5a 范围	scope-auditor	任务描述 + 影响范围表（Phase 2 审批版）+ 清洁 diff（消毒后）	改动文件是否越界 + 表中预期改动是否发生	scope-audit.json（越界/遗漏文件列表）
5b 实践	practice-auditor	任务描述 + Phase 2 方案 + 清洁 diff + 规范引用（CLAUDE.md / .claude/rules/）	对照方案与规范评分，标记偏离违规	practice-audit.json
5c 工程	engineering-auditor	项目根 + 影响范围内文件 + lint/build/typecheck 命令（从 CLAUDE.md / Makefile 发现）	执行 lint/build/typecheck 捕获失败	engineering-audit.json（失败命令+日志）

5d UI 检查（涉及 UI 改动时）：提示用户调用 frontend-design 或 ui-ux-pro-max Skill 做视觉一致性审查。

汇总与修复流程

Workflow 模式（≥4 节点）下，三维派发 + 修复循环已由 Workflow 脚本确定性执行（parallel() 强制三路并行、while(round<3) 硬计数）；主 Agent 仅消费 Workflow 返回值，跳过本小节手动循环，直接执行下方阶段转换。

指令式 fan-out 模式（2-3 节点）与内联模式（1 节点）下，主 Agent 手动执行以下循环：

1. 主 Agent 读取 3 份 audit.json
2. 向用户展示统一审计报告（按 ${LANG}）
3. 若存在 issue：派发修复 Agent（独立 context，不复用 Phase 4 Agent ID）修复
   • 继承关系：fixer-round-N 在前轮改动基础上修复（工作区已含前轮改动），但 prompt 仅注入当前 issue 列表 JSON，不注入前轮审计报告（防泄漏审计思路）
   • 计数规范：修复 Agent 返回 null 也算一轮，round 计数不受网络延迟影响；派发前先落盘 checkpoint 记录 round 值
4. 修复后再次派发 5a/5b/5c 审计 Agent 复核（同样独立 context、同样消毒 diff）
5. 修复循环上限 3 次，超过则按异常暂停 #2 停下让用户人工介入

阶段转换：条件化自动 transition。

• 三维 audit 全 pass → 展示审计摘要，自动进入 Phase 6，不询问用户
• 存在 issue 且修复轮次 < 3 → 自动进入修复循环（指令式）或由 Workflow 内部处理（Workflow 模式），不询问用户
• 修复触达 3 轮仍有 issue → 异常暂停 #2，交人工介入
• --interactive 模式下追加标准检查点「批准 → Phase 6 / 派修复 Agent / 终止」

---

Phase 6: 提交确认

核心铁律

• 历史笼统指令不构成本阶段授权，必须重新发起 AskUserQuestion
• 严禁主 Agent 自行执行 git commit / git push / gh pr create 后追溯告知

执行步骤

1. 分支名复核：分支命名已在 Phase 0「分支命名前置校验」步完成。此处仅复核当前分支名仍匹配 ^(feat|fix|refactor|docs|chore|test|perf)/[a-z0-9-]+$；若执行中被改动致不合规，AskUserQuestion 提示重命名后再继续

2. BASE_REF 再验证：git branch -r 确认 ${BASE_REF} 分支仍存在（防 Phase 0 后被删/改名）；不存在则 AskUserQuestion 让用户重选（候选：本地分支 / origin/main / 当前 HEAD），并回写 .claude/slim-task.json

3. 副产物 staging（git add 精确添加，禁止 git add . / -A）：docs/tasks/{YYYY-MM-DD}/{task-slug}.*（Phase 3 固化文档）；.claude/slim-task/audits/{task-slug}/*.json（三维审计证据，质量证明，必须随代码同步 commit，禁止遗漏）；.gitignore（若 Phase 0 追加了忽略规则）

4. 产物黑名单检查：扫描 staged 区域，若命中运行时产物（.claude/slim-task/checkpoints/、.claude/worktrees/）或仓库共享配置（release-please-config.json / .release-please-manifest.json / .claude-plugin/marketplace.json，worktree 模式必查）→ 提示 git restore --staged <path> 移出；用户坚持则拒绝 commit

5. Staging 校验：git diff --cached --name-only 展示将提交的完整文件清单，连同 diff 摘要 + 提议的 Conventional Commits message 一并展示（按 ${LANG}）

6. 第一次 AskUserQuestion（Commit 决策卡）：「确认 commit」/「修改 message 后再 commit」/「取消回 Phase 5」。选「修改 message」仅改 message 不重审；但若用户同时改了代码，必须先清理旧审计报告并回 Phase 5 重新审计（防代码与审计证据不同步）

7. commit 后立即第二次 AskUserQuestion（Push/PR 决策卡）：「push 到 origin/ + 开 PR」/「push 到 origin/（不开 PR）」/「push 到 origin/${BASE_REF}（仅当 BASE_REF ≠ main/master）」/「保留本地不 push」；worktree 模式下「push 到 main/master」永远禁用，不出现在决策卡

8. 按决策执行，完成后汇报；清理本 task 的 checkpoint 目录

9. Worktree 收尾：AskUserQuestion 询问是否 ExitWorktree(action=keep) 保留。若保留，展示：worktree 绝对路径 + 分支名 + 合并指引 + 冲突回退方法：

   git fetch && git checkout main && git merge worktree-slim-<slug>
   # 冲突时：git merge --abort 回退，或手工解决后 git commit
   

10. 用户拒绝 commit：列出手动调整事项，保留 checkpoint，结束流程