agentsclimarketplace

Root cause

Skill marsloting/product-thinking-pack/skills/root-cause

7 self-contained product-thinking skills that make an AI agent reason like a sharp PM before it acts. MIT.

Install
npx -y skills add marsloting/product-thinking-pack --skill root-cause

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Apply 5 Whys + Fishbone (Ishikawa) + Pareto when something already broke and you need to find the root cause, not the symptom. Use whenever 用户 says "为什么会这样" / "找根因" / "这个 bug 怎么发生的" / "用户为什么流失" / "数据为什么跌" / "上次也踩过这个坑" / "incident postmortem" / "事故复盘". Forces 5-level "why" probing past the first surface answer, distinguishes proximate cause from root cause, uses Fishbone's 6M categories (man/machine/method/material/measurement/environment) for systemic issues, applies Pareto 80/20 to prioritize fixes. Stops "fix the symptom" pattern. Self-contained methodology — no external docs required.

SKILL.md

7.6 KB, as published. Nobody here has run it

根因分析（5 Whys + Fishbone + Pareto）

何时触发

  • 已经发生的问题 / bug / incident / 数据异常
  • "为什么 X" 类问题
  • 重复出现的同类问题（"上次也踩过"）
  • 用户流失 / 转化下降 / 留存崩盘
  • 上线后事故复盘
  • "这次修了，下次还会不会"

何时不触发

  • 上线前的风险预测 → 用 pre-mortem
  • 多个候选项排序 → 用 rice-prioritization
  • 用户需求挖掘 → 用 jtbd-framework

默认起点：5 Whys（Toyota 经典）

最简单最有效。从症状开始连问 5 个 why，每个 why 的答案是下一个 why 的输入。

标准模板

症状：<具体观察到的问题>
↓ Why 1?
答案 1：<直接原因>
↓ Why 2?
答案 2：<更深一层>
↓ Why 3?
答案 3：<更深一层>
↓ Why 4?
答案 4：<更深一层>
↓ Why 5?
答案 5：<根因，通常是流程 / 文化 / 系统设计层>

经典案例（Toyota）

症状：机器停转
Why 1? 保险丝烧了
Why 2? 电流过载
Why 3? 轴承润滑不足
Why 4? 润滑泵工作不正常
Why 5? 润滑泵的轴磨损（根因 → 替换轴 + 增加维护流程）

如果只修到 Why 1（换保险丝），下次还会烧。修到 Why 5（替换轴 + 加流程），从根上解决。

5 Whys 红线

  • 不允许在 Why 3 之前停：到 Why 3 大概率还在症状层
  • 不允许全程指向同一个人："因为 X 没做好"5 次出现 = 你在找替罪羊不是找系统问题
  • 不允许循环回路：Why 4 答案 = Why 1 答案 → 你在原地打转
  • 每层 why 必须可证伪："因为大家不重视"不是答案，要继续问"什么导致大家不重视"

升级：Fishbone (Ishikawa) Diagram

5 Whys 假设单一因果链。当问题是多因素叠加时（症状有多个并行原因），用 Fishbone。

6M 分类（生产 / 工程标准）

                                    ┌─ Man (人)
                                    │
         Method (方法) ──┐         ┌─┘
                          ↓         ↓
症状 ←────────── 原因汇集 ─────────────
                          ↑         ↑
         Machine (机器) ─┘         └─ Material (材料)
                                    │
                                    └─ Environment (环境)
                                       Measurement (测量)

6M 在软件 / 产品场景的映射

类别软件 / 产品场景含义
Man（人）用户行为 / 团队技能 / 沟通 / 培训缺失
Machine（机器）基础设施 / 服务器 / 第三方依赖 / 工具链
Method（方法）流程 / SOP / 协议 / 评审机制
Material（材料）数据 / 文档 / 内容 / 素材
Measurement（测量）监控 / 日志 / 指标定义 / 告警阈值
Environment（环境）部署环境 / 时间窗口 / 业务背景 / 合规约束

每个类别下列至少 2 条可能原因 → 6 × 2 = 12 个起点 → 找出真正贡献度最高的 2-3 个。

收敛工具：Pareto 80/20

Fishbone 列出 12+ 原因后，80% 的影响通常来自 20% 的原因。

评估流程

  1. 每条原因估算"贡献度百分比"（团队投票或数据估算）
  2. 排序 → 累计百分比达到 80% 的项是关键少数
  3. 优先 fix 关键少数，其余记录但不主动 fix

Pareto 红线

  • 不允许把所有原因平均分配权重：12 条原因每条 8% = 没分析
  • 关键少数通常 2-4 条：超过 6 条说明你没真正归因
  • 数据估算 > 团队投票：能量化用量化（错误率 / 用户数 / 工时）

5 步标准流程

  1. 症状陈述：写下"具体观察到什么"，不写解读。"用户流失" → 不行。"用户在 onboarding 第 3 步流失率从 20% 上升到 45%" → 行
  2. 5 Whys 起步：从症状开始连问 5 个 why。卡在 Why 3 之前 = 没到根因
  3. 多因素信号检测：5 Whys 答到 Why 3-4 时如果出现"原因有好几个"——切换到 Fishbone
  4. Fishbone 6M 列原因：每个 M 类别至少 2 条
  5. Pareto 收敛：排序 → 关键少数 → 优先 fix

模板（完整根因分析）

# <事故 / 问题> 根因分析

## 症状
- 具体观察：<可量化的描述>
- 时间范围：<开始 - 持续>
- 影响范围：<用户数 / 业务影响>

## 5 Whys（如单因素链）
- Why 1: ... → 答案
- Why 2: ... → 答案
- Why 3: ... → 答案
- Why 4: ... → 答案
- Why 5: ... → 根因

## Fishbone 6M（如多因素）

### Man
- 原因 A1 (贡献度 估 X%)
- 原因 A2 (贡献度 估 X%)

### Machine
- 原因 B1 ...
- 原因 B2 ...

### Method
...

### Material
...

### Measurement
...

### Environment
...

## Pareto 排序
| 原因 | 贡献度 | 累计 |
|---|---|---|
| C1 | 35% | 35% |
| C2 | 25% | 60% |
| C3 | 20% | 80% ← 关键少数线 |
| C4 | 8% | 88% |
| ... |

## 修复动作
- 关键少数 (top 3)：
  - C1 → <具体动作> / Owner / 截止
  - C2 → <具体动作> / Owner / 截止
  - C3 → <具体动作> / Owner / 截止
- 其余记录但不主动 fix（accept）

## 系统性预防（重要）
此根因导致下次 X 还会发生吗？如果会，加什么流程 / 监控 / 协议防止？

Anti-Rationalization

逃逸路径为什么不行
"Why 2 已经找到原因了"Why 2 几乎都是症状层。强制问到 Why 5，到流程 / 系统 / 文化层才是根因
"因为 X 没做好" 重复 5 次你在找人背锅不是找系统问题。换问题：是什么让 X 没做好的环境 / 流程 / 工具？
"5 Whys 太呆板"呆板是 feature 不是 bug。强制深挖防止思维断在第一层
"Fishbone 太正式不适合 startup"6M 是分类工具不是仪式。startup 团队 30 分钟跑完 Fishbone 比"凭感觉找原因"准 5 倍
"Pareto 估贡献度不准"不准也比不估好。team 三人独立估 → 取中位数 → 偏差 ±10% 内已经足够指导决策
"只修关键少数其他不管"Pareto 是 80/20 不是 100/0。关键少数优先 fix，其他记录 + 监控，发现升级时再处理
"找到根因就行了不用管系统预防"只 fix 实例 = 同根因第二次还会发生 = 重复劳动。系统性预防（加流程 / 加监控 / 加协议）是根因分析的必要产出，不是 nice-to-have
"incident postmortem 模板我们公司有"公司模板 ≠ 5 Whys。多数公司 postmortem 停在 Why 2-3 层（"修了 bug 加了监控"）。本 skill 强制 Why 5 + 系统预防

关联

  • 找到根因后修复优先级排序：用 rice-prioritization
  • 系统性预防方案要 review：用 pre-mortem
  • 重大事故升级到全局复盘：写到 methodology/internal-retrospective-YYYY-MM-DD.md（参考 retrospective-hygiene 5 条偏差）
  • 同根因第二次出现 → 触发 cross-domain-defense 第三层熔断

Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.