人虾协作开发工作流

软件开发工作流+通用方案输出自检，融合Superpowers方法论，强制设计先行→批判性三问自检→计划分解→子Agent执行→双阶段Review。触发词：开发、写代码、新功能、新skill、重构、修bug、实现、build、implement、帮我做一个、方案自检、三问自检。即使用户没有明说'走流程'，只要涉及新建/修改/重构代码或Skill，就应触发。不适用：纯闲聊。

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

---

经验法则（维护者必读，执行时内化）

1. 规则必须嵌入必经路径：触发规则写入 SOUL.md/AGENTS.md 等必加载文件，依赖「想起来」的规则等于没有规则
2. 改执行路径，不是写记忆：犯错后把教训转化为 HARD-GATE 或格式模板，写 memory「下次不要XXX」无效
3. 模板单源头：一个模板只能在一个地方定义；每次改模板后 grep -rl "关键短语" references/，有命中→删或改引用
4. 计划分解与任务派发对 Skill 创建是同一动作：Skill 创建（纯文本写作）的计划文档 ≈ 子Agent task description，合并为一步
5. 事故必须闭环成可执行约束（ICE-5）：满足触发条件的失败，必须在已有的设计计划／代码或脚本／阶段5验收里补齐五字段——触发步骤、强制点、失败行为、运行证据、失败后动作（WHY:只写 memory/复盘/issue 属于「记录了但没修」，下次同样的路径仍会静默通过；把字段嵌进必经路径才真正阻断复发）。触发条件（三选一）：同类失败第二次出现 / 首次造成对外交付或发布事故 / 不可逆或外部依赖存在静默降级、伪成功风险。普通小问题与纯定性场景不强制。禁止新建孤立矩阵或独立文档来「安放」它。

---

工作流全图

text

需求 → [阶段1] 需求澄清 → [阶段2] 设计确认 → [阶段3/4] 计划与执行 → [阶段5] 验收收尾

---

阶段 1：需求澄清（Brainstorming）

HARD-GATE：未完成本阶段，禁止写任何代码

入口条件：收到开发/方案/Skill 需求 出口条件：需求类型明确 + 方案选项已给出 + 木老师已确认选择（或 Skill Intent Brief 已确认）

步骤

1. 探索现有上下文（相关文件、已有 skill、最近变更）
2. 判断需求类型：Skill需求 → 先走「Skill 意图澄清协议」；其他开发 → 直接进步骤3
3. 一次只问一个问题（目标 → 约束 → 成功标准）
4. 提出 2-3 个方案（含优缺点和推荐理由）
5. 等待木老师确认选择

🎯 Skill 意图澄清协议（输入含「新Skill/优化Skill/改Skill」时必走）

核心原则：先问后做。 意图不清时禁止进入阶段2。最多问5个问题，不做问卷，不重复已知信息。

必问清单（按优先级，通常问前3个即可）：

#	问题	目的
1	这个 Skill 只做一件事，它必须消除用户的什么认知负担？	定位核心价值
2	你最不希望它被误解成什么？	定义边界
3	它最危险的失败模式是什么：问太多、问太少、执行太早，还是变成总结机器？	识别风险
4	它的输出应该改变谁的行为？	明确受益方
5	如果它跑通了，哪个现有工作流会变得多余或变轻？	评估影响范围

澄清完成后输出 Skill Intent Brief：

markdown

## 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任务）

markdown

# [功能名] 设计文档
**目标**：一句话 | **架构模式**：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 不要改用系统内置的通用版本；应使用项目指定版本。

操作：

1. 读 mu-skill-creator SKILL.md，按其完整流程执行
2. 过质量门控（IRON LAW / description / AP-1~20 / 行数≤300 / 触发词）
3. 安全检查：无人才标准/组织架构/角色指南/职级/人员信息/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/ 下计划文档

快捷模式输出格式

text

规模判断：[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时