v1.0: 黑手党提案 Agent 初始版本
- AGENTS.md: TOC 五步法方法论注入 - 5 个 Skills: UDE诊断/冲突图/惯例打破/负面分支/提案组装 - HEARTBEAT.md: 每日自动更新 + 每周方法论回顾 - install.sh: 一键安装脚本 - 完整 SPEC 文档
This commit is contained in:
@@ -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/ 目录作为案例存档。
|
||||
> 如果在后续使用中发现方法论有需要改进的地方，我会在下次心跳时自动整理迭代建议。"
|
||||
Reference in New Issue
Block a user