# Nda Review

> 保密协议（NDA）专项审查技能，由 contract-review 路由器按合同类型路由加载，不直接 面向用户调用。覆盖场景：单方保密协议、双方互负保密协议、Confidentiality Agreement、Non-Disclosure Agreement、保密条款占主体的合作前期文件。 同义场景词：NDA 审查、保密协议审查、保密条款审查、confidentiality review。 执行全链路：matter 上下文检查、产物去向检查、披露方/接收方/双方立场判定、 NDA 立场 playbook 加载或现场补齐、Scope check（识别名为 NDA 实为竞业限制/ 排他合作/技术许可/不招揽的藏条款）、六类分类检查清单、按 playbook 三色 分桶、输出 triage memo 与 next-steps 决策树，收尾登记续期并过引用审计。

- Skill: `minimax-ai/nda-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add minimax-ai/nda-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/minimax-ai/nda-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: MiniMax AI (https://skillmd.com/u/minimax-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/minimax-ai/nda-review

---


# 保密协议（NDA）专项审查

## 目的

把一份保密协议从「读一遍」变成「按本方立场逐项过堂」：确认审查视角
（披露方/接收方/双方互负），用经确认的 playbook 立场逐项比对，把结果分成
🟢🟡🔴 三桶，产出一份可直接行动（改、谈、签、停）的 triage memo。

本技能的核心纪律有三条：

1. **结论依附立场**：同一条款对披露方是保护、对接收方是负担，不先定立场
   就无权下结论；
2. **🟢 不出自默认值**：🟢 只能基于律师审定的 playbook 立场；画像里还是
   默认模板时，单份合同最高 🟡（docs/scenes/contract-review-cn.md B3）；
3. **藏条款必现形**：名为 NDA 实为竞业限制、排他合作、技术许可、不招揽的，
   一律 auto-🟡 并明示，不允许悄悄放过。

本技能遵守 legal-core Shared guardrails（G1–G12）与docs/scenes/contract-review-cn.md；
冲突时以 legal-core 为准。

## 前置检查

1. 已由 `contract-review` 路由器完成：画像检查（无 [填空]）、路由确认（用户已认可
   NDA 类型）。未经路由器直接进来的，先补这两项。
2. 文本完整可读；只有部分页或照片件的，在 reviewer note 的「已读」行如实
   写明范围。
3. 用户角色已识别（律师/法务/业务/其他），决定 G4 标头档位与 G5 后果门
   口径；画像未完成时按非律师档处理。

## 操作规程

### 第 0 步：Matter context（事项上下文）

- 检查当前工作区是否已有相关事项：查 `matters/_log.yaml`（登记簿 schema 与
  目录约定以 legal-core 的 `matter-workspace` 为准）。
- 已有事项：把本次审查挂到该事项目录下（drafts/ 存放 memo），并在
  notes.md 追加一条进展。
- 没有事项且本次审查可能伴随后续谈判、多轮修改：建议用户经
  `matter-workspace` 建档（一句提示即可，不强制、不代为决定）。
- 一次性快审（用户明说「就看一下」）：可不在事项下落，但 memo 仍按统一
  模板。

### 第 1 步：Destination check（产物去向检查）

- 询问或从上下文判断：这份审查产物会给谁看？仅内部法务圈，还是会转发业务
  团队、管理层，甚至相对方？
- 去向在保密圈外（如业务群、外部顾问、相对方）：**flag 明示风险**——memo
  含本方 playbook 立场与底线，外泄即谈判减分，甚至构成对本方不利的信息
  披露。
- 用户确需外发：提供**内外双版本**——内部版带完整 reviewer note 与立场
  依据；外部版走 Quiet mode（docs/scenes/contract-review-cn.md A2），只含结论与修改建议，
  不含 playbook 立场、底线与来源标记。两个版本的 G4 标头都保留。
- 用户说不清楚去向：按更保守处理（仅内部版），并在 memo 头部注明
  「未经确认不得外发」。

### 第 2 步：立场判定（决定风险视角）

判定本方在本协议中的角色，三者必居其一：

- **披露方**：本方主要向外提供保密信息（如技术方案、客户名单、经营数据给
  潜在合作方/投资人/供应商看）。风险视角：定义是否够宽、例外是否被滥用、
  期限是否够长、违约救济是否有力、返还销毁是否可执行。
- **接收方**：本方主要接收对方保密信息。风险视角：定义是否过宽吞噬公共
  知识、例外是否齐备、期限是否过长、违约责任与赔偿上限是否畸高、是否被
  隐性捆绑（不得绕开、不得反向工程、成果归属）。
- **双方互负**：双向披露。两个视角都要过一遍，且额外检查「义务对等性」——
  对方给自己的例外与宽松是否同样给了本方。

判定依据：协议文本中的披露方向条款 + 用户确认。文本与业务实质不一致时
（如文本是双方互负但业务上只有本方披露），以业务实质为准并在 memo 中
说明。

### 第 3 步：加载 playbook（NDA 立场）

- 读取执业画像中的 NDA 立场节（场景自定义小节，见docs/scenes/contract-review-cn.md B9 的
  配置纪律）。
- 已填且标注「经律师审定」：直接使用。
- 已填但仍是**默认模板**（未经律师审定）：可用作检查参照，但最终分桶最高
  只能给 🟡，并在 memo 中明示此约束。
- 未填（[填空]）：现场询问以下关键立场，取得回答后**经 `customize` 技能
  写回画像**（不直接手改画像），标注 [已确认—日期] 与「未经律师审定」，
  再继续：
  1. 保密期限可接受范围（例如「X 年起、超过 Y 年需升级」——具体数字由
     用户给出，本技能不提供硬编码阈值）；
  2. 是否接受单方违约赔偿上限，可接受的上限结构（固定金额 / 实际损失 /
     二者孰低）；
  3. 管辖偏好（法院或仲裁、地点；与 B9 首选管辖对齐）。
- 用户拒答或答不出：不编造立场，相关检查项整体按 🟡 处理，理由写
  「立场未确认」。

### 第 4 步：Scope check（范围异变检查，无条件执行）

通读全文（这是本技能唯一强制通读的步骤），识别协议是否在保密外衣下夹带
其他法律关系。命中以下任一情形，**无条件 auto-🟡**，并在 memo 执行摘要
第一行明示「本协议名为保密协议，实际含有 XX 条款」：

1. **竞业限制**：限制本方或本方员工从事竞争业务、限制跳槽去向。提示：
   对劳动者的竞业限制有法定补偿与期限要求 [模型知识—待核实，引用前经
   statute-verify 核验]，夹带在 NDA 里的竞业条款往往不满足。
2. **排他合作**：约定只能与对方合作、不得与第三方洽谈同类业务。
3. **技术许可**：保密义务之外出现「许可使用」「授权实施」「royalty/
   许可费」等字样，实为知识产权许可安排。
4. **不招揽（不挖角）**：限制聘用对方员工。范围与期限过宽时，对本方用人
   自由影响重大。
5. **成果归属**：约定磋商中产生的改进、衍生成果归对方或共有——实为知识
   产权归属条款。

处理方式：藏条款部分不按保密条款清单审查，改按对应法律关系另列标记项
（起点 🟡；涉知识产权归属复杂或限制人身/经营自由的，评估是否 🔴 或触发
B5 升级）。命中画像红线条款（如画像载明「不接受超两年竞业限制」）的，
按画像红线纪律：出现即提示，严重度下限 🟠（G9）。

### 第 5 步：分类检查清单（六类）

逐类对照 playbook 检查。**只按类别与要点检查，不设硬编码数值阈值**——
凡涉及期限长短、金额高低的判断，一律比对画像/playbook 中本方立场；立场
没有覆盖的标 🟡 写「超出 playbook」。条款级风险形态与审查要点调用
`risk-clause-database` 取统一口径。

1. **保密信息定义范围**：定义方式是列举、概括还是「一切披露均保密」；口头
   披露是否需事后书面确认才纳入；是否把披露前已知、独立开发的信息也罩进来
   （接收方视角尤其注意）。
2. **例外情形**：是否包含惯常例外——已公开、非因违约而公开、接收时已合法
   持有、独立开发、依法或应监管要求须披露（须披露时是否有事先通知与最小化
   披露安排）。例外缺失或过窄，接收方视角至少 🟡。
3. **保密期限与返还销毁**：期限长短对照 playbook 立场；期限起算点（签约日/
   披露日/协议终止日）是否明确；终止后返还或销毁的时限、方式、是否需要书面
   证明；备份副本与依法留存的处理是否留有余地。
4. **违约责任与赔偿上限**：违约金/赔偿的计算方式；有无上限、上限结构对照
   playbook；是否约定间接损失、可得利益也在赔偿范围（接收方视角高风险）；
   是否有律师费、维权费用转嫁条款。
5. **管辖与争议解决**：法院还是仲裁、地点，对照画像首选管辖；是否约定境外
   管辖或境外仲裁（命中即触发 B5 升级）；涉外因素的准据法约定（按 G3 法域
   识别五步处理）。
6. **是否隐含知识产权许可**：「为评估目的可使用」之类表述是否被写成可延展
   的使用授权；披露是否被解释为权利转让或许可；标识、专利、软件的披露是否
   伴随权利处分语言。

同时全量过一遍docs/scenes/contract-review-cn.md A8.1 的 blocks 红线（NDA 场景最常见的是：
借保密安排固定虚假交易外观、或要求本方协助隐瞒依法须披露的信息）。命中
即停止，按 blocks 纪律处理。

### 第 6 步：按 playbook 分桶 🟢🟡🔴

- **🟢 可推进**：每一类检查项都落在经律师审定的 playbook 立场之内。画像
  立场是默认模板时，**不得给 🟢，最高 🟡**，理由写明「立场未经律师审定」。
- **🟡 需修订或需人判断**：条款偏离 playbook 但可经修改回到立场内；或
  playbook 未覆盖该项；或命中 Scope check 藏条款。
- **🔴 不得推进**：命中 blocks 红线或画像审批底线；或条款组合构成对本方的
  重大不利且不可经修改补救（如接收方视角下「无限期 + 无上限赔偿 + 放弃
  一切例外」的组合）。
- **双轴标注**：每个标记项同时按 G9 给法律风险轴（🔴🟠🟡🟢）与商业摩擦轴
  （阻碍/拖慢/费解/无感）。法律风险高但商业摩擦也高的，建议栏写替代方案
  方向，不只写「删」。

### 第 7 步：输出 triage memo

按下方模板输出。执行摘要里**只放机械性一行修改**（如「第 X 条『五年』改为
『三年』」这类不需起草的改动）；凡是需要起草新语言的（重写定义条款、补
例外条款），建议栏只写「**建议转法务起草**」，不在 memo 里代拟——代拟条款
属律师工作，本技能守住这条线。

### 第 8 步：后果门（按结论分级，对应 G5）

- 结论含 🔴：memo 首页明示「**本协议不提交签署流程、不向相对方作出任何
  承诺**」，按 G5 生成「带给律师的一页 brief」，非律师用户到此停止。
- 结论 🟢 且用户为非律师：进入签署流程前，按 G5 动作闸门——显式确认用户
  知悉签署的法律后果并获得明确指令（「继续」之外的含糊回应不算），同时
  生成「带给律师的一页 brief」供律师快速复核；用户不给明确指令的，维持
  待确认状态，不放行。
- 结论 🟡：逐条给出修改建议或「建议转法务起草」，改完可重新过一遍本技能。

### 第 9 步：收尾登记

- 协议含保密期限、自动续期或终止后存续条款的：提示并经用户同意后调用
  `renewal-tracker`，把关键日期写入 contracts/renewal-register.yaml。
- memo 中所有条文引用过一遍 legal-core 的 `citation-audit`（G10）；未核验
  的保持 [CITE:__] 占位，FAIL 状态不得外发。
- 审查过程产物（memo 各版本）按 matter-workspace 的版本规则保存；已发给
  相对方的任何版本永不覆盖、永不删除。
- 向用户复述后果门结果与下一步选项，确认其理解——尤其非律师用户，复述
  是 G5 显式确认的前置动作。

## 输出模板

```markdown
【保密标头：按 G4 二选一——律师「保密·内部法律分析」/ 非律师
「研究备忘——不构成法律意见，使用前请经执业律师复核」】

# NDA 审查 memo：<协议名称>

## Reviewer note
- 来源：<文本来源；画像立场 [已确认—日期，是否经律师审定]>
- 已读：<全文 / 指定范围>
- 标记：结论 🔴 不得推进 / 🟡 需修订或需人判断 / 🟢 可推进；
  单项 = 法律风险轴（🔴🟠🟡🟢）× 商业摩擦轴（阻碍/拖慢/费解/无感）
- 时效：<法律状态核查日期；未核验写"未核验">
- 使用前注意：<去向限制（内部/可外发）；非律师用户注明
  "本 memo 不是法律意见">

## 执行摘要
<若是藏条款 NDA，第一行必须是：本协议名为保密协议，实际含有 XX 条款>
<三句话以内：立场（披露方/接收方/双方）、总体结论、最关键的一件事>
<机械性一行修改清单；需要起草新语言的只写"建议转法务起草">

## 标记项
| # | 条款位置 | 问题 | 法律风险轴 | 商业摩擦轴 | 建议改法 | 依据 |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | 第 X 条 | <问题> | 🔴/🟠/🟡/🟢 | 阻碍/拖慢/费解/无感 | <一行修改 或 "建议转法务起草"> | [CITE:__] |

## 通过项（简表）
<符合 playbook 的条款，一行一条>

## FYI
<偏离市场惯例但合法的记录>

## [需复核] 清单
<全文内联 [需复核] 项的汇总（G8）>

## 下一步
<按第 8 步后果门的决策树展开>
```

## 常见误判与边界提示

以下情形容易误判，审查时先排除：

1. **把保密协议当「简单文件」快审放过**：NDA 常被当作签前例行文件，但
   藏条款（第 4 步 Scope check）恰恰最喜欢藏在「简单文件」里。本技能
   不允许跳过 Scope check 的「快审」。
2. **劳动合同/入职文件中的保密条款**：那是劳动关系下的保密义务，不按本
   技能审查；涉及竞业限制补偿与期限的法定要求 [模型知识—待核实]，提示
   走劳动法律师渠道。本技能只审独立民事主体之间的保密协议。
3. **主交易合同中的保密条款**：保密条款只是主合同的一章时，不路由到本
   技能（路由看主要权利义务结构，见 contract-review 第 2 步）；该章按
   `risk-clause-database` 第 7 类检查即可。
4. **「双方互负」文本下的实质单向披露**：文本对等不等于风险对等；业务
   实质只有一方披露时，按披露方视角从严（第 2 步）。
5. **把依法或应监管要求的披露当违约**：法定披露通常属例外情形；条款把
   法定披露也写成违约的，是 🟡 起步的标记项。
6. **期限起算点陷阱**：保密期限以「协议终止日」起算的，存续期可能被主
   合作期无限拉长——起算点是独立检查点，不与期限长短混为一谈。
7. **投标/入围文件捆绑的保密承诺**：投标文件中夹带的保密承诺，实质是
   单方 NDA 且几乎没有谈判空间；按本技能审查，同时提示「不接受可能
   影响投标资格」的商业摩擦（商业摩擦轴：阻碍），由业务负责人拍板。
8. **集团内关联公司间的保密安排**：同一集团内部流转不代表没有保密义务
   边界；主体不同即独立法人，条款仍按常规六项检查，只是立场判定与摩擦
   评估按内部交易处理。

**组合判断提示**（第 6 步分桶的补充）：单条看不严重的条款，组合起来可能
构成 🔴——典型如接收方视角下「定义极宽 + 例外极少 + 期限极长 + 赔偿
无上限」的组合。分桶时先看组合、再看单项。

## 本技能不做什么

- 不代拟保密协议条款或修改稿语言——需要起草的一律「建议转法务起草」。
- 不凭默认值给 🟢：playbook 未经律师审定时，结论天花板是 🟡。
- 不对藏条款（竞业、排他、许可、不招揽）装没看见——命中必 auto-🟡 并
  明示。
- 不设硬编码阈值（几年期限算长、多少赔偿算高），一切比对画像/playbook
  立场。
- 不替用户决定产物去向；去向不明按仅内部处理。
- 不处理 🔴 事项的后续（不出绕行方案，生成律师 brief 后停止）。
- 不做法律意见陈述：对非律师用户的全部输出受 G5 UPL 门控。
- 不直接手改画像：现场取得的立场经 `customize` 写回。

## 收尾与下一步

1. memo 交付后按第 8 步后果门分流：🔴 停止并转律师；🟡 修订后复审；
   🟢 走 G5 显式确认 + 律师 brief。
2. 含期限/续期条款 → `renewal-tracker` 登记 contracts/renewal-register.yaml。
3. 全部引用过 `citation-audit`；需要核验条文原文的经 `statute-verify`
   （核验通过后以 [已确认—日期] 标注填入）。
4. 用户需要给业务方看的版本 → `contract-summary`（Quiet mode，去掉立场
   与底线信息；上游严重度只作下限，降级须声明理由——G9）。
5. 进入多轮谈判的，提示经 `matter-workspace` 建档，后续每轮修改挂同一
   事项 slug，版本按 drafts/ 规则递增。
6. 审查中发现画像 NDA 立场缺失或覆盖不全的，提示用户经 `customize` 完善
   playbook——playbook 越完整、且经律师审定，未来审查给出 🟢 的空间越大；
   这也是本插件「越用越准」的积累路径。

