launch-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/launch-review

Load

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

→ framework + calibration. Stop if placeholders.

Get PRD + related docs. If tracker connected, pull ticket and comments.
Walk every framework category using the workflow below.
Calibrate each finding against the table. Novel = flag explicitly.
Output review memo in house format. Post summary to ticket if connected.
Hand off: marketing-claims-review if substantial marketing; feature-risk-assessment if a finding needs depth.

/product-legal:launch-review PROJ-1234

加载

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

→ 框架+校准。若存在占位符则停止。

获取PRD及相关文档。若已关联追踪系统，拉取工单及评论。
按照以下工作流程逐一检查框架中的每个分类。
根据表格校准每项发现。若为新情况，需明确标记。
按照内部格式输出审查备忘录。若已关联工单，将摘要发布至工单。
移交：若涉及大量营销内容，移交至营销声明审查；若某项发现需深入分析，移交至功能风险评估。

/product-legal:launch-review PROJ-1234

Matter context

事项上下文

Matter context. Check

## Matter workspaces

in the practice-level CLAUDE.md. If

Enabled

✗

(the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run

/product-legal:matter-workspace switch <slug>

or say

practice-level

." Load the active matter's

matter.md

for matter-specific context and overrides. Write outputs to the matter folder at

~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/

. Never read another matter's files unless

Cross-matter context

on

事项上下文：查看业务级CLAUDE.md中的

## Matter workspaces

。若「启用」状态为

✗

（内部用户默认设置），则跳过本段剩余内容——技能将使用业务级上下文，事项机制不可见。若已启用且无活跃事项，询问：「本次对应哪个事项？请运行

/product-legal:matter-workspace switch <slug>

或选择

业务级

。」加载活跃事项的

matter.md

以获取事项特定上下文及覆盖规则。将输出写入事项文件夹

~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/

。除非「跨事项上下文」开启，否则不得读取其他事项的文件。

Destination check

输出目标检查

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical

## Shared guardrails → Destination check

in this plugin's CLAUDE.md.

生成输出前，检查输出目标。若用户指定了目标（如频道、分发列表、交易对手、「所有人」），需询问该目标是否属于特权保护范围。公开频道、全公司列表、交易对手/对方律师、供应商及客户（针对工作成果）会导致特权保护失效。若目标看起来在保护范围外，需标记并提供以下选项：(a) 仅供法务查看的特权版本，(b) 适用于更广泛频道的脱敏版本，(c) 同时提供两者——不得静默添加特权页眉后将内容粘贴至无法提供保护的位置。详见本插件CLAUDE.md中的标准

## Shared guardrails → Destination check

章节。

Purpose

目的

Read the PRD, check every category in this team's framework, calibrate against what actually blocks here (per

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

), and output a review in house format. Goal: a PM reads it and knows exactly what has to happen before they ship.

阅读PRD，检查本团队框架中的每个分类，根据

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

校准实际阻碍因素，并按照内部格式输出审查报告。目标：让产品经理阅读后明确知晓发布前需完成的所有事项。

Load calibration

加载校准规则

Read

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

```
## Review framework
```
— the categories to check
```
## Risk calibration
```
— what blocks vs. what's FYI at this company
```
## Launch review process
```
— output format
```
## Escalation
```
— when to route up

The calibration table is the difference between this skill and a generic checklist. If the table says "new data collection → PIA, ships in 1-2 days," don't write "this might require a full DPIA and regulatory consultation." Match the team's actual practice.

阅读

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

：

```
## Review framework
```
— 需检查的分类
```
## Risk calibration
```
— 本公司定义的阻碍项与仅供参考项
```
## Launch review process
```
— 输出格式
```
## Escalation
```
— 升级上报的触发条件

校准表是本技能与通用检查清单的核心区别。若表格显示「新数据收集→PIA，1-2天内完成发布」，则不得写「这可能需要完整的DPIA及监管咨询」。需匹配团队实际操作规范。

Workflow

工作流程

Step 1: Get the inputs

步骤1：获取输入

PRD — from file, Drive, or the launch tracker ticket
Spec/design doc — if separate
Marketing plan — if there is one (hands off to marketing-claims-review if substantial)
Launch date — for urgency calibration
Launch tracker ticket — if connected, pull it for context and comments

If Jira/Linear MCP is connected, pull the ticket history — often there's context in earlier comments that the PRD doesn't capture.

PRD — 来自文件、云端硬盘或发布追踪工单
规格/设计文档 — 若单独存在
营销计划 — 若存在（若涉及大量内容，移交至营销声明审查）
发布日期 — 用于紧急程度校准
发布追踪工单 — 若已关联，拉取工单获取上下文及评论

若已连接Jira/Linear MCP，拉取工单历史记录——早期评论中往往包含PRD未提及的上下文信息。

Step 2: Understand what's launching

步骤2：理解发布内容

Before the checklist, answer in plain English:

What does this thing do?
Who uses it — existing users, new users, a new segment?
What's new vs. what's an extension of something already reviewed?
Any new data, new vendors, new claims, new jurisdictions?

AI detection — run before the framework walk. Check whether this launch uses AI in any form: a third-party model, an internally built model, an AI-powered vendor feature, automated scoring or classification, generative content, recommendations, predictions. Look for this even if the PRD doesn't label it "AI" — words like "intelligent", "automated", "personalized", "generated", "suggested" are tells.

If AI component detected → flag it, then run

/ai-governance-legal:use-case-triage [feature]

alongside the framework walk. Category 8 below handles the detail; this flag ensures it's never skipped even if the PRD is vague.

在开始检查清单前，用简洁语言回答：

该功能的用途是什么？
用户群体是谁——现有用户、新用户还是新细分群体？
哪些是新内容，哪些是已审查内容的扩展？
是否涉及新数据、新供应商、新声明或新司法管辖区？

AI检测——在框架检查前执行：检查本次发布是否以任何形式使用AI：第三方模型、内部构建模型、AI驱动的供应商功能、自动评分或分类、生成式内容、推荐、预测。即使PRD未标注为「AI」，也要留意相关线索，如「智能」「自动化」「个性化」「生成」「推荐」等词汇。

若检测到AI组件→标记，然后在框架检查的同时运行

/ai-governance-legal:use-case-triage [feature]

。下文分类8将处理细节；此标记确保即使PRD表述模糊，也不会遗漏AI相关审查。

Step 3: Walk the framework

步骤3：框架检查

For each category in

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

→ Review framework. If the team doesn't have one, use the 8-category default below. The categories are stable framing concepts; within each category, research the regulatory regimes applicable to the product's sector, audience, and jurisdictions before calibrating severity. What blocks in one jurisdiction or sector may be routine in another —

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

captures the team's calibration.

#	Category	Key question	Auto-skip if
1	Contractual commitments	Does this conflict with any customer-facing promise (ToS, SLA, marketing)?	No customer-facing changes
2	Privacy	New data collection, new purpose, new sharing?	No data changes
3	Security	New attack surface, new data at rest, new access patterns?	UI-only, no backend change
4	IP	Third-party code/content? Open-source license check? Outputs that could infringe?	No new dependencies, no user-generated content
5	Third-party	New vendor, partner, or integration?	No new external parties
6	Regulatory	Does this touch a regulated sector, audience, or jurisdiction? Research the applicable regimes.	Same users, same sectors, same jurisdictions as existing product

No silent supplement. If a research query to the configured legal research tool (Westlaw, CourtListener, regulator sites, or firm platform) returns few or no results for a regime, enforcement precedent, or regulator guidance, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged
[web search — verify]
and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.
Source attribution tiering. Tag every citation in the review with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag:
[settled]
— stable, well-known statutory and regulatory references unlikely to have changed (e.g., FTC Act § 5, GDPR Art. 33, CCPA § 1798.100). Still verify before relying on it to clear a launch, but lower priority.
[verify]
— model-knowledge citations that are real but should be verified: specific implementing regulations, agency guidance, enforcement actions, case holdings, thresholds, effective dates, post-2023 amendments.
[verify-pinpoint]
— pinpoint citations (specific subsection letters, volume/page numbers, paragraph numbers) carry the highest fabrication risk and should ALWAYS be verified against a primary source.
Tool-retrieved citations keep their source tag (
[Westlaw]
,
[CourtListener]
,
[regulator site]
, or the MCP tool name); web-search citations remain
[web search — verify]
; user-supplied citations (from the PRD or seed materials) remain
[user provided]
. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.
[platform policy — verify against live docs]
— platform rules (Apple App Store Review Guidelines, Google Play policies, Meta / Snap / TikTok creator rules, ESRB / PEGI descriptors, card-network rules, app-store in-app-purchase policies) cited without fetching the live page. Never use
[settled]
for a platform policy — these change without notice and the model's snapshot is almost always stale. If the launch hinges on a platform rule, fetch the current policy page in-session before relying on it. | 7 | Marketing claims | Any claims that need substantiation? | No marketing component | | 8 | AI governance | Does this use AI in any form? Is the use case in the registry? AIA done? Vendor AI terms reviewed? | No AI component detected in Step 2 |

For each category, output:

markdown

undefined

针对

~/.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、监管机构网站或律所平台）发起的研究查询，针对某一制度、执法先例或监管指南返回结果极少或无结果，需报告已发现内容并停止。不得未经询问就通过网络搜索或模型知识填补空白。应说明：「从[工具]获取了[N]条结果。[制度/主题]的覆盖范围较窄。可选方案：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 进行网络搜索——结果将标记为
[web search — verify]
，使用前需与发布机构核实，或(4) 标记为未验证并停止。请问您选择哪种方案？」由律师决定是否接受低可信度来源。
来源归因分层：为审查中的每个引用标记来源。对于模型生成的引用，使用以下三个层级而非统一的「需验证」标记：
[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政策、Meta/Snap/TikTok创作者规则、ESRB/PEGI分级、卡组织规则、应用商店内购政策）。平台规则不得使用
[settled]
标记——这些规则会随时变更，模型的快照几乎总是过时的。若发布依赖某一平台规则，需在会话中获取当前政策页面后再使用。 | 7 | 营销声明 | 是否存在需要举证的声明？ | 无营销相关内容 | | 8 | AI治理 | 是否以任何形式使用AI？用例是否已登记？是否完成AIA？是否审查了供应商AI条款？ | 步骤2未检测到AI组件 |

每个分类的输出格式：

markdown

undefined

[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]


**Auto-skip honestly.** If a category doesn't apply, say so with a one-line reason. Don't pad.

**Sector hints.** The 8-category framework above is enterprise-SaaS-shaped. If the launch involves any of the sectors below, add the overlay: ask the overlay question alongside the base-framework question for each affected category, and surface the sector-specific regime before calibrating severity. A launch that checks all 8 boxes but misses a sector regime still ships with a hole.

| Sector | Overlay regimes to surface |
|---|---|
| **Children / minors** | COPPA (US — operators of services directed to children under 13 or with actual knowledge), CA AADC / state age-appropriate design codes, platform age ratings (ESRB, PEGI), addictive-design scrutiny (NY Safe for Kids Act, CA SB 976 and analogs), FTC endorsement guides for kid-directed influencers |
| **Gaming / loot boxes / in-game currency** | Loot-box odds disclosure (CA AB 2476-style, Chinese / Korean / Belgian / Dutch regimes), ESRB / PEGI descriptors (In-Game Purchases, Loot Boxes, Real Gambling), state gambling law (games-of-chance vs. games-of-skill lines, sweepstakes promotions law), FTC dark-patterns guidance, platform-store policies (Apple, Google, console) |
| **Financial / fintech** | GLBA (NPI, Safeguards Rule, Reg P), state money transmission licensing (MTLs across ~50 states + DC), CFPB UDAAP, state UDAP, bank-partner sponsorship requirements and "true lender" exposure, Reg E / Reg Z where applicable, FINRA if brokerage |
| **Health** | HIPAA (if CE or BA), FDA SaMD / clinical decision support / general wellness exemption, state health-privacy (WA MHMDA, NV SB 370, CT HIPAA-analog), FTC Health Breach Notification Rule for non-HIPAA entities |
| **Education** | FERPA (if school or school-acting service provider), state student-privacy (NY Ed Law 2-d, IL SOPPA, CA SOPIPA + AB 1584), COPPA if K-12 data under 13 |
| **Employment / HR tech** | Title VII, EEOC guidance on AI in hiring, ADA, state AI-hiring laws (IL AIVIA, NYC Local Law 144, CA / CO / UT / NJ analogs under consideration or enacted), state biometric laws (IL BIPA, TX / WA analogs) for video-interview and keystroke products, FCRA for background / verification products |
| **Government / public sector** | FedRAMP (Low / Moderate / High), FAR / DFARS, CMMC where applicable, state-level equivalents (StateRAMP), CJIS for law-enforcement data, IRS Publication 1075 for tax data, StateRAMP and state procurement rules |
| **Consumer / retail / marketing** | FTC Act § 5, Made-in-USA rule, Green Guides, CAN-SPAM, TCPA (with TCPA-Shaken/Stir for calls), state auto-renewal (ROSCA, CA ARL, NY GBL § 527-a [consumer] or GOL § 5-903 [B2B services] — verify which applies), state sweepstakes/promotions law |

If a sector hint fires and no dedicated category in the base framework covers it, insert it as a category (e.g., "6a. Sector overlay — children / COPPA + CA AADC"). Don't let it disappear into category 6 Regulatory as an afterthought; the sector regime often supplies the controlling floor, not a footnote.

检查内容： [所检查的对象] 发现： [通过 | 需要整改 | 阻碍发布 | 已跳过] 详情： [若存在问题，需具体说明PRD中的相关内容，不得泛泛而谈] 校准： [根据配置文件CLAUDE.md——通常为仅供参考/通常需完成X/通常阻碍发布] 行动： [需完成的事项、负责人、截止日期]


**如实自动跳过**：若某分类不适用，需用一句话说明原因。不得凑数。

**领域提示**：上述8类框架适用于企业SaaS场景。若发布涉及以下领域之一，需添加叠加规则：在每个受影响分类的基础框架问题之外，同时询问叠加规则问题，并在校准风险等级前明确领域特定制度。即使通过了8类框架检查，但遗漏领域制度的发布仍存在漏洞。

| 领域 | 需明确的叠加制度 |
|---|---|
| **儿童/未成年人** | COPPA（美国——面向13岁以下儿童的服务运营商或明知用户为儿童的运营商）、加州AADC/州级适龄设计规范、平台年龄分级（ESRB、PEGI）、成瘾设计审查（纽约儿童安全法案、加州SB 976及类似法案）、FTC针对儿童定向网红的代言指南 |
| **游戏/开箱机制/游戏内货币** | 开箱概率披露（加州AB 2476式、中/韩/比/荷制度）、ESRB/PEGI分级（游戏内购买、开箱机制、真实赌博）、州级赌博法（机会游戏vs技能游戏的界限、抽奖促销法）、FTC暗模式指南、平台商店政策（苹果、谷歌、主机平台） |
| **金融/金融科技** | GLBA（非公开个人信息、安全规则、Reg P）、州级货币传输许可（约50个州+华盛顿特区的MTL）、CFPB UDAAP、州级UDAP、银行合作伙伴赞助要求及「真实贷款人」风险、适用情况下的Reg E/Reg Z、若涉及经纪业务需遵守FINRA规则 |
| **医疗健康** | HIPAA（若为覆盖实体或商业伙伴）、FDA SaMD/临床决策支持/通用健康豁免、州级健康隐私法（华盛顿州MHMDA、内华达州SB 370、康涅狄格州HIPAA类似法案）、针对非HIPAA实体的FTC健康 breach通知规则 |
| **教育** | FERPA（若为学校或代学校提供服务的供应商）、州级学生隐私法（纽约州教育法2-d、伊利诺伊州SOPPA、加州SOPIPA+AB 1584）、若涉及13岁以下K-12学生数据需遵守COPPA |
| **就业/人力资源科技** | Title VII、EEOC关于AI招聘的指南、ADA、州级AI招聘法（伊利诺伊州AIVIA、纽约市第144号地方法、加州/科罗拉多州/犹他州/新泽西州已颁布或审议中的类似法案）、州级生物识别法（伊利诺伊州BIPA、德克萨斯州/华盛顿州类似法案）（适用于视频面试和按键记录产品）、针对背景/验证产品的FCRA |
| **政府/公共部门** | FedRAMP（低/中/高等级）、FAR/DFARS、适用情况下的CMMC、州级等效制度（StateRAMP）、针对执法数据的CJIS、针对税务数据的IRS Publication 1075、StateRAMP及州级采购规则 |
| **消费者/零售/营销** | FTC Act § 5、美国制造规则、绿色指南、CAN-SPAM、TCPA（通话需遵守TCPA-Shaken/Stir）、州级自动续费规则（ROSCA、加州ARL、纽约州GBL § 527-a[消费者]或GOL § 5-903[B2B服务]——需验证适用范围）、州级抽奖/促销法 |

若触发领域提示且基础框架中无对应分类，需添加为单独分类（如「6a. 领域叠加——儿童/COPPA+加州AADC」）。不得将其作为事后补充归入分类6监管合规；领域制度通常是管控底线，而非脚注。

Step 4: Calibrate severity

步骤4：风险等级校准

For each finding, check against the calibration table in ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md:

If it matches a "usually FYI" pattern → note it, don't block
If it matches "usually requires work" → specify the work, estimate timeline from the table
If it matches "usually blocks" → flag prominently, route per escalation table
If it's novel (not in the table) → say so explicitly: "This doesn't match any pattern in the calibration — needs a human call"

针对每项发现，对照

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

中的校准表：

若符合「通常仅供参考」模式→记录，不阻碍发布
若符合「通常需要整改」模式→明确整改内容，根据表格预估时间线
若符合「通常阻碍发布」模式→突出标记，按照升级表上报
若为新情况（未列入表格）→明确说明：「此情况未在校准表中匹配到模式——需人工判断」

Step 5: Assemble the review

步骤5：整理审查报告

Format per

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

→ Launch review process → output format. Prepend the work-product header from

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

## Outputs

(it differs by user role — see

## Who's using this

). If no house format is specified:

markdown

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

按照

~/.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

）。若未指定内部格式，使用以下模板：

markdown

[工作成果页眉——根据插件配置## Outputs]

Launch Review: [Feature name]

发布审查：[功能名称]

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

审查日期： [日期] | 发布日期： [日期] | 审查人： [姓名] PRD： [链接] | 工单： [若已关联则提供链接]

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.

[一段内容：能否发布？发布前需完成哪些事项？]

结论： [可发布 | 满足条件后发布 | 需完成X后方可发布 | 需升级上报]

在得出「可发布」或「满足条件后发布」结论前： 阅读
~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md
中的
## Who's using this
。若角色为非法务人员：
批准发布属于法律行为——产品发布后，公司需承担本文件记录的法律立场。您是否已与律师审查过本报告？若是，可继续。若否，请将以下摘要提交给律师：

[生成1页摘要：发布内容、各分类发现、未解决问题、满足条件后的剩余风险，以及发布前需向律师确认的三个问题。]

若您需要寻找律师：所在地区的专业监管机构推荐服务是最快的途径（美国为州律师协会；英格兰及威尔士为SRA/律师标准委员会；苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚为律师协会；或所在司法管辖区的等效机构）。

未获得明确同意前，不得得出「可发布」或「满足条件后发布」结论。「需完成X后方可发布」和「需升级上报」无需此确认——这些是审查结论，而非批准结论。

Findings by category

各分类发现

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

[步骤3中的所有分类模块——已跳过的分类放在最后]

Action items

行动项

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

#	事项	负责人	截止日期	是否阻碍发布？
1	[具体内容]	[产品经理/工程师/法务]	[日期]	是/否

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.

undefined

本审查中引用的所有案例、法规、条例或执法行动均由AI模型生成，未对照原始来源验证。在发布决策中依赖引用前，需通过法律研究工具（Westlaw、CourtListener或贵所研究平台）验证其准确性、有效性及当前执法态势。发布审查中伪造或错误引用的内容可能误导业务决策。每个引用的来源标记（如

[Westlaw]

、

[web search — verify]

）显示其来源；

verify

标记的伪造风险较高，需优先验证。

undefined

Step 6: Produce BOTH outputs — the privileged memo AND the redacted ticket comment

步骤6：生成双输出——特权备忘录及脱敏工单评论

⚠️ Privilege warning: Posting the full privileged memo to a Jira/Linear ticket that is widely shared with engineering, PM, and other non-legal roles may waive privilege. Don't paste the full memo into a broadly-shared ticket.

Both of the following are REQUIRED outputs of this skill. Neither is optional. Print them in the order below, with a clear divider between them so the user cannot miss the redacted block.

Output 1 — Privileged launch review memo. The full analysis assembled in Step 5: work-product header, bottom line, findings by category with risk rationale, action items, escalations, notes for next time, citation check. This is internal legal work product. Keep it in your matter file (Drive, DMS, or wherever

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

says review docs go). Distribute only to people inside the privilege circle.

Output 2 — Redacted ticket-comment block — SAFE TO POST TO TRACKER. After the memo, with a clear

---

divider and the header

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

, produce a short comment block containing ONLY:

Launch status: green / yellow / red (i.e., Clear to ship / Ship with conditions / Blocked pending X / Needs escalation)
Conditions as action items: each condition is a bullet, written as an instruction to the PM/eng ("add PIA link to ticket before ship", "remove 'most accurate' language from homepage copy"). No legal reasoning.
Deadline per condition.
Owner per condition.

The redacted block contains NO work-product / privilege header, NO risk rationale, NO internal legal discussion, NO regulatory citations, NO escalation notes. If a condition's phrasing would leak the underlying legal theory ("retaliation risk"), rewrite it as the action ("route to GC before term date").

Example divider and block:

markdown

---

⚠️ 特权警告：将完整特权备忘录发布至与工程师、产品经理及其他非法务角色广泛共享的Jira/Linear工单，可能导致特权保护失效。不得将完整备忘录粘贴至广泛共享的工单。

以下两项均为本技能的必填输出，缺一不可。 按以下顺序输出，两者间需添加清晰分隔符，确保用户不会遗漏脱敏内容块。

输出1——特权发布审查备忘录：步骤5整理的完整分析内容：工作成果页眉、核心结论、带风险依据的各分类发现、行动项、升级上报、后续改进建议、引用验证提示。此为内部法务工作成果。需保存在事项文件中（云端硬盘、文档管理系统或

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

指定的审查文档存储位置）。仅可分发给特权保护范围内的人员。

输出2——脱敏工单评论块——可安全发布至追踪系统：在备忘录后添加清晰的

---

分隔符及标题

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

，生成简短评论块，仅包含：

发布状态：绿色/黄色/红色（即可发布/满足条件后发布/需完成X后方可发布/需升级上报）
条件行动项：每个条件以项目符号列出，以面向产品经理/工程师的指令形式撰写（如「发布前将PIA链接添加至工单」「从首页文案中移除『最准确』表述」）。不得包含法律推理。
每个条件的截止日期
每个条件的负责人

脱敏块不得包含工作成果/特权页眉、风险依据、内部法务讨论、监管引用、升级上报说明。若某条件的表述可能泄露潜在法律逻辑（如「报复风险」），需改写为具体行动（如「变更保留期限前需确认GC意见」）。

分隔符及块示例：

markdown

---

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]


Paste Output 2 (and only Output 2) to the tracker. Link Output 1 only to the people inside the privilege circle who need to read the full analysis.

发布状态： 需完成以下条件后方可发布。

条件：

将已完成的PIA附加至工单 — 负责人：[产品经理] — 截止日期：[日期]
从首页草稿中移除「市场最准确」表述 — 负责人：[营销人员] — 截止日期：[日期]
变更保留期限前需确认GC意见 — 负责人：[产品经理] — 截止日期：[日期]


将输出2（仅输出2）粘贴至追踪系统。仅向特权保护范围内需要阅读完整分析的人员提供输出1的链接。

Handoffs

移交规则

To marketing-claims-review: If there's a substantial marketing component, hand off the claims section.
To feature-risk-assessment: If a finding is complex enough to need its own doc (e.g., novel AI feature, children's product), spawn a deeper assessment.
To privacy: If the launch touches personal data, run
```
/privacy-legal:use-case-triage [feature]
```
. If triage returns PIA REQUIRED or DPIA MANDATORY, run
```
/privacy-legal:pia-generation [feature]
```
. Don't just note "PIA needed" — trigger it.

To AI governance: If an AI component was detected in Step 2, run

/ai-governance-legal:use-case-triage [feature]

. If triage returns CONDITIONAL, run

/ai-governance-legal:aia-generation [feature]

. If a new AI vendor is involved, run

/ai-governance-legal:vendor-ai-review [vendor agreement]

移交至营销声明审查：若涉及大量营销内容，移交声明部分。
移交至功能风险评估：若某项发现复杂到需单独文档分析（如新AI功能、儿童产品），启动深度评估。
移交至隐私合规：若发布涉及个人数据，运行
```
/privacy-legal:use-case-triage [feature]
```
。若分类结果为需要PIA或强制DPIA，运行
```
/privacy-legal:pia-generation [feature]
```
。不得仅记录「需要PIA」——需触发对应流程。

移交至AI治理：若步骤2检测到AI组件，运行

/ai-governance-legal:use-case-triage [feature]

。若分类结果为有条件通过，运行

/ai-governance-legal:aia-generation [feature]

。若涉及新AI供应商，运行

/ai-governance-legal:vendor-ai-review [vendor agreement]

。

Close with the next-steps decision tree

以后续步骤决策树收尾

End with the next-steps decision tree per CLAUDE.md

## Outputs

. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

根据CLAUDE.md

## Outputs

中的后续步骤决策树收尾。需根据本技能生成的内容自定义选项——五个默认分支（起草X、升级上报、获取更多信息、观察等待、其他）为起点，而非固定选项。决策树为输出内容，由律师选择下一步。

What this skill does not do

本技能不负责的事项

It doesn't replace a conversation with the PM. Often the PRD is wrong or out of date — the review surfaces questions, a human asks them.
It doesn't approve the launch. It informs the approval.
It doesn't retroactively calibrate. If this launch turns out fine (or badly) in a way that should update the calibration table, a human updates ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md.

不替代与产品经理的沟通。PRD往往存在错误或过时内容——审查仅能发现问题，需人工询问确认。
不批准发布。仅为批准提供信息支持。
不进行事后校准。若本次发布结果良好（或不佳），且需更新校准表，需由人工更新
```
~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md
```
。