v1.0: 黑手党提案 Agent 初始版本

- AGENTS.md: TOC 五步法方法论注入
- 5 个 Skills: UDE诊断/冲突图/惯例打破/负面分支/提案组装
- HEARTBEAT.md: 每日自动更新 + 每周方法论回顾
- install.sh: 一键安装脚本
- 完整 SPEC 文档

agent/skills/conflict_cloud/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: 冲突图构建
+description: 对筛选出的主要UDE构建冲突图（Evaporating Cloud），拆解O-B-D结构，合并多个UDE的冲突图
+---
+
+# 冲突图构建（Evaporating Cloud / Conflict Cloud）
+
+当用户完成了 UDE 诊断（筛选出最重要的 3 个 UDE + 恶性循环），进入"定义核心冲突"时，激活此 Skill。
+
+## 概念说明
+
+冲突图（又称"蒸发云"）是 TOC 思考过程的核心工具。它揭示的不是"问题"，而是"为什么问题一直存在"——因为存在一个看似无法调和的冲突。
+
+## 第一步：对每个主要 UDE 构建冲突图
+
+### 构建逻辑（Agent 内部推理过程）
+
+1. 将 UDE 反转为 DE（期望效果）
+2. 思考：DE 的必备条件是什么？（D：只有做了 D，UDE 才会转化为 DE）
+3. 从 D 中找到两个矛盾的行动方向（D1 vs D2）
+4. D1 对应的期望效果 = B1（需求1）
+5. D2 对应的期望效果 = B2（需求2）
+6. B1 和 B2 共同服务的上层目标 = O
+
+### 引导用户的提问
+
+对每个主要 UDE，依次提问：
+
+1. "当您感受到这个 UDE 时，团队**通常的做法**是什么？" → 这就是 D1
+2. "如果不考虑任何限制，您**期望采取的做法**是什么？" → 这就是 D2
+3. "D1 试图满足的需求是什么？" → 这就是 B1
+4. "D2 试图满足的需求是什么？" → 这就是 B2
+5. "B1 和 B2 共同服务的更大目标是什么？" → 这就是 O
+
+### 输出模板（每个 UDE 一份）
+
+```markdown
+### UDE-[编号]：[UDE 描述]
+
+| 维度 | 目标 | 需求 | 行动 |
+|------|------|------|------|
+| 惯性方向 | O: [系统目标] | B1: [需求1] | D1: [当前通常做法] |
+| 期望方向 |  | B2: [需求2] | D2: [期望做法] |
+
+#### 互斥性检查
+- ✅ 如果 D1，则不能 D2：[解释为什么]
+- ✅ 如果 D2，则不能 D1：[解释为什么]
+- ✅ 只有 D1 才能 B1：[解释]
+- ✅ 只有 D2 才能 B2：[解释]
+- ✅ 如果 D1 则不能 B2：[解释]
+- ✅ 如果 D2 则不能 B1：[解释]
+```
+
+### 互斥性校验规则
+
+**这是最关键的质量关卡。** D1 和 D2 必须满足以下全部条件：
+- D1 和 D2 不能同时执行（不是"程度差异"，而是"方向互斥"）
+- 选择 D1 必然牺牲 B2
+- 选择 D2 必然牺牲 B1
+- 如果可以"都做一点"，说明冲突图构建有误，需要重新提炼
+
+## 第二步：合并冲突图
+
+当多个 UDE 的冲突图都完成后，寻找它们的共性：
+
+### 合并规则
+1. 将多个 O 合并为统一的系统目标
+2. 将多个 B1 合并为"惯性方向的需求集"
+3. 将多个 B2 合并为"期望方向的需求集"
+4. 将多个 D1 合并为"当前采取的行动集"
+5. 将多个 D2 合并为"希望采取的行动集"
+
+### 输出模板
+
+```markdown
+### 合并冲突图
+
+| 维度 | O合并 | B | D |
+|------|-------|---|---|
+| 惯性方向 | 1. [目标1] | B1 合并：| D1 合并（当前行动）：|
+|  | 2. [目标2] | - [需求a] | - [行动a] |
+|  | 3. [目标3] | - [需求b] | - [行动b] |
+| 期望方向 |  | B2 合并：| D2 合并（期望行动）：|
+|  |  | - [需求c] | - [行动c] |
+|  |  | - [需求d] | - [行动d] |
+```
+
+## 完成标志
+
+- [ ] 每个主要 UDE（3个）都有独立的冲突图
+- [ ] 每个冲突图通过互斥性校验
+- [ ] 完成合并冲突图
+- [ ] 用户确认合并结果
+
+完成后，提示用户进入下一步：**步骤2 - 揭示冲突背后的惯例**。

agent/skills/convention_breaker/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: 惯例打破与方案激发
+description: 揭示冲突背后的行业惯例，通过因果假设分析找到隐含假设，用例外案例激发打破惯例的方案，输出方向性提案
+---
+
+# 惯例打破与方案激发（Convention Breaker）
+
+当用户完成了冲突图构建（合并冲突图就绪），进入"揭示惯例"和"用例外激发方案"时，激活此 Skill。
+
+此 Skill 覆盖原方法论的 **步骤2（揭示惯例）** 和 **步骤3（用例外激发方案）**。
+
+---
+
+## 部分一：揭示冲突背后的惯例（步骤2）
+
+### 核心问题
+
+对合并冲突图中的每对 B1-D1，追问：
+
+> **"为什么用户想要 B1，就一定得 D1？"**
+
+### 因果假设分析法
+
+用 CLR（因果逻辑推理）格式拆解：
+
+```
+因为：D1 [当前行动]
+同时：[隐含假设]
+那么：B1 [需求被满足]
+```
+
+如果这个逻辑链成立，说明"隐含假设"就是维持 D1 的根基。
+
+### 引导提问
+
+1. "在你们行业，为什么大家都选择 D1 而不是 D2？"
+2. "D1 背后有什么'理所当然'的假设？"
+3. "这个假设对应的行业通常做法（惯例）是什么？"
+4. "你能举出具体的同行案例来证明这个惯例的存在吗？"
+
+### 输出模板
+
+```markdown
+### 惯例分析
+
+| 关键问题 | 假设 | 行业惯例（直接证据/通常做法） | 总结 |
+|---------|------|---------------------------|------|
+| 为什么想要 B1:[XX] 就必须 D1:[XX]？ | [假设1] | [具体行业做法] | 如果遵循惯例1: [XX]，则用户只会D1不会D2 |
+| 检查：因为 D1，同时 [假设]，那么 B1 | [假设2] | [具体行业做法] | 如果遵循惯例2: [XX]，则用户只会D1不会D2 |
+```
+
+### 惯例验证（两个视角，必做）
+
+#### 我方视角验证
+
+```markdown
+1. 惯例是不是行业内保护自身利益的"普遍做法"？
+   - 惯例1 [XX]：✅/❌ [解释]
+   - 惯例2 [XX]：✅/❌ [解释]
+
+2. 惯例是否导致/加剧当下的恶性循环？
+   - 因为：企业继续遵守惯例 [XX]
+   - 假设：同时，[XX]
+   - 结果：恶性循环中 [XX] 将加剧
+```
+
+#### DTB（客户）视角验证
+
+```markdown
+1. 惯例直接导致了主要 UDE 中的至少一个？
+   - 惯例 [XX] → 直接导致 UDE-[编号]：✅/❌
+
+2. 惯例导致加剧了恶性循环？
+   - 惯例 [XX] → 加剧循环 [编号]：✅/❌
+```
+
+**如果验证不通过，需要回退重新寻找惯例。**
+
+---
+
+## 部分二：用例外激发方案（步骤3）
+
+### 核心规则
+
+**例外必须是具体实例，而不是逻辑推演。** 不接受"理论上可以……"，必须是"在 XX 行业，XX 公司做到了……"。
+
+### 引导提问
+
+对每个惯例，依次提问：
+
+1. "有没有哪家公司/哪个行业，做了跟这个惯例完全相反的事，反而成功了？"
+2. "如果用户可以同时获得 B1 和 B2，那需要什么样的新做法？"
+3. "发生了什么例外事件破坏了这个假设？"
+
+### 方案激发模板
+
+对每个惯例分别填写：
+
+```markdown
+### 惯例 [编号]：[惯例名称]
+
+| 维度 | DTB目标 | 需求 | 行动 | 激发方案 |
+|------|--------|------|------|---------|
+| 之所以D2无法B1，是因为假设： |  |  |  | [隐含假设] |
+| 现有惯例对应D1 | O: [XX] | B1: [XX] | D1: [XX] | 例外是：[具体公司/行业实例] |
+| 打破惯例对应D2 |  | B2: [XX] | D2: [XX] | 可以尝试的是：[具体方案] |
+```
+
+### 方向性提案总结（必须输出）
+
+当所有惯例都完成方案激发后，用以下固定格式输出总结：
+
+```markdown
+## 方向性提案总结
+
+> **通过** D [具体行动]，**满足** B [具体需求]；
+> **同时通过** D' [具体行动]，**满足** B' [具体需求]；
+> **使 DTB 既可以** O1 [目标1]，**又能够** O2 [目标2]。
+
+### 具体拆解
+- D：[行动描述]
+- B：[需求描述]
+- D'：[行动描述]
+- B'：[需求描述]
+- O1：[目标描述]
+- O2：[目标描述]
+```
+
+---
+
+## 完成标志
+
+- [ ] 每个惯例都经过因果假设分析
+- [ ] 每个惯例通过双视角验证（我方 + DTB）
+- [ ] 每个惯例都找到了具体的例外案例（不是逻辑推演）
+- [ ] 输出了方向性提案总结
+- [ ] 用户确认方向性提案
+
+完成后，提示用户进入下一步：**步骤4 - 消除负面分支**。

agent/skills/negative_branch/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: 负面分支消除
+description: 识别新方案可能带来的新UDE，构建因果假设链，在链条中找到打破假设的节点来消解负面分支
+---
+
+# 负面分支消除（Negative Branch Reservation）
+
+当用户完成了方向性提案总结，进入"消除负面分支"时，激活此 Skill。
+
+## 概念说明
+
+任何新方案在解决旧问题的同时，都会带来新的副作用。负面分支消除不是否定新方案，而是提前预见并设计配套措施，使副作用不会危害核心需求。
+
+---
+
+## 第一步：列出新方案可能导致的所有新 UDE
+
+### 引导提问
+
+向用户提供以下发散思考维度：
+
+> "如果我们实施了方向性提案中的新方案（D + D'），可能会出现哪些新的不良效果？"
+
+提供以下清单帮助用户发散思考：
+
+- 协同复杂度增加（扯皮和纠纷变多）
+- 考核边界不清晰（难以量化）
+- 管理复杂度增加
+- 局部效率降低
+- 结果不确定性高
+- 不适应新的思考和行为模式
+- 加重了认知负担
+- 提升了决策难度
+- 决策慢
+- 错失"机会"多
+- 官僚作风
+- 办公室政治
+- 对人才的要求高
+- 短期业绩可能下滑
+- 组织阻力大
+- 其他（请用户补充）
+
+## 第二步：筛选危害性 UDE
+
+从新增 UDE 中，筛选出**同时满足**以下两个条件的：
+
+1. **直接危害**现有任一 B（方向性提案中的需求）
+2. **客户感受强**（客户会第一时间抱怨）
+
+### 输出模板
+
+```markdown
+### 危害性 UDE 筛选
+
+| 被危害的 B | 新增 UDE | 客户感受 |
+|-----------|---------|---------|
+| B1: [需求] | [新UDE描述] | [为什么客户感受强] |
+| B2: [需求] | [新UDE描述] | [为什么客户感受强] |
+```
+
+## 第三步：构建因果假设链
+
+对每个危害性 UDE，从方案 D 开始，追踪因果链条直到最终 UDE。
+
+### 构建规则
+
+1. 从最底层（方案 D）向上推演
+2. 每一步标注"假设"（这步成立需要什么前提）
+3. 每一步标注性质：DE（好的中间结果）还是 UDE（坏的中间结果）
+4. **重点寻找**：链条中 DE 变为 UDE 的转折点——那就是打破假设的节点
+
+### 输出模板（每个危害性 UDE 一份）
+
+```markdown
+### 因果假设链：[最终 UDE 描述]
+
+|  | 因果假设链 |  | 性质 |
+|--|-----------|--|------|
+| 结果 | 最终结果：[UDE 描述] |  | UDE |
+| 过程 | 中间结果3：[XX] | 假设：[XX] | UDE |
+|  | 中间结果2：[XX] | 假设：[XX] | UDE/DE |
+|  |  |  | **→ 打破假设的方案：[XX]** |
+|  | 中间结果1：[XX] | 假设：[XX] | DE |
+| 方案 | D：[新方案] | 假设：[前提条件] |  |
+```
+
+## 第四步：验证打破假设方案的有效性
+
+对每个"打破假设的方案"，用以下模板验证：
+
+```markdown
+### 验证：[打破的假设]
+
+| 如果： | D [具体方案] |
+|--------|-------------|
+| 同时： | 假设 [前提条件被满足] |
+| 那么： | UDE变成DE：[原UDE描述] → [新DE描述] |
+| 并且那么： | 现有DE没有转变为UDE：✅ [确认说明] |
+```
+
+### 验证标准
+- "UDE 变成 DE"必须是具体的、可感知的改善
+- "现有 DE 没有转变为 UDE"必须逐一检查所有现有 DE
+- 如果验证不通过，需要回退修改打破假设方案
+
+---
+
+## 完成标志
+
+- [ ] 列出了所有可能的新增 UDE
+- [ ] 筛选出直接危害 B 且客户感受强的 UDE
+- [ ] 每个危害性 UDE 都有因果假设链
+- [ ] 每条链上找到了打破假设的节点和方案
+- [ ] 每个打破假设方案通过了"如果-同时-那么"验证
+- [ ] 用户确认所有负面分支已消解
+
+完成后，提示用户进入最后一步：**步骤5 - 确立新规则、匹配新能力**。

agent/skills/proposal_assembler/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: 提案组装
+description: 确立新规则、匹配运营能力、组装最终黑手党提案交付文档
+---
+
+# 提案组装（Proposal Assembler）
+
+当用户完成了负面分支消除，进入最后阶段时，激活此 Skill。
+
+此 Skill 覆盖 **步骤5（确立新规则、匹配新能力）** 和 **最终交付文档组装**。
+
+---
+
+## 部分一：确立新规则（步骤5）
+
+### 第一步：对比新旧惯例
+
+```markdown
+### 新旧惯例对比
+
+| 维度 | 旧惯例 | 新规则 |
+|------|-------|-------|
+| 惯例1 | [旧做法] | [打破后的新做法] |
+| 惯例2 | [旧做法] | [打破后的新做法] |
+```
+
+### 第二步：梳理剩余 UDE
+
+将所有 UDE 分为两类：
+
+| 分类 | 说明 | 处理方式 |
+|------|------|---------|
+| 原 UDE 未被方向性提案解决的 | 打破惯例后仍然存在 | 需要额外运营能力 |
+| 新方案导致的新 UDE（负面分支未完全消解的） | 步骤4 的遗留 | 需要配套运营能力 |
+
+### 第三步：匹配运营能力
+
+对每个剩余 UDE，明确"要把它转化为 DE 需要什么能力"：
+
+```markdown
+### 运营能力匹配
+
+| 分类 | 期望改变的结果 | 运营能力（我方产品为DTB增加的能力） |
+|------|-------------|--------------------------------|
+| 原UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
+| 原UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
+| 新UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
+| 新UDE → DE | [UDE描述] → [期望DE] | [具体运营能力] |
+```
+
+### 第四步：输出产品说明书
+
+将运营能力归类到具体的产品/服务单元中：
+
+```markdown
+### 产品说明书
+
+| 产品单元 | 运营能力（改变UDE为DE） | 运营能力（维持DE） |
+|---------|---------------------|------------------|
+| [产品1] | [改变能力描述] | [维持能力描述] |
+| [产品2] | [改变能力描述] | [维持能力描述] |
+```
+
+---
+
+## 部分二：组装最终交付文档
+
+完成以上所有步骤后，将全流程的输出组装为完整的黑手党提案文档。
+
+### 最终交付文档结构
+
+```markdown
+# [品牌名] 产品上新 — 黑手党提案
+
+> 生成时间：YYYY-MM-DD
+> 方法论版本：vX.Y
+> Agent：mafia-expert
+
+---
+
+## 一、双赢定义
+
+### 1.1 概念共识
+[对黑手党提案概念的共识——来自准备1]
+
+### 1.2 JTBD 四要素
+[四要素表——来自准备2]
+
+| 维度 | 我方 | 典型目标客户（DTB） |
+|------|------|-------------------|
+| 客户画像 | ... | ... |
+| 雇用产品 | ... | ... |
+| 待办任务 | ... | ... |
+| 期望结果 | ... | ... |
+
+---
+
+## 二、UDE 诊断
+
+### 2.1 完整 UDE 清单
+[编号列表——来自准备3，标注10条标准校验结果]
+
+### 2.2 最重要的 3 个 UDE
+[Top3 及选择理由——来自准备3]
+
+### 2.3 恶性循环
+[循环图——来自准备3]
+
+---
+
+## 三、核心冲突
+
+### 3.1 各 UDE 冲突图
+[每个UDE的O-B-D表——来自步骤1]
+
+### 3.2 合并冲突图
+[合并后的结果——来自步骤1]
+
+---
+
+## 四、惯例揭示与方向性提案
+
+### 4.1 行业惯例清单
+[惯例分析表——来自步骤2]
+
+### 4.2 惯例验证
+[双视角验证结果——来自步骤2]
+
+### 4.3 方向性提案总结
+> 通过 D [XX]，满足 B [XX]；
+> 同时通过 D' [XX]，满足 B' [XX]；
+> 使 DTB 既可以 O1，又能够 O2。
+[——来自步骤3]
+
+---
+
+## 五、操作性提案
+
+### 5.1 负面分支消除
+[因果假设链 + 打破假设方案——来自步骤4]
+
+### 5.2 新规则与新能力
+[运营能力匹配表——来自步骤5]
+
+### 5.3 产品说明书
+[产品单元 × 运营能力矩阵——来自步骤5]
+
+---
+
+## 附录
+
+### A. 数据来源与证据链
+[列出所有信息来源]
+
+### B. 研讨过程记录
+[记录每步中用户的关键校准和决策]
+
+### C. 方法论版本与迭代日志
+[记录本次提案使用的 Agent 版本和 Skill 版本]
+```
+
+### 组装规则
+
+1. **不要添加新的分析**——只整理和呈现已有输出
+2. **保持逻辑链完整**——从 UDE 到最终产品说明书的推理链必须可追溯
+3. **标注来源步骤**——每个章节标注输出来自哪个步骤
+4. **提示用户保存**——建议将文件保存为 `cases/[品牌名]_[日期].md`
+
+---
+
+## 完成标志
+
+- [ ] 新旧惯例对比完成
+- [ ] 所有剩余 UDE 都匹配了运营能力
+- [ ] 产品说明书输出
+- [ ] 最终交付文档组装完成，五章结构完整
+- [ ] 用户确认最终交付物
+- [ ] 提案文件已保存
+
+完成后，告知用户：
+
+> "黑手党提案已完成。建议将此文件保存到 cases/ 目录作为案例存档。
+> 如果在后续使用中发现方法论有需要改进的地方，我会在下次心跳时自动整理迭代建议。"

agent/skills/ude_diagnosis/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: UDE 诊断
+description: 引导用户识别不良现状效果（UDE），进行10条标准校验，筛选最重要的3个UDE，并识别恶性循环
+---
+
+# UDE 诊断（Undesirable Effects Diagnosis）
+
+当用户完成了准备1（概念对齐）和准备2（JTBD 四要素），需要进入"定义双赢"时，激活此 Skill。
+
+## 第一步：引导用户列出所有 UDE
+
+向用户解释：
+> "UDE（不良现状效果）是您的客户当前持续承受的、让他们无法表现更好的问题。我们需要尽可能多地列出来。"
+
+请用户从以下维度思考：
+- 战略层：方向不清、节奏不明
+- 业绩层：增长乏力、利润下降
+- 营销层：费用高、效果差
+- 组织层：架构不合理、协调不畅
+- 人才层：关键岗位缺位、能力不足
+- 运营层：缺数据、缺反馈机制
+- 财务层：缺科学核算、现金流紧张
+
+## 第二步：逐条 10 标准校验
+
+对用户列出的每条 UDE，逐一检查以下 10 条标准。**不合格的 UDE 必须退回修改或删除，不能凑合使用。**
+
+| 序号 | 标准名称 | 检查问题 | 不合格则… |
+|------|---------|---------|----------|
+| 1 | 持续存在 | 这是一个持续存在的问题吗？还是一次性事件？ | 改为持续性描述 |
+| 2 | 当下正在发生 | 这是现在时态的陈述吗？还是对未来的假设？ | 改为现在时态 |
+| 3 | 描述状态 | 这是对系统状态的描述吗？还是一个动作？ | 改为状态描述 |
+| 4 | 责任范围内 | 这属于您（或客户）的责任/影响范围吗？ | 删除或缩小范围 |
+| 5 | 可以解决 | 可以采取措施来改善这个问题吗？ | 删除 |
+| 6 | 不归因于人 | 有没有在责怪某个具体的人？ | 改为系统性描述 |
+| 7 | 不分析原因 | 有没有包含推测的原因？ | 去掉原因部分 |
+| 8 | 不是解决方案 | 有没有隐藏着一个解决方案？ | 改为问题描述 |
+| 9 | 单独实体 | 是否只包含一个问题？ | 拆分为多条 |
+| 10 | 不是主观猜想 | 这是事实还是主观感受？ | 改为可验证的事实 |
+
+### 输出格式
+
+对每条 UDE 输出校验结果：
+
+```markdown
+#### UDE-[编号]：[UDE 描述]
+
+| 标准 | 通过？ | 备注 |
+|------|-------|------|
+| 1. 持续存在 | ✅/❌ | [如不通过，说明原因] |
+| 2. 当下正在发生 | ✅/❌ | |
+| ... | ... | ... |
+
+**结论**：✅ 合格 / ❌ 需修改：[修改建议]
+```
+
+## 第三步：筛选最重要的 3 个 UDE
+
+从合格的 UDE 中，按以下两个标准**同时满足**来筛选：
+
+1. **关联性**：跟买我们的产品、用我们的服务有关（我们和同行导致了这个 UDE）
+2. **杠杆性**：这个 UDE 对于客户至关重要，直接或间接影响了 70% 以上的其他 UDE
+
+### 输出格式
+
+```markdown
+### 最重要的 3 个 UDE
+
+1. **UDE-[编号]：[描述]**
+   - 关联性：[解释为什么跟我们的产品/服务有关]
+   - 杠杆性：[解释它影响了哪些其他 UDE，覆盖了百分之多少]
+
+2. **UDE-[编号]：[描述]**
+   - 关联性：[...]
+   - 杠杆性：[...]
+
+3. **UDE-[编号]：[描述]**
+   - 关联性：[...]
+   - 杠杆性：[...]
+```
+
+## 第四步：识别恶性循环
+
+从 UDE 清单中找出相互因果增强的 UDE 组合，构成恶性循环。
+
+### 构建规则
+- 恶性循环是 3-5 个 UDE 首尾相连的因果链
+- A 导致 B，B 导致 C，C 又反过来加剧 A
+- 至少识别 1 个恶性循环，建议 2-3 个
+
+### 输出格式
+
+```markdown
+### 恶性循环 1：[循环名称]
+[UDE-A] → [UDE-B] → [UDE-C] → [UDE-D] → 回到 [UDE-A]
+
+**解读**：[用一句话解释这个循环为什么会自我强化]
+
+### 恶性循环 2：[循环名称]
+[UDE-X] → [UDE-Y] → [UDE-Z] → 回到 [UDE-X]
+
+**解读**：[...]
+```
+
+## 完成标志
+
+当以下条件全部满足时，此 Skill 完成：
+- [ ] 所有 UDE 通过 10 条标准校验（或已修正/删除）
+- [ ] 筛选出最重要的 3 个 UDE（两个标准同时满足）
+- [ ] 至少识别 1 个恶性循环
+- [ ] 用户确认以上输出
+
+完成后，提示用户进入下一步：**步骤1 - 定义核心冲突**。