菜单
当用户提到'洞察'、'insight'、'分析问题'、'萃取'、'萃取洞察'、'根因分析'、'问题诊断'、'数据分析'、'找出原因'、'为什么会这样'、'优化机会'、'异常分析'时，必须使用此技能。提供系统化的数据分析与问题诊断能力：数据采集→趋势分析→根因分析→异常检测→建议生成。不要手动进行无结构的分析——本Skill封装了5-Whys根因法和四步分析流程。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
当用户提到'CI检查'、'提交前检查'、'综合检查'、'ci-check'、'流水线检查'、'提交门禁'、'全量检查'、'跑一下CI'、'pre-commit'、'预检'、'检查所有'时，必须使用此技能。提供项目CI/CD综合检查能力，按标准流水线顺序执行10项核心检查：仓库合规→链接检查→Spec一致性→模式成熟度→文档生成→重复代码检测→阶段守卫日志→SG仪表盘→文件放置校验→.temp生命周期检查。提交前必跑，确保代码符合项目规范。不要手动逐个执行检查脚本——本Skill已按正确顺序编排，并处理了跨平台兼容（Windows用.ps1，Linux/Mac用.sh）。
当用户提到'链接检查'、'检查链接'、'断链'、'链接修复'、'fix links'、'check links'、'验证链接'、'死链'、'链接有效性'、'提交前检查'时，必须使用此技能。提供Markdown链接有效性检查与自动修复能力：本地文件引用验证、外部URL可达性检测、file:///绝对路径转相对路径、相对路径层级自动校正。不要手动查找断链——本Skill封装了缓存机制、并发检测、自动修复和dry-run预览，是提交前质量门禁的核心工具。
当用户提到'原子化收尾'、'finalize atomization'、'文档拆分完成'、'文件移动后处理'、'断链修复导航更新'、'一键收尾'、'重构完成后整理'时，必须使用此技能。原子化/文件移动/目录重构后的一键收尾工具：自动断链修复→导航表更新→Spec看板刷新→验证摘要。不要手动逐个执行后处理步骤——本Skill封装了正确的执行顺序和dry-run预览机制，是文档原子化工作流的标准最后一步。
当用户提到'萃取'、'extraction'、'模式沉淀'、'萃取模式'、'模式入库'、'沉淀为模式'、'可复用模式'、'更新模式库'、'生成模式文档'时，必须使用此技能。提供标准化的模式萃取流程：案例收集→本质抽象→结构化模板→反模式提炼→迁移验证→入库。不要手动组织萃取流程——本Skill封装了六步标准萃取法、反模式对等原则和可迁移性验证。替代旧的pattern-extraction-cmd（v1.0.0）。
当用户提到'知识图谱'、'knowledge graph'、'概念关系可视化'、'交互式知识图谱'、'节点关系网络'、'生成知识图谱'、'可视化知识库'、'概念网络'、'knowledge graph config'时，必须使用此技能。从结构化Markdown文档集（术语表/文档索引/时间线等）自动提取节点和关系，生成交互式vis-network HTML知识图谱。支持TOML声明式配置和Python API两种方式，内置节点去重、孤立节点检测、类型筛选、可信度分级显示。不要手动拼接vis-network代码——本Skill封装了表格解析、关系构建、HTML模板渲染和自包含输出，确保产出质量可预测。
当用户提到'mermaid'、'流程图'、'时序图'、'状态图'、'画个图'、'图表'、'架构图'、'思维导图'、'ER图'、'类图'、'甘特图'、'饼图'、'UML图'、'可视化流程'、'画流程图'、'mermaid图'、'可视化'、'流程可视化'时，必须使用此技能。提供标准化的Mermaid图表创建、检查、修复流程，引导完成从设计→编码→检查→修复→验证→交付的完整闭环。不要手写Mermaid代码绕过本Skill——本Skill封装了安全编码六规则、模板选择、自动检查修复流程，确保图表质量可预测。
| name | insight-cmd |
| version | 1.3.0 |
| description | 当用户提到'洞察'、'insight'、'分析问题'、'萃取'、'萃取洞察'、'根因分析'、'问题诊断'、'数据分析'、'找出原因'、'为什么会这样'、'优化机会'、'异常分析'时，必须使用此技能。提供系统化的数据分析与问题诊断能力：数据采集→趋势分析→根因分析→异常检测→建议生成。不要手动进行无结构的分析——本Skill封装了5-Whys根因法和四步分析流程。 |
| argument-hint | <分析目标：system/task/process/user> [关注指标] |
| user-invocable | true |
| paths | [".agents/commands/insight.md","docs/retrospective/patterns/methodology-patterns/retrospective-knowledge/","rules/cmd-log-specification.md"] |
| title | Insight 洞察命令 Skill |
| x-toml-ref | ../../../.meta/toml/.agents/skills/insight-cmd/SKILL.toml |
⚠️ 本Skill是命令入口门面（L1索引层），遵循渐进式披露三层架构：
- L0：.agents/ONBOARDING.md（入口速查）
- L1：本文件（<500行，触发词+决策树+核心步骤+安全清单）
- L2：commands/insight.md（完整流程）+ cmd-log-specification.md（日志规范）
insight-cmd
提供系统化数据分析与问题诊断能力，完成"采集→分析→诊断→建议"闭环：
| 方案 | 推荐场景 | 优势 |
|---|---|---|
| 数据驱动分析 | ⭐ 指标异常、效率下降、周期性分析 | 基于量化数据，客观可验证 |
| 根因诊断 | ⭐ 问题排查、故障分析、缺陷定位 | 5-Whys追根究底，找到根本原因 |
| 萃取洞察 | ⭐ 复盘中提炼可复用经验 | 从具体事件抽象为可迁移模式 |
核心功能：采集运行数据→分析趋势变化→定位根本原因→检测异常模式→生成改进建议。
为什么用本Skill而非随意分析？ 手动分析容易停留在表面现象（"出了个bug"）而不去找根因（"为什么这个bug会出现"）；本Skill强制使用5-Whys方法和四步分析流程，确保分析深度足够，结论可行动。
当用户提到以下任何内容时触发：
关于触发：即使没有明确说"用insight命令"，只要涉及问题诊断、原因追查、数据分析，就应该使用本Skill。如果是外部产品/竞品研究的信息采集分析，必须结合三角验证法SOP。
需要执行分析？
├─ 有明确的量化指标/数据？ → 数据驱动分析（采集→趋势→对比→结论）
├─ 有具体问题/故障需要定位原因？ → 根因诊断（5-Whys方法）
├─ 从执行过程中提炼经验模式？ → 萃取洞察（具体→抽象→可复用）
├─ 需要完整的项目/阶段复盘？ → 使用 retrospective-cmd Skill（本Skill作为其中步骤3）
└─ 需要导出分析报告？ → 分析完成后使用 export-report-cmd
决策前输出CMD_START日志（session前缀 insgt-YYYYMMDD-<topic>）：
[CMD-LOG] | level=INFO | cmd=insight | step=S0 | event=CMD_START | session=insgt-... | msg=开始洞察分析：<简述> | ctx={"analysis_target":"system/task/process/user","focus_metrics":"..."}
为什么决策前必须记录日志？ 洞察分析涉及多步推理（采集→趋势→根因→异常→建议），分析目标判断错误会导致分析方向偏航，CMD_START记录目标和关注指标便于回溯分析起点。
步骤1：读取 [commands/insight.md](../../commands/insight.md) 了解完整四步流程
步骤2：明确分析目标（system/task/process/user）和关注指标
步骤3：按四步法执行：
- 步骤1 数据采集（运行指标、执行日志、用户反馈、变更记录）
- 步骤2 趋势分析（时间序列、异常拐点、基线对比、变化率）
- 步骤3 根因分析（5-Whys追问、因果链、瓶颈识别、影响评估）
- 步骤4 异常检测（异常分类、阈值判定、关联分析）
- 步骤5 建议生成（可行动建议、优先级排序、预期效果）
步骤4：建议形成行动项（高/中/低优先级+验收标准）
步骤5：可复用洞察沉淀至 docs/retrospective/patterns/
完整RACI矩阵、数据采集清单、5-Whys模板、三角验证法SOP见L2文档 commands/insight.md。分析外部产品/技术/竞品时参考三角验证法。
为什么必须区分"相关性"与"因果性"？ 数据分析中最危险的陷阱是把时间上先后发生或统计上相关的两件事误判为因果关系（如"服务器重启后响应变慢"不等于重启导致变慢）。错误的因果推断会产生误导性建议，比没有结论更有害——它会引导团队在错误的方向上投入资源。必须通过对照实验、机制解释或多源交叉验证来确认因果关系。
为什么根因分析必须追问至少3层"为什么"？ 单层"为什么"只能得到表面原因（如"服务挂了因为进程崩溃"），双层只能得到直接原因（"进程崩溃因为内存溢出"），三层及以上才能触达根本原因（"内存溢出因为新上线的缓存策略没有设置过期时间，且代码评审时未检查资源释放逻辑"）。追问层数不足会导致"修复症状而非病因"——重启服务能暂时恢复，但同样的问题会再次发生。
执行洞察命令集时，必须按 CMD-LOG规范 输出结构化日志：
cmd=insight，session前缀 insgt-YYYYMMDD-<topic>DATA_QUALITY_LOW、ANOMALY_DETECTED、ROOT_CAUSE_FOUND、CAUSALITY_UNCERTAIN、ANOMALY_CLASSIFIED、RECOMMENDATION完整字段说明、事件表格、日志示例见L2文档 cmd-log-specification.md §7.2。
| 问题场景 | 处理方式 |
|---|---|
| 数据不足无法分析 | 明确标注"数据不足"，列出需要补充什么数据，基于现有信息给出初步判断 |
| 多个可能原因 | 列出所有可能原因，按可能性排序，说明验证方法 |
| 问题无法复现 | 记录已知条件，给出监控建议，标注为"待观察" |
| 分析范围过大 | 缩小范围，优先分析影响最大的问题，标注范围边界 |
为什么需要Gotchas？ 错误处理记录"已知错误码及修复方式"，Gotchas记录"容易踩的坑、反直觉行为、容易被忽略的约束条件"——不会产生明确错误码但会导致结果不符合预期的隐性陷阱。
| 参考 | 层级 | 路径 | 何时查阅 |
|---|---|---|---|
| 完整命令文档（RACI/参数/模板） | L2 | commands/insight.md | 每次使用必读 |
| CMD-LOG日志规范 | L2 | cmd-log-specification.md | 日志格式、事件定义、解析方法 |
| 根因诊断模式 | L2 | root-cause-diagnosis.md | 根因分析时 |
| 洞察萃取漏斗 | L2 | extraction-four-layer-funnel.md | 萃取洞察时 |
| 洞察冰山模型 | L2 | insight-iceberg-model.md | 理解洞察层次 |
| 三源验证法 | L2 | triangular-source-verification.md | 外部产品研究时 |