launch-review

/launch-review

1. 加载 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → 框架 + 校准。如果存在占位符，则停止。
2. 获取 PRD + 相关文档。如果已连接跟踪器，则拉取工单及评论。
3. 使用下方工作流逐一检查框架中的所有类别。
4. 根据表格校准每项发现。新颖问题 = 明确标记。
5. 按内部格式输出审查备忘录。如果已连接跟踪器，则将摘要发布到工单。
6. 移交：如果涉及大量营销内容，则移交给 marketing-claims-review；如果某项发现需要深入分析，则移交给 feature-risk-assessment。

/product-legal:launch-review PROJ-1234

---

事项背景

事项背景。 检查实践级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部用户的默认值），则跳过本段其余内容——技能使用实践级背景，事项管理机制不可见。如果已启用且没有当前事项，则询问：“这是哪个事项？运行 /product-legal:matter-workspace switch <slug>，或输入 practice-level。”加载当前事项的 matter.md，以获取事项专属背景和覆盖项。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则绝不读取其他事项的文件。

---

目标位置检查

输出前，先检查内容将发送到哪里。如果用户指定了目标位置（频道、分发列表、交易对方、“所有人”），询问该位置是否属于特权保护范围。公开频道、全公司列表、交易对方／对方律师、供应商，以及客户（涉及工作成果时）都会使保护失效。如果目标位置看起来不在保护范围内，请指出这一点，并提供以下选项：(a) 仅供法务使用的特权版本，(b) 供更广泛频道使用的净化版本，或 (c) 两者兼备——不要默默加上特权标头，然后又帮忙将内容粘贴到标头无法提供保护的地方。请参阅此插件 CLAUDE.md 中的规范内容 ## Shared guardrails → Destination check。

目的

阅读 PRD，检查此团队框架中的所有类别，并根据此处实际会阻止发布的事项进行校准（参见 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md），然后按内部格式输出审查意见。目标是让 PM 明确了解发布前必须完成哪些工作。

加载校准信息

阅读 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md：

• ## Review framework — 要检查的类别
• ## Risk calibration — 在这家公司哪些事项会阻止发布，哪些仅供参考
• ## Launch review process — 输出格式
• ## Escalation — 何时向上升级

校准表正是此技能区别于通用清单的关键。如果表格写着“收集新数据 → 进行 PIA，1–2 天内发布”，就不要写“这可能需要完整的 DPIA 和监管咨询”。按照团队的实际做法进行校准。

工作流

第 1 步：获取输入

• PRD — 来自文件、Drive 或发布跟踪器工单
• 规范／设计文档 — 如有单独文档
• 营销计划 — 如有（大量营销内容应移交给 marketing-claims-review）
• 发布日期 — 用于校准紧迫程度
• 发布跟踪器工单 — 如果已连接，则拉取工单以获取背景和评论

如果已连接 Jira/Linear MCP，则拉取工单历史记录——早先的评论中往往包含 PRD 未记录的背景信息。

步骤 2：了解要发布什么

在开始检查清单之前，请用通俗语言回答：

• 这个东西有什么作用？
• 谁会使用它——现有用户、新用户，还是新的用户群体？
• 有哪些新内容？哪些只是对已审查内容的扩展？
• 是否涉及新数据、新供应商、新声明或新司法管辖区？

AI 检测——在检查框架之前进行。 检查此次发布是否以任何形式使用 AI：第三方模型、内部构建的模型、AI 驱动的供应商功能、自动评分或分类、生成式内容、推荐、预测。即使 PRD 没有将其标记为“AI”，也要留意这一点——“智能”“自动化”“个性化”“生成”“建议”等词都可能是线索。

如果检测到 AI 组件 → 将其标记出来，然后在检查框架的同时运行 /ai-governance-legal:use-case-triage [feature]。下文的类别 8 会处理具体细节；此标记可确保即使 PRD 含糊不清，也不会漏掉这一项。

步骤 3：检查框架

针对 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Review framework 中的每个类别进行检查。如果团队没有自己的框架，请使用下方的 8 类默认框架。这些类别是稳定的分类概念；在每个类别中，根据产品的行业、受众和司法管辖区研究适用的监管制度，然后再评估严重程度。在一个司法管辖区或行业中需要阻止的事项，在另一个地方可能只是常规事项——~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md 记录了团队的评估标准。

#	类别	关键问题	可自动跳过的情况
1	合同承诺	这是否与面向客户的任何承诺（ToS、SLA、营销内容）相冲突？	没有面向客户的变更
2	隐私	是否会收集新数据、用于新目的或与他方共享？	没有数据变更
3	安全	是否会新增攻击面、静态存储的数据或访问模式？	仅涉及 UI，后端没有变更
4	知识产权	是否涉及第三方代码或内容？是否需要检查开源许可证？输出内容是否可能侵权？	没有新增依赖项，也没有用户生成内容
5	第三方	是否有新的供应商、合作伙伴或集成？	没有新的外部方
6	监管	是否涉及受监管的行业、受监管的受众或司法管辖区？研究适用的监管制度。	与现有产品的用户、行业和司法管辖区相同

不得静默补充。 如果针对某项制度、执法先例或监管机构指引的研究查询，在已配置的法律研究工具（Westlaw、CourtListener、监管机构网站或律所平台）中返回的结果很少或没有结果，请报告已找到的内容并停止。未经询问，不得通过网页搜索或模型知识填补空缺。请说：“搜索从 [tool] 返回了 [N] 条结果。[regime / topic] 的覆盖似乎有限。可选方案：(1) 扩大搜索查询范围；(2) 尝试其他研究工具；(3) 搜索网页——结果将标记为 [web search — verify]，依赖这些结果前应对照发布机构核实；或 (4) 标记为未经核实并停止。您希望怎么做？”由律师决定是否接受可信度较低的来源。

来源归属分级。 在审查中为每条引用标注来源。对于模型知识中的引用，使用以下三个等级之一，而不是统一标注为“verify”：

• [settled] — 稳定且广为人知、不太可能发生变化的法律和监管依据（例如 FTC Act § 5、GDPR Art. 33、CCPA § 1798.100）。依赖这些依据批准上线前仍应核实，但优先级较低。
• [verify] — 确实存在、但应予核实的模型知识引用：具体实施法规、机构指引、执法行动、判决要旨、门槛、生效日期、2023 年之后的修订。
• [verify-pinpoint] — 精确定位引用（具体款项字母、卷号／页码、段落编号）具有最高的编造风险，必须始终对照一手来源核实。

工具检索到的引用保留其来源标签（[Westlaw]、[CourtListener]、[regulator site] 或 MCP 工具名称）；网页搜索引用仍标记为 [web search — verify]；用户提供的引用（来自 PRD 或种子材料）仍标记为 [user provided]。分级能体现实际需要进行的核实工作——如果读者什么都核实，就等于什么也没核实。绝不要删除或合并这些标签。

[platform policy — verify against live docs] — 未获取实时页面而引用的平台规则（Apple App Store Review Guidelines、Google Play policies、Meta / Snap / TikTok 创作者规则、ESRB / PEGI 描述符、银行卡组织规则、应用商店应用内购买政策）。平台政策绝不可使用 [settled]——这类政策可能不经通知就发生变化，而模型所依据的快照几乎总是过时的。如果上线是否可行取决于某项平台规则，依赖该规则前请在当前会话中获取政策的最新页面。 | 7 | 营销声明 | 是否有需要佐证的声明？ | 无营销内容 | | 8 | AI 治理 | 是否以任何形式使用 AI？该用例是否已录入登记册？是否已完成 AIA？是否已审查供应商 AI 条款？ | 第 2 步未发现 AI 组件 |

针对每个类别，输出：

### [N]. [Category]

**Checked:** [what you looked at]
**Finding:** [Clear | Needs work | Blocker | Skipped]
**Detail:** [what the issue is, if any — specific to the PRD, not generic]
**Calibration:** [per the config CLAUDE.md — this is usually an FYI / usually needs X / usually blocks]
**Action:** [what has to happen, who owns it, by when]

如实自动跳过。 如果某个类别不适用，请用一句话说明原因。不要凑内容。

行业提示。 上述 8 类框架以企业 SaaS 为主。如果上线涉及以下任何行业，请添加对应的补充项：针对每个受影响的类别，在基础框架问题旁一并提出补充问题，并在评估严重程度前指出行业特定制度。即使上线通过了全部 8 项检查，但遗漏行业特定制度，仍会留下合规漏洞。

行业	需识别的叠加监管制度
儿童 / 未成年人	COPPA（美国——面向 13 岁以下儿童的服务运营者，或实际知晓用户为儿童的运营者）、CA AADC / 州级适龄设计规范、平台年龄评级（ESRB、PEGI）、对成瘾性设计的审查（NY Safe for Kids Act、CA SB 976 及类似法规）、FTC 针对面向儿童的网红的代言指南
游戏 / 战利品箱 / 游戏内货币	战利品箱概率披露（类似 CA AB 2476 的规定，以及中国 / 韩国 / 比利时 / 荷兰的监管制度）、ESRB / PEGI 描述符（游戏内购买、战利品箱、真实赌博）、州赌博法（机会游戏与技巧游戏的界定、抽奖促销法）、FTC 关于暗黑模式的指导、平台商店政策（Apple、Google、主机平台）
金融 / 金融科技	GLBA（NPI、Safeguards Rule、Reg P）、州级货币传输牌照（约 50 个州及 DC 均有 MTL）、CFPB UDAAP、州级 UDAP、银行合作伙伴赞助要求及“实际贷款人”风险、适用时的 Reg E / Reg Z、如涉及证券经纪业务则遵循 FINRA
医疗健康	HIPAA（如属于 CE 或 BA）、FDA SaMD / 临床决策支持 / 一般健康豁免、州级健康隐私法规（WA MHMDA、NV SB 370、CT HIPAA 类似法规）、适用于非 HIPAA 实体的 FTC Health Breach Notification Rule
教育	FERPA（如服务对象是学校，或服务提供商代表学校行事）、州级学生隐私法规（NY Ed Law 2-d、IL SOPPA、CA SOPIPA + AB 1584）、如涉及 13 岁以下学生 K-12 数据则适用 COPPA
就业 / HR 技术	Title VII、EEOC 关于 AI 招聘的指导、ADA、州级 AI 招聘法规（IL AIVIA、NYC Local Law 144、CA / CO / UT / NJ 类似法规，已颁布或正在考虑中）、视频面试和击键记录产品适用的州级生物识别法规（IL BIPA、TX / WA 类似法规）、背景调查 / 验证产品适用的 FCRA
政府 / 公共部门	FedRAMP（Low / Moderate / High）、FAR / DFARS、适用时的 CMMC、州级同类制度（StateRAMP）、执法数据适用的 CJIS、税务数据适用的 IRS Publication 1075、StateRAMP 和州级采购规则
消费者 / 零售 / 营销	FTC Act § 5、Made-in-USA rule、Green Guides、CAN-SPAM、TCPA（电话呼叫适用 TCPA-Shaken/Stir）、州级自动续订法规（ROSCA、CA ARL、NY GBL § 527-a［消费者］或 GOL § 5-903［B2B 服务］——核实适用哪项）、州级抽奖 / 促销法

如果触发了行业提示，但基础框架中没有专门类别涵盖，应将其作为一个类别列出（例如“6a. 行业叠加监管——儿童 / COPPA + CA AADC”）。不要让它沦为类别 6「监管」中的附带事项；行业监管制度往往规定了具有约束力的底线，而非仅是脚注。

步骤 4：校准严重程度

针对每项发现，对照 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md 中的校准表：

• 如果符合“通常仅供参考”的模式 → 记录，不要阻止
• 如果符合“通常需要处理”的模式 → 说明需要完成的工作，并根据表格估算时间
• 如果符合“通常会阻止”的模式 → 显著标记，并按照升级处理表转交
• 如果属于新情况（表格中没有）→ 明确说明：“这不符合校准表中的任何模式，需要由人工判断”

步骤 5：整理审查结果

按照 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Launch review process → output format 规定的格式整理。在开头添加 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md ## Outputs 中的工作成果标题（该标题因用户角色而异——参见 ## Who's using this）。如果未指定内部格式：

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# Launch Review: [Feature name]

**Reviewed:** [date] | **Launch date:** [date] | **Reviewer:** [name]
**PRD:** [link] | **Ticket:** [link if connected]

---

## Bottom line

[One paragraph: can this ship? What has to happen first?]

**Call:** [Clear to ship | Ship with conditions | Blocked pending X | Needs escalation]

> **Before emitting a "Clear to ship" or "Ship with conditions" call:** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md`. If the Role is Non-lawyer:
>
> > Clearing a launch is a legal act — once the product ships, the company is committed to the legal posture documented here. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
> >
> > [Generate a 1-page summary: the launch, the findings by category, any open questions, the residual risk after conditions, and the three things to ask the attorney before the launch goes out.]
> >
> > If you need to find a lawyer: your professional regulator's referral service is the fastest starting point (state bar in the US; SRA/Bar Standards Board in England & Wales; Law Society in Scotland/NI/Ireland/Canada/Australia; or your jurisdiction's equivalent).
>
> Do not proceed past this gate to a "Clear to ship" or "Ship with conditions" call without an explicit yes. "Blocked pending X" and "Needs escalation" do not require the gate — those are review calls, not clearances.

---

## Findings by category

[All the category blocks from Step 3 — skip-noted categories at the bottom]

---

## Action items

| # | Item | Owner | Due | Blocking? |
|---|---|---|---|---|
| 1 | [specific] | [PM/eng/legal] | [date] | Yes/No |

---

## Escalations

[If any — who, why, drafted per escalation skill]

---

## Notes for next time

[If this launch surfaced a pattern that should update the calibration table]

---

## Citation check

Any cases, statutes, regulations, or enforcement actions referenced in this review were generated by an AI model and have not been verified against a primary source. Before relying on a citation in a launch decision, verify it against a legal research tool (Westlaw, CourtListener, or your firm's research platform) for accuracy, good law status, and current enforcement posture. Fabricated or misquoted citations in launch reviews can steer the business wrong. Source tags on each citation (e.g., `[Westlaw]`, `[web search — verify]`) show where it came from; `verify` tags carry higher fabrication risk and should be checked first.

第 6 步：生成两份输出——特权备忘录和脱敏工单评论

⚠️ 特权警告： 将完整的特权备忘录发布到 Jira/Linear 工单，而该工单由工程、PM 及其他非法律岗位广泛共享，可能会导致特权被放弃。不要将完整备忘录粘贴到广泛共享的工单中。

以下两项均为此技能的必需输出。 两项都不可省略。按以下顺序输出，并在两者之间用清晰的分隔线隔开，确保用户不会漏看脱敏内容。

输出 1——特权发布审查备忘录。 第 5 步汇总的完整分析：工作成果标头、结论、按类别列出的发现及风险依据、行动项、升级事项、下次注意事项、引文核查。这是内部法律工作成果。将其保存在案件档案中（Drive、DMS，或 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md 中规定的审查文档存放位置）。仅向特权圈内人士分发。

输出 2——脱敏工单评论区块——可安全发布到工单跟踪系统。 在备忘录之后，用清晰的 --- 分隔线和标题 ## SAFE TO POST TO TRACKER (non-privileged) 输出一段简短评论，且仅包含以下内容：

• 发布状态： 绿色／黄色／红色（即：可发布／满足条件后发布／在 X 事项解决前阻止／需要升级处理）
• 发布条件作为行动项： 每项条件单独列为一条，用指令形式写给 PM/工程团队（例如“发布前将 PIA 链接添加到工单”“从主页文案中删除‘最准确’的表述”）。不包含法律依据。
• 每项条件的截止日期。
• 每项条件的负责人。

脱敏区块不得包含工作成果／特权标头、风险依据、内部法律讨论、法规引文或升级事项说明。如果某项条件的措辞会泄露背后的法律理论（例如“报复风险”），请改写为行动指令（例如“在任期结束日期前提交 GC 审核”）。

分隔线和区块示例：

---

## SAFE TO POST TO TRACKER (non-privileged)

**Launch status:** Blocked pending conditions below.

**Conditions:**
- [ ] Attach completed PIA to ticket — Owner: [PM] — Due: [date]
- [ ] Remove "most accurate on the market" copy from homepage draft — Owner: [Marketing] — Due: [date]
- [ ] Confirm with GC before changing retention window — Owner: [PM] — Due: [date]

仅将输出 2 粘贴到工单跟踪系统。输出 1 仅分享给需要阅读完整分析的特权圈内人士。

交接事项

• 交接至 marketing-claims-review： 如果营销内容占比较大，移交其中的声明审查部分。
• 交接至 feature-risk-assessment： 如果某项发现较复杂，需要单独编写文档（例如新型 AI 功能、面向儿童的产品），则启动更深入的评估。
• 交接至 privacy： 如果发布涉及个人数据，运行 /privacy-legal:use-case-triage [feature]。如果分诊结果为 PIA REQUIRED 或 DPIA MANDATORY，则运行 /privacy-legal:pia-generation [feature]。不要只注明“需要 PIA”——要启动相应流程。
• 交接至 AI governance： 如果第 2 步发现了 AI 组件，运行 /ai-governance-legal:use-case-triage [feature]。如果分诊结果为 CONDITIONAL，则运行 /ai-governance-legal:aia-generation [feature]。如果涉及新的 AI 供应商，则运行 /ai-governance-legal:vendor-ai-review [vendor agreement]。

以“下一步”决策树收尾

按照 CLAUDE.md ## Outputs 中的要求，以“下一步”决策树收尾。根据此技能刚刚生成的内容调整选项——五个默认分支（起草 X、升级处理、获取更多事实、观察并等待、其他事项）只是起点，并非固定选项。决策树即为输出；由律师选择。

此技能不做什么

• 它不能替代与 PM 的沟通。PRD 往往有误或已过时——审查会提出问题，再由人工跟进。
• 它不会批准发布，而是为审批提供信息。
• 它不会追溯性地调整校准。如果此次发布结果良好（或糟糕），且应据此更新校准表，则由人工更新 ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md。