当 launch review…

对单个功能或产品领域做定性深度风险评估，框定可能出错什么、概率、严重性、缓解与选项，供有权限者决策。

适用场景

解决思路

1. 检查 practice-level CLAUDE.md 中的 `## Matter workspaces`；若 `Enabled` 为 `✗`（in-house 用户默认），跳过 matter 机制，使用 practice-level 上下文。
2. 若 matter 启用且没有 active matter，询问：Which matter is this for? Run `/product-legal:matter-workspace switch <slug>` or say `practice-level`。
3. 加载 active matter 的 `matter.md`，获取 matter 特定上下文和覆盖。
4. 将输出写入 `~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/`。
5. 除非 `Cross-matter context` 为 `on`，不要读取另一个 matter 的文件。
6. 用一段话写明正在评估什么：功能做什么、新在哪里、为什么升级为完整评估。
7. 列出 2-5 个不同风险，不要列 15 个；每个风险按模板填写。
8. 对每个风险写具体场景：不要写“data breach”，而写“recommendation algo 因 X 将用户的敏感类别兴趣暴露给不应看到的人”。
9. 写明谁会受伤：用户、公司、第三方，具体说明。
10. 给出发生可能性：低/中/高，并附理由，如“低——需要 X 和 Y 同时失败”，不要只凭感觉。
11. 给出若发生有多严重：低/中/高，并附理由，如“高——监管罚款 + 集体诉讼风险 + 媒体”对比“低——一条愤怒推文，无实际伤害”。
12. 写明现有缓解措施：已经降低可能性或影响的做法。
13. 写明缺口：缺失什么。
14. 写明剩余风险：现有缓解后是否可接受，是否需要更多措施。
15. 若监管机构正在主动关注该领域，加入监管环境：哪个监管机构、近期说了或做了什么、该功能在他们看来如何、希望他们从我们这里还是从头条得知。
16. 若有先例，加入：其他公司是否做过类似事情、结果如何；没坏事则有用但非决定性；坏事则分析他们情况有何不同、是否适用；不要过度重视先例。
17. 提出 2-3 条现实路径，用表格列 Option、Description、Risk reduction、Cost；典型包括 A: Ship as designed、B: Ship with [mitigation]、C: Don't ship [component]。
18. 给出建议：选一个选项，解释为什么，承认权衡；使用模板 Recommended: Option [X]；说明剩余风险、为何可接受、谁接受。
19. 若答案不是我能决定，写明谁决定、他们需要知道什么。
20. 定稿前做校准检查：对照 `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Risk calibration；判断是否针对本公司校准，而非通用；同一风险在受同意令公司可能是 High、在另一公司可能是 Medium；反映实际监管姿态、诉讼历史和风险偏好。
21. 若由 AI 功能触发，并行或紧接着运行 `/ai-governance-legal:aia-generation [feature]`；FRA 是 product-legal 决策文档，AIA 是治理记录。
22. 若涉及新数据收集或处理，运行 `/privacy-legal:pia-generation [feature]`；标记与 FRA 风险部分的重叠以避免重复，但两份文档都需存在。
23. 若使用新的 AI 供应商，运行 `/ai-governance-legal:vendor-ai-review [vendor agreement]`，如果 launch review 中尚未做。
24. 输出独立文档，2-4 页；从 `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` 的 `## Outputs` 前置 work-product header（按用户角色不同）。
25. 不要做成 slide deck 或 memo to file；做成决策文档，供人阅读后决定。
26. 保存到 `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Launch review process 指定的 review docs 位置。
27. 若文档要与特权圈外共享（如贴到广泛共享 ticket），仅对该外部副本删除 work-product header，特权原件保留在 matter file。
28. 若评估引用案例、法规、规章或执法行动，特别是 Regulatory landscape 或 Precedent 部分，在给决策者前用法律研究工具（Westlaw、CourtListener 或 firm research platform）核实每个引文的准确性、good law status 和当前执法姿态；AI 生成引文未经验证，捏造执法行动比没有评估更糟。
29. 若对配置的法律研究工具查询返回很少或无结果，报告找到的内容并停止；不要未经询问从 web search 或模型知识填补；提供选项：(1) broaden the search query，(2) try a different research tool，(3) search the web — 结果标记 `[web search — verify]` 并依赖前核对发布机构，(4) flag as unverified and stop；由律师决定是否接受低置信来源。
30. 对 Regulatory landscape 和 Precedent 的每个引文打来源标签：`[Westlaw]`、`[CourtListener]`、`[regulator site]` 或法律研究连接器的 MCP 工具名；`[web search — verify]`；`[model knowledge — verify]`；`[user provided]`；verify 标签风险更高应先检查；不要删除或合并标签。
31. 以 CLAUDE.md `## Outputs` 的下一步决策树收尾；根据本技能产出定制选项；五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点不是锁定；决策树是输出，律师选择。
32. 不要评估每个功能；大多数功能只做 launch review。
33. 不要替人做决定；只框定决定，由有权限的人选选项。
34. 不要做定量风险建模；若公司有带数字的正式风险框架则使用它，本技能是定性。

适用边界 · 注意事项

• 若 launch review 未发现不在 calibration table 的新颖模式、未命中 usually blocks 类别、GC 或领导未要求、该领域无主动监管关注、外部无人担忧，则 launch review 已足够，不要为文书而文书。
• 不要用于评估每个功能；大多数功能只做 launch review 即可。
• 不适合替代有权限者的决定，也不适合做定量风险建模；若公司有正式数字风险框架，应使用该框架。