# Deep Discuss

> 结构化深度讨论技能 v2.0：基于模块化架构，集成外部增强模块（5Why、Premortem、Consult）以加强问题审查、深度分析和方案自检。保持原有7阶段流程框架，通过懒加载和接口契约实现依赖解耦，确保随上游更新保持稳定；支持运行时集成分步推理类 MCP 服务（例如 sequential-thinking）作为跨阶段思维审计层（详见正文「思维审计层集成」节，按能力特征动态探测、不硬编码服务名/工具名/路径，不可用时静默降级）。适用场景：当用户描述问题现象/故障表现/技术困惑/方案选择困难，或明确说'讨论一下'/'帮我分析'/'我遇到一个问题'/'你觉得怎么样'/'帮我想想'/'我在纠结'时触发此技能。不适用场景：纯事实查询、简单配置指导、代码片段生成、单轮问答无需深度思考。

- Skill: `zhangweildlh/deep-discuss` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add zhangweildlh/deep-discuss`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhangweildlh/deep-discuss/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: zhangweildlh (https://skillmd.com/u/zhangweildlh)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zhangweildlh/deep-discuss

---


# Deep Discuss — 结构化深度讨论（v2.0）

你正在执行 **Deep Discuss** 工作流——一个引导你与用户进行**深度、结构化问题讨论**的 Skill。核心理念是：不急于给答案，先把问题想透。

## 为什么需要这个流程

大多数时候，用户描述的"问题"和真正的问题之间存在鸿沟——信息可能不完整，表述可能有偏差，甚至问题本身可能不成立。如果你跳过思考直接给方案，很容易答非所问或遗漏关键点。这个 Skill 的价值在于：通过有纪律的分阶段思考，确保讨论的质量和深度。

## 模块化架构说明

本技能采用懒加载模块化架构，核心原则：

- **主干稳定**：本文件（SKILL.md）仅定义7阶段流程框架和阶段契约，不包含具体算法实现。
- **模块接口标准**：每个增强模块通过标准输入/输出与主干通信，输入输出格式见`references/enhancements/`下的模块说明。
- **版本锁定机制**：所有依赖均通过锁定版本而非分支追踪，具体见技能根目录的`version-lock.md`文件。
- **按需激活**：仅在满足特定条件时激活对应模块，不一次性全加载。
- **降级设计**：任何模块不可用时，主干自动切换至基础实现，不影响整体流程。
- **跨阶段基础设施层（思维审计层）**：除单阶段增强模块外，本技能还可在运行时接入「分步推理 / 思维记录」类 MCP 服务（例如 sequential-thinking），作为贯穿 7 阶段的思维审计基础设施——提供显式推理留痕、分支探索与跨会话持久化。该层**非单阶段模块**，按「能力特征动态探测」接入（详见「思维审计层集成」节），不硬编码任何服务名 / 工具名 / 路径；探测不可用或会话内未接入时，自动降级、完全不参与，deep-discuss 仍可独立运行。

## 触发条件

本技能在以下两类情形被激活（满足任一即触发，无需用户使用特定指令词）：

1. **用户显式请求深度讨论**：当用户明确说出「讨论一下 / 帮我分析 / 我遇到一个问题 / 你觉得怎么样 / 帮我想想 / 我在纠结」等短语时。
2. **问题具备深度讨论特征**：当用户描述问题现象、故障表现、技术困惑或方案选择困难，且需要结构化审查、根因分析或方案自检时（即使未使用上述显式短语）。

两类触发均面向"值得深入拆解的问题"，而非单轮事实问答；是否属于本技能范围，可对照下方「不适用场景」快速判别。

## 模块激活阈值

为避免模块激活的随意性，本技能对"复杂度 ≥ 中 / ≥ 高"给出客观判定清单。满足任一即触发对应等级（与上文触发条件叠加生效）：

- **复杂度 ≥ 中（激活 SilvereWolf /consult 模块，Phase 2）**：① 问题涉及多方立场、价值冲突或取舍权衡（如架构选型、资源分配）；② 表述中存在可识别的隐含假设（"应该""显然""大家都知道"等）；③ 信息不完整，存在 2 个以上关键 Unknowns 才能继续；④ 问题成立性本身存疑（可能是伪问题或归因错误）。
- **复杂度 ≥ 高（激活 kimasplund/premortem 模块，Phase 5-6）**：① 方案一旦执行，失败代价高（不可回退、影响外部用户、涉及资金/安全/合规）；② 存在不受控的外部依赖（第三方系统、他人配合、政策环境）；③ 方案涉及多个子系统或跨团队协作；④ 失败概率难以直接评估，需要系统性推演失败模式。
- **5Why 模块（jasminK11，Phase 3）**：在信息充足、需追根因时使用，不限复杂度等级；但当结论或假设关系到"≥ 高"决策时必激活。
- 若仍难以判定，遵循"宁可多激活、不可漏激活"原则：复杂度偏低但涉及不可逆后果时，也按"≥ 高"处理。

## 讨论流程（7 个阶段）

整个讨论像一次联合诊断，你在每个阶段都应该明确标注当前所处的阶段，让用户随时知道"我们在哪"。

### Phase 1：接收信息

用户提供问题描述，可能包含：
- 文字描述（现象、背景、上下文）
- 图片/截图（错误信息、界面状态、日志片段等）
- 用户自己的初步判断或猜测

你在此阶段的任务：**只接收，不急于分析**。先完整理解用户提供的全部信息，用自己的话简要复述关键点（不超过 3-5 句），确认理解无误。

如果用户的描述明显模糊或信息严重不足，可以在复述后提出 1-2 个最关键的澄清问题（不要一次抛出一堆问题，会打断用户的思路）。

**超大输入护栏**：若用户提供超大篇幅输入（例如超过约 2000 字、附带多份文档或长日志），不要逐字复述。先给出 3-5 句要点摘要，确认"我理解的核心诉求是……"，再进入 Phase 2；细节留待分析时按需回查，避免被海量信息淹没而遗漏主线。

---

### Phase 2：问题审查（Critical Thinking）

这是最核心的阶段。你需要对用户提供的信息做三层审查：

**第一层：问题是否成立？**
- 用户描述的现象是否真的构成一个"问题"？有没有可能这是正常行为？
- 用户的归因（如果有）是否合理？因果关系是否可靠？
- 是否存在前提假设需要验证？

**第二层：信息是否充足？**
- 现有信息是否足够支撑分析？缺什么关键信息？
- 哪些信息需要用户补充才能继续？（标注优先级：必须有 / 最好有 / 锦上添花）
- 如果信息不足，明确告诉用户"我目前能分析到什么程度，还差什么"

**第三层：是否有隐藏问题？**
- 基于已有信息，是否能发现用户没注意到的其他问题？
- 这些隐藏问题与用户提出的问题是否有关联？
- 有没有更深层的根因（root cause）藏在表面现象之下？

**增强：SilvereWolf /consult 模块（P1 级）**
> 方法论文档：`references/enhancements/silvereWolf-consult.md`；配套模板：`assets/templates/audit-template.md`
在问题复杂度 ≥ 中或信息不明确时（阈值见"模块激活阈值"），激活此模块：
1. 执行 Audit：分离 Facts / Assumptions / Unknowns（使用约定的审计模板）
2. 执行 Steelman 双方分析：生成最强支持案（Steelman Pro）和最强反对案（Steelman Con）
3. 将 Audit 结果和 Steelman 观点融入原有三层审查中：
   - 问题成立性参考 Steelman Con 的 Value flaw
   - 信息充足度参考 Unknowns 列表
   - 隐藏问题参假设中的 Load-bearing 项
4. 输出格式建议（灵活调整）：
   ```
   ## Phase 2：问题审查
   
   ### 问题成立性
   [你的判断 + 理由]
   
   ### 信息充足度
   [已有信息概述 / 缺失信息 / 对分析的影响]
   
   ### 潜在隐藏问题
   [发现的其他问题 / 或"暂未发现"]
   
   ### SilvereWolf 增强输出
   - Facts: [列表]
   - Assumptions: [列表，每项标注类型]
   - Unknowns: [列表]
   - Steelman Pro: [列表]
   - Steelman Con: [列表]
   - Value Flaw: [Steelman Con 视角下该问题/立场的成立性缺陷；未发现则填"暂未发现"]（问题成立性裁决依据，避免跳过"伪问题/归因错误"判定）
   - Verdict: [可行 / 有条件可行 / 不可行 / 需更多信息 之一]（Phase 2 阶段裁决结论，须明确落到上述四类之一；四类的行动映射见 `references/enhancements/silvereWolf-consult.md` 第 4 节「Verdict 与行动建议」：可行→进入 Phase 3；有条件可行→携带承重假设进入 Phase 3；不可行→反馈用户重新定义问题；需更多信息→暂停等待补充）
   ```
   如果在这个阶段发现需要补充信息，**暂停后续流程**，先等用户回复。不要带着不确定的假设往下走。

---

### Phase 3：深度分析

在 Phase 2 的基础上（信息已确认足够），展开全面、有深度的分析。

> **消费关系（上游→本阶段）**：本阶段直接承接 Phase 2（SilvereWolf 增强）产出的「待验证假设」列表，将其作为 5Why 逐级追问的种子；Phase 2 的 `Verdict` 是进入本阶段的门控，分四种情形：
> - `可行` → 直接进入 Phase 3；
> - `有条件可行` → 进入 Phase 3，但将「待验证假设」中的承重/隐性假设作为 5Why 优先种子（其成立性未验证前，结论置信度降一档标注）；
> - `不可行` → **不进入 Phase 3**，直接反馈用户，建议重新定义问题或调整讨论方向；
> - `需更多信息` → 已在 Phase 2 暂停，待用户补齐「必须有」未知项后重新审查，再据新 Verdict 决定进入与否。

这个阶段的核心要求：
- **全面**：考虑多种可能性，不要只盯着最显眼的那个
- **有深度**：追根溯源，不停留在表面现象，尽量抵达 root cause
- **有层次**：从不同角度或维度进行分析，而非线性罗列
- **诚实**：对不确定的部分明确标注置信度，不要装作什么都知道

**增强：jasminK11/claude-5-why-skill（P0 级）**
> 方法论文档：`references/enhancements/jasminK11-5why.md`；配套模板：`assets/templates/5why-template.md`
在信息充足后（阈值见"模块激活阈值"），激活此模块：
1. 对每个关键结论或假设，逐级追问 why（最多 5 次）
2. 使用对话式追问：每消息一个 why，编号 1st~5th
3. 每次追问后评估：
   * 若抵达根因 → 停止该链
   * 若进入死胡同 → 回退 1-2 层，改问其他角度
   * 若涉及复杂社会系统 → 标注为「待验证假设」
4. （可选）what-for 变体：若分析涉及目标设定，将「为什么」替换为「为了什么」，用于 OKR 式目标开发
5. 输出格式建议：
   ```
   ## Phase 3：深度分析
   
   ### 5Why 追问链（格式与 assets/templates/5why-template.md 表格结构一致，鼓励用表格）
   | 层级 | 问题 | 回答 | 评估 |
   |---|---|---|---|
   | 1st why | [问题] | [回答] | 抵达根因 / 死胡同→回退 / 待验证假设 |
   | 2nd why | [问题] | [回答] | 同上 |
   | 3rd why | [问题] | [回答] | 同上 |
   | 4th why | [问题] | [回答] | 同上 |
   | 5th why | [问题] | [回答] | 同上 |
   
   ### what-for 变体（如适用）
   为了什么：[目标导向反推结果]
   
   ### 结论
   - 根因：[明确的根因陈述]
   - 置信度：[高/中/低]（基于追问链的完整性和证据）
   - 未解决的假设：[列表，如有]
   ```
   分析完成后，用简洁的语言总结核心发现，等待用户反馈。用户可能会：
   - 补充新信息 → 回到 Phase 2 重新审查
   - 认可分析 → 进入 Phase 4
   - 提出不同看法 → 讨论分歧，调整分析

---

### Phase 4：方案设计

基于 Phase 2-3 的分析结论，开始设计解决方案。

方案设计原则：
- 优先给出 **2-3 个可选方案**，而非直接拍一个（除非问题简单到只有一个合理解法）
- 每个方案明确：做什么、为什么这样做、代价是什么、适用场景，以及**「前提假设」**（方案成立所依赖的条件，如技术可行性、资源到位、外部依赖可用、关键假设成立等；将作为 Phase 5 Premortem 推演「隐藏假设/失败模式」的直接输入，务必具体、可验证）
- 如果方案之间有 trade-off，明确对比
- 给出你的推荐方案及推荐理由，但把最终选择权留给用户

---

### Phase 5：方案自检（First Review）

在提出方案后，你主动对自己的方案做第一轮 review：

> **消费关系（上游→本阶段）**：本阶段直接承接 Phase 4 产出的「方案列表」（含各方案的「前提」字段，即方案的前提假设），将其作为 Premortem 失败模式推演的对象；Phase 4 各方案的「前提」直接映射为 Premortem 五段报告中 Autopsy 的「隐藏假设」输入。

检查清单：
- 是否有遗漏的场景或边界条件？
- 方案的前提假设是否都成立？
- 实施复杂度是否被低估了？
- 有没有更简单的替代方案被忽略了？
- 方案是否真的解决了 Phase 2 中识别出的所有问题（包括隐藏问题）？

**增强：kimasplund/premortem-skill（P0 级）**
> 方法论文档：`references/enhancements/kimasplund-premortem.md`；配套模板：`assets/templates/premortem-template.md`
在问题复杂度 ≥ 高时（阈值见"模块激活阈值"），激活此模块：
1. 执行 Proportionality Screen：评估每个方案的风险等级（L × I 矩阵），若所有方案均为低风险则跳过完整 premortem
2. Steelman First：对每个方案先写计划的最强支持案（Steelman），再执行攻击（找出最可能的失败模式）
3. 生成 12-15 个候选失败模式，按 failure-class 分类后削减至 ~7 个
4. 五段报告结构：
   - Autopsy：对每个失败模式做逆向解剖（事件链 / 隐藏假设 / 早期信号 / 概率伤害）
   - Verdict：战略综合分析（最可能失败 / 最危险失败 / 关键隐藏假设 / 不受控依赖）
   - Rebuild：修订计划（基于 Verdict 调整方案）
   - Adversary：对抗性审查（从对手视角再审修订后方案）
   - Tripwires：发布清单（≤8 项可验证的早期信号）
5. Decision Rule（IF/THEN 门控）：
   - IF 失败模式概率 > 40% → 暂停，重新设计
   - IF 失败模式概率 20-40% → 修订方案并增加缓解措施
   - IF 失败模式概率 < 20% → 进入 Phase 6
6. 输出格式建议：
   ```
   ## Phase 5：方案自检
   
   ### Proportionality Screen
   [风险等级评估结果]
   
   ### 五段报告
   - Autopsy：[事件链 / 隐藏假设 / 早期信号 / 概率伤害]
   - Verdict：[战略综合分析结果]
   - Rebuild：[修订计划]
   - Adversary：[对抗性审查结果]
   - Tripwires：[≤8 项可验证的早期信号]
   
   ### Decision Rule
   [IF/THEN 门控评估结果]
   
   ### 修订后方案
   [基于自检的方案修订]
   ```
   如果发现问题，直接在这个阶段修正，不需要等用户指出。

---

### Phase 6：最终确认（Final Review）

用户确认方案方向后，做最后一轮 review：

- 方案的完整性：所有步骤是否都覆盖到了？
- 风险预案：如果方案执行中出现意外，怎么办？
- 验证方式：方案执行后，怎么确认问题真的解决了？
- 还有没有什么补充建议？

**增强：kimasplund/premortem-skill 的 Calibration Review 和 Commitment 等级（P0 级）**
1. 校准概率份额（~5/~10/~15/~20/~30/~40 粗梯）
2. 评估 Commitment 等级（champion / endorse / accept / comply）
3. 执行 Decision Rule 最终裁决
4. 索取具体承诺：要求用户给出一项具体行动承诺（如「下周三前完成 X」）
5. 输出最终确认报告：
   ```
   ## Phase 6：最终确认
   
   ### 方案完整性
   [检查结果]
   
   ### 风险预案
   [应对意外情况的预案]
   
   ### 验证方式
   [方案执行后的确认方法]
   
   ### Calibration Review
   [概率份额校准结果]
   
   ### Commitment 等级
   [评估结果]
   
   ### 具体承诺
   [用户给出的具体行动承诺]
   
   ### 补充建议
   [其他建议]
   ```

---

### Phase 7：执行（可选）

只有在用户明确说"开始执行"、"动手吧"、"搞起来"等指令时才进入这个阶段。

执行时遵循：
- 按 Phase 4-6 确认的方案步骤逐步执行
- 每完成一个关键步骤，简要汇报进展
- 遇到意外情况时暂停，回到讨论模式
- **写操作授权门槛**：若执行涉及修改文件、运行命令、改动代码或系统配置，在动手前逐项列出将执行的具体操作（含目标路径/命令），并向用户取得显式授权（如"确认执行以上 N 项操作？"）后再进行；不默认代用户执行任何写操作

---

## 行为准则

### 阶段推进的节奏
- 不要跳阶段。即使问题看起来简单，也至少过一遍 Phase 1-4
- Phase 2 是最关键的质量门控，如果在这一步发现信息不足，宁可多问一轮也不要带着假设往下走
- Phase 5 和 6 可以根据问题复杂度适当合并，但不能完全跳过
- 如果用户中途提供了新信息，评估是否需要回到更早的 Phase 重新分析；回退深度按"新信息影响哪一阶段结论"决定：只影响方案细节→回 Phase 4，影响根因判断→回 Phase 2-3
- 若用户中途将话题转向一个与当前问题无关的全新问题时：先快速确认是要"暂停当前讨论、开启新讨论"还是"两件事并行"，不要混在同一轮里分析，避免两边都浅尝辄止；若并行，用编号分别跟踪（问题 A / 问题 B）

### 沟通风格
- 直接、坦诚，不要绕弯子。用户不玻璃心，更重视有效信息
- 如果用户的判断有误，直说，但要给出理由
- 对不确定的事情用概率/置信度表述，而非模棱两可的"可能"
- 输入语言以用户当前使用的语言为准：用户用中文就用中文讨论，用英文就用英文，不要擅自切换；若用户混用语种（如中文夹英文术语），保持同样混用风格，仅对必要的陌生术语给出中文释义
- 每次回复末尾简要标注当前阶段和下一步建议，保持讨论的节奏感

### 标注当前阶段
每次回复的开头用简洁的方式标注当前阶段，例如：
```
Phase 2 → 问题审查
```
或者在阶段转换时：
```
Phase 2 done → Phase 3：深度分析
```
这样用户随时知道讨论进行到哪里了。

## 思维审计层集成（运行时探测）

本技能可在运行时接入「分步推理 / 思维记录」类 MCP 服务，作为贯穿 7 阶段的**思维审计基础设施层**（而非单阶段增强模块）。其完整方法论文档与接口契约见 `references/enhancements/sequential-thinking-adapter.md`。核心纪律如下。

### 探测纪律（硬约束，不可省略、不可仅文档检查）

> ⚠️ **激活强制动作（位于 Phase 1 之前、不可省略、不可延后）**：本 Skill 每次被激活后，**必须实际调用** `sequential-thinking` 服务的真实接口（无论该服务是**直接连接到 Agent**，还是**经任意名称聚合器中转**，具体接入途径在运行时探测确定，**绝不硬编码 `dynamic-mcp` 或任何分组名**）做一次真实调用，以运行时结果判定服务可用性。**仅凭「适配层文档存在」「SKILL.md 提及该层」等静态事实不足以判定服务可用**——这正是 P3-03 类错判（把"文档存在"误当"服务可用"）的根因。确切调用参数、失败判定与"已探测"缓存约定见 `references/enhancements/sequential-thinking-adapter.md` §3.5「强制探活执行协议」。该强制动作以 `scripts/probe_seq_thinking.py` 作为激活探活器清单，激活后运行它即可获得需执行的调用与验收点。

1. **每次激活必实际调用探测、会话内只探一次**：进入 Phase 1 之前**真实执行**一次探测调用（运行时枚举全部可用 MCP 工具/服务、按能力特征匹配、再用真实入口实测 `process_thought`），**不得仅以文档/代码静态存在替代真实调用**；结果缓存至会话级变量，同一对话会话内后续激活（含用户切换新问题）直接复用，**不再重复探测**。新开会话或显式「重新探测」指令时才重新探测。
2. **按能力特征匹配，不按名称匹配**：运行时发现主机「全部可用 MCP 工具 / 服务」（须同时覆盖「直接连接暴露的工具」与「各聚合器分组内的工具」两类拓扑，聚合器名称任意、不得假设为特定名；枚举机制由主机决定，不得假设具体 API 名），比对适配层文档 §2 的「能力特征集合」（记录单条思维 + 生成摘要 + 清空历史 三件套即视为可适配）。具体服务名、工具名、接入路径一律以探测结果为准，本文件与适配层文档均**不硬编码**。
3. **记录探测结论**：探测后登记 `available` / `access_path`（直接连接 Agent，或经某聚合器中转，二者皆可）/ `tool_names`（真实调用名，直连时为 `mcp__<服务名>__<工具名>` 形式）/ `functions`（各工具功能）。
4. **不可用即静默降级**：`available=false` 时不打扰用户、不阻塞流程，全部阶段按基础模式运行（思维审计层完全不参与）；仅在用户需要时可于 Phase 1 开头以一行注明 `[思维审计层不可用，已切换至基础模式]`。

### 各阶段一句话映射（available=true 时生效；完整表格见适配层文档 §4）

- **Phase 1**：用「记录思维」工具写入信息摘要，锚定上下文。
- **Phase 2**：每条关键判断各记一条思维；对替代问题成立性用分支探索。
- **Phase 3**：5Why 每步记一条；死胡同用分支、早前结论用修订修正。
- **Phase 4**：每个候选方案记一条并打标签，便于回溯对比。
- **Phase 5**：每个失败模式记一条，标注被挑战假设 / 公理。
- **Phase 6**：用「生成摘要」工具产出结构化思维链路，作为汇报素材。
- **Phase 7 / 会话切换**：每步记留痕；切换问题前「清空历史」或「导出会话」保存，旧讨论可用「导入会话」续推。

> 激活阈值：复杂度 ≥ 中 且思维审计层可用时即启用（该层轻量、近乎零额外成本）；复杂度偏低但用户希望保留推理链路时，也可显式 opt-in。

## 版本锁定与模块依赖

本技能依赖以下外部模块，版本已锁定在 `version-lock.md`：
- jasminK11/claude-5-why-skill（用于 Phase 3 深度分析）
- kimasplund/premortem-skill（用于 Phase 5 方案自检和 Phase 6 最终确认）
- SilvereWolf/idea-friction-feasibility-auditor（用于 Phase 2 问题审查）

> **思维审计层（sequential-thinking 等 MCP 服务）不进入上述 commit 锁定表**：它是运行时按能力特征动态探测接入的 MCP 服务，非 git 上游模块，无固定版本可锁；其可用性、接入途径与工具名均在每次激活时探测确定（详见「思维审计层集成」节与 `references/enhancements/sequential-thinking-adapter.md`）。

**更新流程**：
1. 每季度检查上游仓库是否有新版本（仅读取 CHANGELOG 或标签，不自动拉取）
2. 仅当确认更新不破坏接口契约时，才考虑更新 `version-lock.md` 中的版本号
3. 更新前必须在隔离环境中验证新版本与主干的兼容性
4. 更新后运行回归测试（使用典型问题场景走查完整流程）

## 降级机制

任何依赖模块不可用时（网络、版本不兼容、接口 mismatch 等）：
- Phase 2：退化至原有三层审查（问题成立性/信息充足度/隐藏问题）
- Phase 3：退化至多维度脑暴雨式分析（考虑技术/流程/风险/成本等维度）
- Phase 5：退化至原有检查清单（5项）
- Phase 6：退化至原有四项检查（完整性/风险预案/验证方式/补充建议）
- **思维审计层（MCP 服务）不可用时**：默认无任何额外提示、不阻塞流程，所有阶段按基础模式运行（无显式思维留痕 / 分支 / 跨会话持久化）；如需告知用户，可在 Phase 1 开头注明 `[思维审计层不可用，已切换至基础模式]`。
- 在阶段输出中明确标注：`[模块名称] 暂不可用，已切换至基础模式`
- 不中断整个讨论流程，仅影响该阶段的深度程度

### 加载时启动自检（必做）

每次激活本技能时，**先完成「思维审计层集成」节的激活强制探测（运行时枚举 + 真实调用 `process_thought`，见该节），再执行下方自检**，避免"静默降级"导致用户误以为模块已生效。技能根目录附带 `scripts/selfcheck.py`，可运行 `python scripts/selfcheck.py`（或 `uv run python scripts/selfcheck.py`）自动完成下方一致性核对（含第 4 项强制探活机制检查）；手动核对时遵循下方清单：

> **前置：思维审计层探测（每会话一次）**：在自检之前或紧邻，先执行「思维审计层集成」节的探测（会话内仅一次，结果缓存复用）。探测不可用时不计入自检失败，仅按降级纪律处理。

1. **模块存在性**：确认 `references/enhancements/` 下三个模块文件（jasminK11-5why.md、kimasplund-premortem.md、silvereWolf-consult.md）均存在且非空。
2. **版本标记一致性**：逐项核对以下三处 commit 必须互证一致，任一不匹配即视为版本偏离：
   - **模块首行 ↔ 锁表**：读取三个模块文件首行的 `<!-- 版本锁定: commit:... -->`，确认其 commit 出现在 `version-lock.md` 的锁定表中；
   - **更新记录 ↔ 首行**：若模块文件「更新记录」小节引用了上游 commit（形如 `基于 <repo>@<commit>`），其 `<commit>` 必须与文件首行的 commit 完全一致，禁止遗留占位符（如 `<真实commit>`）；
   - **主干锁 ↔ main HEAD**：读取 `version-lock.md` 中「主干」行的 commit，须等于当前仓库 `git rev-parse --short main` 的值，或为其已合入 main 的祖先提交（仅当指向未合入 main 的悬空 commit 才视为版本偏离）。
3. **处置**：若自检发现缺失或版本偏离，在 Phase 1 开头明确向用户提示"检测到 [模块名] 不可用/版本偏离，已切换至基础模式"，而非等到对应阶段才悄悄降级；若无异常则无需提示，不打扰用户。

## 示例

### 典型场景 1：技术故障排查
**用户**：「我的网站在 Safari 上打开慢，但 Chrome 正常，不知道是不是 CSS 问题」
**流程**：Phase 1 收集现象/浏览器/环境 → Phase 2 审查问题成立性（是否真为 CSS）、信息充足度（需网络面板/性能分析）、隐藏问题（可能是字体加载/渲染阻塞） → 如信息不足暂停等待补充 → Phase 3 激活 5Why 追问根因 → Phase 4 给出 2-3 个方案（字体预加载/关键 CSS 内联/字体回退策略） → Phase 5 Premortem 评估方案风险 → Phase 6 最终确认并索取承诺。

### 典型场景 2：架构决策困境
**用户**：「我们要开发新功能，该用微服务还是单体架构？团队 8 人，预计维护 3 年」
**流程**：Phase 1 接收团队规模/维护周期/业务边界 → Phase 2 审查：是否真需要微服务（Value Flaw：过度设计）、信息充足度（需业务边界清晰度/运维能力/部署基建）、隐藏问题（认知负载/分布式事务/测试复杂度） → Phase 3 5Why 分析核心驱动力 → Phase 4 方案：单体+模块化/微服务/模块化单体+未来拆分预留 → Phase 5 Premortem 评估各方案失败模式 → Phase 6 Calibration+Commitment。

### 典型场景 3：问题澄清不足
**用户**：「用户说 APP 崩溃了，但没给日志，我也没法复现」
**流程**：Phase 1 收集仅有信息 → Phase 2 审查：信息严重不足，Unknowns「必须有」：崩溃日志/复现步骤/设备型号/版本号 → Verdict：「需更多信息」→ **暂停流程**，明确列出必须补齐的信息等用户回复。