Stats
Actions
Tags
From slim-task
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/slim-task:slim-task [task description] [--lang zh-CN|en-US|...] [--worktree] [--base <branch>] [--interactive][task description] [--lang zh-CN|en-US|...] [--worktree] [--base <branch>] [--interactive]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
多阶段 SOP 编排器。主 Agent 只做检查/决策/派发/验证（主检子执），实现 Agent 做实际编码，审计 Agent 做独立盲审。任务按 DAG 拓扑序最大化并行。
多阶段 SOP 编排器。主 Agent 只做检查/决策/派发/验证（主检子执），实现 Agent 做实际编码，审计 Agent 做独立盲审。任务按 DAG 拓扑序最大化并行。
AskUserQuestion。Phase 2 审批通过后，Phase 3-5 为执行段，默认自动推进（见「自动推进与异常暂停协议」），仅异常时暂停。--interactive 模式下恢复每阶段检查点frontend-design 或 ui-ux-pro-max Skill${LANG}（默认 zh-CN）；Conventional Commits 前缀保持英文；代码标识符/API 名/框架关键字保持原文<type>/<slug> 格式，type 限定为：feat / fix / refactor / docs / chore / test / perf；slug 仅含小写字母、数字、连字符；Phase 6 commit 前强制校验，不合规则阻断并提示重命名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。
AskUserQuestion 工具发起决策卡，禁止用纯文本提问（如"要不要继续"、"看起来如何"、"是否 OK"）替代${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，展示进度，发起恢复决策卡。禁止"等这一步跑完再说"式拖延。
执行段是长流程，须防 context 压缩/会话断开/崩溃导致全部重跑。
references/checkpoint-schema.md（phase / dag-progress / fix-round / files-modified / pending-decision）.claude/slim-task/checkpoints/{task-slug}-{phase}.json（覆盖写最新态）--lang / --worktree / --base / --interactive；各参数合法值域与非法处理见 references/params-and-interactive.md--lang > 仓库 .claude/slim-task.json 的 language 字段 > 默认 zh-CN；首次确定后写入 .claude/slim-task.json（不存在则创建）持久化为后续默认值.gitignore 自检（首次运行必检）：检查仓库 .gitignore 是否含 .claude/slim-task.json 与 .claude/slim-task/（运行时配置 + Phase 5 审计落盘）；任一缺失则经 AskUserQuestion 决策卡确认后追加（禁止静默写入），用户拒绝则继续但提示后续 commit 须人工排除这些路径；仓库无 .gitignore 时提示用户在根创建并加入上述两条--worktree 未出现则跳过保持当前工作树；出现则：a. AskUserQuestion 确认基线分支（默认 head 当前分支；可选 origin/main 或自定义）→ b. 调用 EnterWorktree(name=slim-<task-slug>-<timestamp>) → c. 检查 .gitignore 是否含 .claude/worktrees/，缺失则比照 step 3 流程补齐${BASE_REF}：当前工作分支名（非 worktree 模式）或 --base 指定分支（worktree 模式），写入 .claude/slim-task.json 的 baseRef 字段，供 Phase 6 push 决策卡使用^(feat|fix|refactor|docs|chore|test|perf)/[a-z0-9-]+$；不合规则此刻（代码未写、改名零成本）通过 AskUserQuestion 提示 git branch -m <new-name>，阻断后续直到合规。前置于此避免 Phase 6 代码写完才改名引发 rebase 冲突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 / 修改配置 / 终止」。
原则：一次一问、多选优先、迭代推进、明确退出。
Step 1 — 维度扫描：解析用户输入的任务描述，识别以下维度的缺失/歧义：
| 优先级 | 维度 | 典型问题 |
|---|---|---|
| P0 | 目标/意图 | 要实现什么、为什么做 |
| P1 | 范围/边界 | 包含什么、排除什么 |
| P2 | 验收标准 | 怎样算完成、成功指标 |
| P3 | 技术约束 | 性能要求、兼容性、依赖限制 |
| P4 | 隐含假设 | 需要用户确认的推断 |
Step 2 — 迭代澄清循环（问到清楚为止）：
AskUserQuestion 发送（选项按 ${LANG}）Step 3 — 输出：精炼需求摘要（bulleted list，按 ${LANG}），包含关键假设列表。
审批 gate：执行审批 gate 强制规则，选项为「采纳 → Phase 2 / 补充澄清（重入循环）/ 终止」。用户选「补充澄清」时重入 Step 2 循环继续迭代。这是三处关键人工边界之一，无论 --interactive 与否都必须执行。
WebSearch 补充Explore 子 Agent（subagent_type: Explore）扫描代码库，查找相关代码、可复用工具函数、现有设计模式、潜在冲突点；可同时派发多个 Explore Agent 扫描不同维度向用户展示（按 ${LANG}）：
| 操作 | 文件路径 | 理由 |
|---|---|---|
| 修改 | src/xxx.ts | 具体原因 |
| 新增 | src/yyy.ts | 具体原因 |
| 不可触碰 | src/zzz.ts | 超出范围 |
git revert 是否充分 / 是否需数据迁移回退脚本）在审批前先做 DAG 拆分，使「批准方案」与「批准任务拆分」合并为一次决策：
${LANG}），标注预计执行模式：节点数=1→单 Agent 直派；2-3→指令式 fan-out；≥4→Workflow 确定性编排审批 gate：执行审批 gate 强制规则，选项为「批准方案+DAG → 执行段 / 修改方案或拆分 / 终止」。这是三处关键人工边界之一，无论 --interactive 与否都必须执行。此 gate 通过后，Phase 3-5 执行段自动接管，不再逐阶段询问用户。
DAG 拆分已在 Phase 2d 完成并随方案一并审批。Phase 3 仅做文档固化，是执行段的第一步。
在项目中写入 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 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、修复轮次硬计数、三维审计强制并行）的收益压过成本。
Agent 工具，run_in_background: true）；1 节点时该层仅一个 Agent。每个实现 Agent 的 prompt 按 references/impl-agent-prompt.md 的结构化模板（Objective / File Boundary / Task Boundary / Language / Output JSON）填充TaskOutput(task_id, block=true) 逐一等待，全部返回后才派发 Layer N+1；禁止收到任一通知就推进。设最大等待（建议 3600s），超时按异常 #3 处理modified_files 后，主 Agent 核对其 ⊆ 影响范围表；越界即按异常 #1 处理（不等到 Phase 5 才发现）AskUserQuestion阶段转换（指令式/单 Agent 模式）：自动 transition → Phase 5。本层全部成功即推进，不询问用户；失败按异常暂停 #3。--interactive 模式下追加标准检查点「进入 Phase 5 审计 / 回退修复 / 终止」。
主 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 / 终止」。
写实现的 Agent ≠ 审实现的 Agent。主 Agent 只做派发与汇总，不做实质审查。
主 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，禁止删减 |
以下任一信号一旦出现，立即停止当前动作，回到全局护栏重新校验：
Edit / Write 业务代码文件（违反全局护栏第 1 条）issues=[] 但 git diff 行数 > 200 且未附执行日志git diff 中且 scope-audit 未报 issuewhile 上限被改大于 3general-purpose 独立派发，不复用 Phase 4 任何 Agent ID，prompt 严禁注入实现 Agent 的对话历史/思考/自评（同护栏 10）git diff --unified=0 --no-ext-diff --ignore-all-space -- <影响范围内文件>，仅含改动行号+内容，剥离上下文与无关痕迹（消毒命令详见 references/audit-diff-sanitize.md）{任务描述, 影响范围表, 清洁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 手动执行以下循环：
audit.json${LANG}）阶段转换：条件化自动 transition。
--interactive 模式下追加标准检查点「批准 → Phase 6 / 派修复 Agent / 终止」AskUserQuestiongit commit / git push / gh pr create 后追溯告知分支名复核：分支命名已在 Phase 0「分支命名前置校验」步完成。此处仅复核当前分支名仍匹配 ^(feat|fix|refactor|docs|chore|test|perf)/[a-z0-9-]+$；若执行中被改动致不合规，AskUserQuestion 提示重命名后再继续
BASE_REF 再验证：git branch -r 确认 ${BASE_REF} 分支仍存在（防 Phase 0 后被删/改名）；不存在则 AskUserQuestion 让用户重选（候选：本地分支 / origin/main / 当前 HEAD），并回写 .claude/slim-task.json
副产物 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 追加了忽略规则）
产物黑名单检查：扫描 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
Staging 校验：git diff --cached --name-only 展示将提交的完整文件清单，连同 diff 摘要 + 提议的 Conventional Commits message 一并展示（按 ${LANG}）
第一次 AskUserQuestion（Commit 决策卡）：「确认 commit」/「修改 message 后再 commit」/「取消回 Phase 5」。选「修改 message」仅改 message 不重审；但若用户同时改了代码，必须先清理旧审计报告并回 Phase 5 重新审计（防代码与审计证据不同步）
commit 后立即第二次 AskUserQuestion（Push/PR 决策卡）：「push 到 origin/ + 开 PR」/「push 到 origin/（不开 PR）」/「push 到 origin/${BASE_REF}（仅当 BASE_REF ≠ main/master）」/「保留本地不 push」；worktree 模式下「push 到 main/master」永远禁用，不出现在决策卡
按决策执行，完成后汇报；清理本 task 的 checkpoint 目录
Worktree 收尾：AskUserQuestion 询问是否 ExitWorktree(action=keep) 保留。若保留，展示：worktree 绝对路径 + 分支名 + 合并指引 + 冲突回退方法：
git fetch && git checkout main && git merge worktree-slim-<slug>
# 冲突时：git merge --abort 回退，或手工解决后 git commit
用户拒绝 commit：列出手动调整事项，保留 checkpoint，结束流程
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub stoicatom/claude-autopilot --plugin slim-task