IRON LAW：①未完成阶段1需求澄清禁止写任何代码（WHY:跳过=基于错误假设构建，改起来成本10倍）；②阶段2方案必附批判性三问自检，无自检 = 方案不完整禁止提交（WHY:自检能暴露80%隐含假设漏洞）；③阶段5验收必须有实际命令输出作证据，如涉及 Skill 文件必跟跑 skill-audit 全绿才算完成（WHY:无验证=无法排查回归问题）；④禁说“应该好了”“这样就对”——无验证输出 = 未完成。
mu-dev-workflow — 小木开发工作流
灵感来源：Superpowers（Jesse Vincent）
核心原则
- 设计先行，禁止冲动写代码（HARD-GATE）
- YAGNI：不需要的功能一律不加
- DRY：一个逻辑只写一次
- TDD：有条件时先写测试
- 子Agent执行 + 双阶段Review：保证质量
- 独立判断 ≥ 迎合 🧠：木老师的反馈是输入不是指令。每个阶段输出前必须经过自己的系统思维评估——这个方案真的对吗？有没有更好的？如果不同意木老师的建议，必须给出分析理由而不是沉默服从或无脑执行。
📖 架构决策见 references/architecture-patterns.md | 防跳步见 references/anti-rationalization.md
经验法则（维护者必读，执行时内化）
- 规则必须嵌入必经路径：触发规则写入 SOUL.md/AGENTS.md 等必加载文件，依赖「想起来」的规则等于没有规则
- 改执行路径，不是写记忆：犯错后把教训转化为 HARD-GATE 或格式模板，写 memory「下次不要XXX」无效
- 模板单源头：一个模板只能在一个地方定义；每次改模板后
grep -rl "关键短语" references/，有命中→删或改引用 - 计划分解与任务派发对 Skill 创建是同一动作：Skill 创建（纯文本写作）的计划文档 ≈ 子Agent task description，合并为一步
- 事故必须闭环成可执行约束（ICE-5）：满足触发条件的失败，必须在已有的设计计划／代码或脚本／阶段5验收里补齐五字段——触发步骤、强制点、失败行为、运行证据、失败后动作（WHY:只写 memory/复盘/issue 属于「记录了但没修」，下次同样的路径仍会静默通过；把字段嵌进必经路径才真正阻断复发）。触发条件（三选一）：同类失败第二次出现 / 首次造成对外交付或发布事故 / 不可逆或外部依赖存在静默降级、伪成功风险。普通小问题与纯定性场景不强制。禁止新建孤立矩阵或独立文档来「安放」它。
工作流全图
需求 → [阶段1] 需求澄清 → [阶段2] 设计确认 → [阶段3/4] 计划与执行 → [阶段5] 验收收尾
阶段 1：需求澄清（Brainstorming）
HARD-GATE：未完成本阶段，禁止写任何代码
入口条件：收到开发/方案/Skill 需求 出口条件：需求类型明确 + 方案选项已给出 + 木老师已确认选择（或 Skill Intent Brief 已确认）
步骤
- 探索现有上下文（相关文件、已有 skill、最近变更）
- 判断需求类型：Skill需求 → 先走「Skill 意图澄清协议」；其他开发 → 直接进步骤3
- 一次只问一个问题（目标 → 约束 → 成功标准）
- 提出 2-3 个方案（含优缺点和推荐理由）
- 等待木老师确认选择
🎯 Skill 意图澄清协议（输入含「新Skill/优化Skill/改Skill」时必走）
核心原则：先问后做。 意图不清时禁止进入阶段2。最多问5个问题，不做问卷，不重复已知信息。
必问清单（按优先级，通常问前3个即可）：
| # | 问题 | 目的 |
|---|---|---|
| 1 | 这个 Skill 只做一件事，它必须消除用户的什么认知负担？ | 定位核心价值 |
| 2 | 你最不希望它被误解成什么？ | 定义边界 |
| 3 | 它最危险的失败模式是什么：问太多、问太少、执行太早，还是变成总结机器？ | 识别风险 |
| 4 | 它的输出应该改变谁的行为？ | 明确受益方 |
| 5 | 如果它跑通了，哪个现有工作流会变得多余或变轻？ | 评估影响范围 |
澄清完成后输出 Skill Intent Brief：
## Skill Intent Brief：{Skill名}
- **显性目标**：用户直接说要解决什么
- **隐性张力**：背后真正的痛点/现有工具哪里不够
- **核心机制**：这个Skill的关键设计判断
- **可执行定义**：触发词 / 核心流程 / 输出格式（具体）
- **验证方法**：怎么知道Skill做对了？成功长什么样？
- **禁止事项**：不能做什么？边界在哪？
Brief 经木老师确认后，才进入阶段2设计。
Anti-rationalization 防跳步
完整借口表见 references/anti-rationalization.md 常见借口："需求很简单""我已经知道怎么做了""改一行而已""来不及先做""木老师催了" 遇到任何借口 → 停下来，完成阶段1再继续。
阶段 2：设计确认
入口条件：阶段1完成，木老师已确认方向 出口条件：方案已输出含批判性三问自检，木老师说「可以」/「确认」/「开始吧」
⚠️ 批判性自检 — 通用方案输出硬规则
任何方案/建议/策略输出前必须包含「批判性自检」章节，与方案一体输出。 此规则不局限开发场景——招聘策略、OP/TG、会议方案、流程设计等一切"给木老师的建议"均适用。 格式：问题列表（每项含检验过程 + 修正动作）。无自检 = 方案不完整，禁止提交给木老师确认。
三问自检（必答，场景无关）
| # | 自检问题 | 开发场景 | 招聘/HR场景 | 管理/规划场景 |
|---|---|---|---|---|
| 1 | 真问题？有没有更简单的解法？ | 方案是否over-engineering | 策略是否瞄准真正瓶颈 | 目标是真需求还是惯性延续 |
| 2 | 造轮子？已有资源能否复用？ | 现有Skill/工具能否cover | 现成流程/团队有没有在做 | 上下游有没有类似目标可协同 |
| 3 | 边界案例？极端情况怎么兜底？ | references是否完备、降级链 | 候选人放鸽子/HC冻结/JD变更 | 资源不足/方向变化/人不齐 |
扩展自检（按需选做）
内置调用 mu-critical-thinking 的 12 维度扫描：
- 主线资料是什么？注脚是什么？骨架 vs 补充关系是否清晰？
- 隐含假设是什么？如果假设不成立会怎样？
- 有没有被"沉没成本"或"从众"牵着走？
- 时间维度：短期收益 vs 长期代价的权衡够不够？
- 利益相关方：谁被遗漏了？谁的利益可能受损？
设计文档结构
通用模板（代码开发/重构/修bug等非Skill任务）
# [功能名] 设计文档
**目标**：一句话 | **架构模式**：A-F（见 [architecture-patterns.md](references/architecture-patterns.md)）
**方案**：选了哪个为什么 | **架构**：整体结构
**文件变更**：创建/修改清单 | **验收标准**：怎么算做完
Skill 创建专用模板（新建/优化/重构 Skill 时必用）
通用必含章节（所有类型）： ①批判性自检 ②定位与边界（含不适用场景）③核心设计 ④差异化能力 ⑤文件规划（含被read概率评估）⑥安全合规 ⑦I/O示例(≥3组) ⑧实施计划
按类型额外补充：
| 类型 | 代表 | 额外必含 |
|---|---|---|
| 知识编码型 | 引导虾/金字塔原理 | 主线vs注脚说明、ref精简策略 |
| 系统交互型 | 会议虾/招聘虾 | API依赖清单、降级链、认证方案 |
| 文档生成型 | PPT大师/述职虾 | 模板策略、渲染引擎说明、输出格式 |
| 质量检查型 | AI味消除剂/龙虾守卫 | 规则库来源、扫描路径、修正动作 |
⚠️ Confirmation Gate
木老师说"可以"/"确认"/"开始吧"之后，才进入阶段3（WHY:未经确认就执行=浪费双方时间，且难以回滚）
阶段 2.5：Skill 质量门控（非 Skill 开发跳过）
🚨 硬规则：创建或优化 Skill 必须调用 mu-skill-creator。 路径：
<SKILL_DIR>/mu-skill-creator/SKILL.md不要改用系统内置的通用版本；应使用项目指定版本。
操作：
- 读 mu-skill-creator SKILL.md，按其完整流程执行
- 过质量门控（IRON LAW / description / AP-1~20 / 行数≤300 / 触发词）
- 安全检查：无人才标准/组织架构/角色指南/职级/人员信息/C4数据
出口条件：mu-skill-creator 流程完成 + 安全检查通过
阶段 3/4：计划与执行（合并阶段）
入口条件：阶段2完成（含2.5 Skill质量门控，如适用） 出口条件：任务执行完毕，子Agent全部返回结果，核心功能可运行
Skill 创建 M 级以下走快捷模式；其他走完整计划模式。
模式选择
| 条件 | 模式 | 输出物 |
|---|---|---|
| Skill创建 <1500行 | 快捷模式 | 规模判断(1句)+task description |
| Skill创建 ≥1500行 | 完整计划 | docs/plans/ 下计划文档 |
| 非Skill开发 | 完整计划 | docs/plans/ 下计划文档 |
快捷模式输出格式
规模判断：[XS/S/M] | 总预估行数：~N行 | 文件数：N个
→ 直接进入子Agent派发（单 Agent 可 handle）
🚨 HARD-GATE：禁止 silently 跳过本阶段。即使走快捷模式也必须输出规模判断记录。
完整计划模式
详见原阶段3规范（任务粒度/模板/规模约束），保存到 docs/plans/YYYY-MM-DD-<功能名>.md
子Agent执行与Review
双阶段 Review 模板、Monitor 机制、共享目录约定 → 见 references/subagent-review-templates.md
任务规模约束
| 规模 | 文件数 | 要求 |
|---|---|---|
| XS | 1 | 主会话直接执行 |
| S | 2-3 | 主会话或单子Agent |
| M | 4-5 | 单子Agent |
| L | 6-10 | 必须继续拆到≤5 |
| XL | >10 | 拆为多个 M/S 子任务 |
阶段 5：验收收尾
入口条件：阶段3/4完成，任务已执行 出口条件：Verification Checklist 全部 ✅，已 commit，已报告木老师
HARD-GATE：必须有实际命令输出证明，不接受"应该好了"。
Verification Checklist
| 检查项 | 验证方式 | 期望结果 |
|---|---|---|
| 功能可运行 | 执行核心命令 | 无报错 |
| 测试通过 | pytest/npm test/go test | 全绿 |
| 构建通过 | npm run build/py_compile | exit 0 |
| 代码已提交 | git log --oneline -3 | 有本次 commit |
| 文档已更新 | git diff SKILL.md/TOOLS.md | 有修改 |
| 规格审查 ✅ | 子Agent输出 | 合规 |
| 质量审查 ✅ | 子Agent输出 | 通过 |
| 🚨 Skill Audit（涉及 Skill 文件时必做） | skill-audit.sh 自动扫描 + 输出完整 23 项 checklist，逐项确认全部 ✅ | 全部 ✅，否则禁止交付 |
| 🚨 ICE 事故闭环（适用时必做） | 逐项列出五字段（触发步骤／强制点／失败行为／运行证据／失败后动作），并贴出该强制点的实际命令输出或审计证据；说明字段嵌入的具体位置（设计计划／代码或脚本／本 Checklist） | 五字段齐全且证据可复现，否则禁止交付 |
收尾步骤
逐项跑 Checklist 贴输出 → 全 ✅ 后 commit → 更新文档 → 报告木老师
快速参考
| 场景 | 做法 |
|---|---|
| 新 Skill 开发 | 完整5阶段，阶段2.5 必须调 mu-skill-creator |
| 修小 bug（<30min） | 阶段1确认→直接执行 |
| 重构 | 阶段1-3，避免过度重构 |
| 加一个小功能 | 阶段1→阶段2简版→执行 |
| 非开发方案输出 | 阶段2三问自检必做，其余阶段按需 |
Pre-Delivery Checklist
- IRON LAW首位 | version=X.Y | 经验法则已内化到正文 | 阶段1含Skill意图澄清协议 | 阶段2含自检+Skill模板（4种类型完整）| 阶段3/4合并+HARD-GATE | references/3文件齐全 | 模板单源头检查通过（
grep -rl无重复）
子Agent最小执行规范
本 Skill 常被子Agent执行（如：Skill开发子Agent、方案输出子Agent）
必读文件：<SKILL_DIR>/mu-dev-workflow/SKILL.md（本文件）
不可跳过的硬 Gate：
- 阶段1：必须有明确需求确认，禁止直接写代码
- 阶段2：方案必须附批判性三问自检
- 阶段5：必须有实际命令输出作验收证据
- ICE 事故闭环（触发条件满足时）：必须在已有设计计划／代码或脚本／阶段5验收中补齐五字段并附实际命令或审计证据，禁止只写 memory／复盘／issue 就宣称完成
禁止行为：禁止跳过阶段1直接执行 | 禁止用"目测没问题"代替验证 | 禁止自创流程绕过门控 | 禁止把事故记录当作事故闭环
references 索引
| 文件 | 内容 | 何时读取 |
|---|---|---|
| architecture-patterns.md | 6大架构模式+决策树+共通组件 | 阶段2选架构模式时 |
| anti-rationalization.md | 6条防跳步借口+现实对照 | 阶段1遇借口时 |
| subagent-review-templates.md | 双阶段Review模板+Monitor机制+共享目录 | 阶段4派子Agent时 |