菜单
当用户提到'复盘'、'retrospective'、'回顾'、'总结经验'、'做个复盘'、'项目总结'、'阶段回顾'、'里程碑总结'、'事后分析'、'经验总结'时，必须使用此技能。提供标准化的项目复盘流程：收集事实→分析过程→提炼洞察→生成报告，引导完成完整的复盘闭环。不要手动组织复盘流程——本Skill已封装四步标准流程和产出物规范。
用 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 | retrospective-cmd |
| version | 1.5.0 |
| description | 当用户提到'复盘'、'retrospective'、'回顾'、'总结经验'、'做个复盘'、'项目总结'、'阶段回顾'、'里程碑总结'、'事后分析'、'经验总结'时，必须使用此技能。提供标准化的项目复盘流程：收集事实→分析过程→提炼洞察→生成报告，引导完成完整的复盘闭环。不要手动组织复盘流程——本Skill已封装四步标准流程和产出物规范。 |
| argument-hint | <复盘范围：project/iteration/task/incident> [重点领域] |
| user-invocable | true |
| paths | [".agents/commands/retrospective.md","docs/retrospective/reports/","docs/retrospective/patterns/","rules/cmd-log-specification.md"] |
| title | Retrospective 复盘命令 Skill |
| x-toml-ref | ../../../.meta/toml/.agents/skills/retrospective-cmd/SKILL.toml |
⚠️ 本Skill是命令入口门面（L1索引层），遵循渐进式披露三层架构：
- L0：.agents/ONBOARDING.md（入口速查）
- L1：本文件（<500行，触发词+决策树+核心步骤+安全清单）
- L2：commands/retrospective.md（完整流程）+ cmd-log-specification.md（日志规范）
retrospective-cmd
提供标准化项目复盘执行能力，引导完成"事实→分析→洞察→报告"四步闭环：
| 方案 | 推荐场景 | 优势 |
|---|---|---|
| 标准复盘 | ⭐ 项目/迭代里程碑完成后 | 完整四步流程，产出结构化复盘报告 |
| 轻量复盘 | ⭐ 单个任务/事件快速回顾 | 快速提炼经验，不做深入根因分析 |
| 故障复盘 | ⭐ 重大问题/故障发生后 | 重点根因分析和改进措施 |
核心功能：引导复盘流程 → 萃取可复用洞察 → 生成带优先级的改进建议 → 沉淀知识至模式库。
为什么用本Skill而非手动组织？ 手动复盘容易遗漏关键步骤（如跳过事实收集直接分析、或没有将洞察沉淀为可复用模式）；本Skill封装了经过多次验证的四步法模型和产出物规范，确保复盘质量可预测。
当用户提到以下任何内容时触发：
关于触发：即使没有明确说"用retrospective命令"，只要涉及项目/任务/事件的经验总结和回顾，就应该使用本Skill。复盘是知识沉淀的核心入口，不要跳过。
需要执行复盘？
├─ 项目/迭代里程碑完成？ → 标准复盘（完整四步流程）
├─ 单个任务/小事件快速总结？ → 轻量复盘（聚焦关键经验）
├─ 故障/重大问题发生后？ → 故障复盘（重点根因分析+改进措施）
└─ 需要从对话中直接萃取洞察（不做完整复盘流程）？ → 使用 insight-cmd Skill
决策前输出CMD_START日志（session前缀 retro-YYYYMMDD-<topic>）：
[CMD-LOG] | level=INFO | cmd=retrospective | step=S0 | event=CMD_START | session=retro-... | msg=开始项目复盘：<简述> | ctx={"retro_topic":"...","retro_type":"project/milestone/incident"}
为什么决策前必须记录日志？ 复盘涉及多步骤流程（事实收集→过程分析→洞察提炼→报告生成），复盘类型判断错误会选择错误模板，CMD_START记录主题和类型便于回溯。
与其他Skill的关系：
export-report-cmd 导出正式报告insight-cmdatomization-cmd 原子化拆分步骤1：读取 [commands/retrospective.md](../../commands/retrospective.md) 了解完整四步流程
步骤2：明确复盘范围（project/iteration/task/incident）和时间范围
步骤3：按四步法执行：
- S1 收集事实数据（时间线、关键事件、产出物）
- S2 分析过程（成功因素、失败原因、瓶颈）
- S3 提炼洞察（可复用模式、系统性问题、改进建议）
- S4 生成报告（结构化复盘报告，含行动项）
- S5 归档沉淀（模式入库、索引更新）
步骤4：需要导出时使用 export-report-cmd
步骤5：可复用模式沉淀至 docs/retrospective/patterns/
完整RACI矩阵、输入参数规范、约束条件见L2文档 commands/retrospective.md。
为什么必须区分"事实"与"判断"？ 事实阶段混入主观判断是复盘最常见的失败模式——一旦带着结论去收集事实，就会选择性忽略矛盾证据，最终得到"验证了偏见"的伪复盘。严格分离两阶段（S1只记录发生了什么，S2才分析为什么），才能确保洞察建立在客观基础上而非事后合理化。
file:/// 绝对路径、三查章节完整性）——适用于分析类任务或含数据引用的复盘报告为什么行动项必须有明确的验收标准？ 没有验收标准的行动项（如"优化性能"、"加强测试"）是无法追踪完成状态的——三个月后回头看，没人知道"做了"还是"没做"、"做好了"还是"做了一半"。验收标准是行动项的"完成定义"（Definition of Done），它把模糊的改进意图转化为可验证的具体结果（如"首页加载时间从3.2s降至1.5s以内，通过Lighthouse验证"），确保复盘产出的改进真正落地。
为什么复盘报告需要数据验证三查法？ 复盘报告中引用的关键数据（如执行时间、产出物行数、验证匹配数等）如果错误，会导致后续决策基于错误信息——例如把"104 处匹配"写成"10 处"，会让读者误以为数据验证不充分。
file:///绝对路径违反 SpecWeave 文档规范（必须使用相对路径），会导致链接检查失败。章节缺失会让复盘报告结构不完整，遗漏关键分析维度。三查法通过 Grep 工具自动化验证，将"人工目检"升级为"工具验证"，确保数据准确性、规范合规性和结构完整性。详见 external-article-deep-analysis-workflow.md 阶段 4。
执行复盘命令集时，必须按 CMD-LOG规范 输出结构化日志：
cmd=retrospective，session前缀 retr-YYYYMMDD-<topic>KEY_FINDING、PATTERN_EXTRACTED、ACTION_ITEM、REPORT_GENERATED、DATA_INSUFFICIENT、PATTERN_SKIPPED完整字段说明、事件表格、日志示例见L2文档 cmd-log-specification.md §7.1。
为什么需要Gotchas？ 错误处理记录"已知错误码及修复方式"，Gotchas记录"容易踩的坑、反直觉行为、容易被忽略的约束条件"——不会产生明确错误码但会导致结果不符合预期的隐性陷阱。
docs/retrospective/reports/ 下对应的分类子目录中（如 project-reports/、iteration-reports/、incident-reports/），不要随意散落在其他目录——错误的目录位置会导致docgen无法索引，导航表中找不到报告。pattern-extraction-cmd 沉淀到模式库（docs/retrospective/patterns/），而不是只停留在单次复盘报告中——否则经验无法复用，下次遇到同样问题还会踩同样的坑。| 参考 | 层级 | 路径 | 何时查阅 |
|---|---|---|---|
| 完整命令文档（RACI/参数/约束） | L2 | commands/retrospective.md | 每次使用必读 |
| CMD-LOG日志规范 | L2 | cmd-log-specification.md | 日志格式、事件定义、解析方法 |
| 四步法模型 | L2 | retrospective-four-step-method.md | 理解核心方法论 |
| 洞察萃取漏斗 | L2 | extraction-four-layer-funnel.md | 步骤3提炼洞察时 |
| 三源验证法 | L2 | triangular-source-verification.md | 外部竞品/技术复盘时 |
| 外部文章深度分析端到端工作流 | L2 | external-article-deep-analysis-workflow.md | 分析类任务复盘时（含数据验证三查法） |
| 复盘报告目录 | L2 | docs/retrospective/reports/ | 存放产出物 |