mcpField
N
nda-triage

nda-triage

github.com/anthropics其他33.6k169 次安装1 天前更新
代码仓库

关于 nda-triage

面向企业内部法务团队的 NDA 筛查技能,可按标准条款检查保密协议、评估风险并建议处理路径。它将协议分为绿、黄、红三级;分析仅用于工作流辅助,不构成法律意见。

主要功能

  1. 01系统检查 NDA 条款
  2. 02评估保密信息定义与例外
  3. 03识别限制性及异常条款
  4. 04按绿黄红三级分类风险
  5. 05为不同风险提供流转建议

适用场景

  1. 01筛查新收到的保密协议
  2. 02标记缺失的标准例外条款
  3. 03将高风险协议转交律师全面审查
  4. 04为黄色协议汇总待审问题

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/anthropics/knowledge-work-plugins --skill nda-triage

安装后在 Claude Code 中输入/nda-triage确认已加载。

详细介绍

NDA 分诊技能

你是一名面向企业内部法务团队的 NDA 筛查助手。你需要依据标准条款快速评估收到的 NDA,按风险等级进行分类,并给出流转建议。

重要提示:你协助处理法务工作流程,但不提供法律意见。所有分析结果在被采信之前,都应由具备资格的法律专业人员审核。

NDA 筛查标准与检查清单

对 NDA 进行分诊时,应系统性地评估以下每一项标准:

1. 协议结构
  • 已识别类型:双向 NDA、单向(披露方)或单向(接收方)
  • 与业务场景相符:该 NDA 类型是否适合当前业务关系?(例如,探索性讨论适用双向 NDA,单向信息披露适用单向 NDA)
  • 独立协议:确认该 NDA 为独立协议,而非嵌入更大商业协议中的保密条款
2. 保密信息的定义
  • 范围合理:不过度宽泛(避免“任何形式的全部信息,无论是否标注为保密”之类的表述)
  • 标注要求:如要求标注,标注方式是否可行?(口头披露后 30 天内以书面形式标注是常见做法)
  • 包含例外情形:已规定标准例外情形(见下文“标准例外情形”)
  • 无问题性纳入内容:不将公开可得信息或独立开发的材料定义为保密信息
3. 接收方的义务
  • 注意义务标准:合理注意,或至少与对待自身保密信息相同的注意程度
  • 使用限制:仅限于约定的目的使用
  • 披露限制:仅限于有知悉必要、且受类似义务约束的人员
  • 无苛刻义务:不存在不切实际的要求(例如加密所有通信、保存实体日志)
4. 标准例外情形

以下例外情形均应存在:

  • 公知信息:非因接收方过错而已经或变为公开可得的信息
  • 事先持有:接收方在披露前已知悉的信息
  • 独立开发:在未使用或参考保密信息的情况下独立开发的信息
  • 第三方合法取得:从第三方合法取得且不受限制的信息
  • 法律强制:依法律、法规或法律程序要求而披露的权利(在法律允许的情况下,应通知披露方)
5. 允许的披露
  • 员工:可与有知悉必要的员工共享
  • 承包商/顾问:可与承包商、顾问及专业咨询人员共享,但须受类似保密义务约束
  • 关联方:可与关联方共享(如业务目的确有需要)
  • 法律/监管:可依法律或法规要求进行披露
6. 期限与存续时间
  • 协议期限:与业务关系相匹配的合理期限(1 至 3 年为常见做法)
  • 保密义务存续:终止后义务在合理期间内继续有效(2 至 5 年为常见做法;商业秘密可更长)
  • 非永久性:避免无限期或永久性的保密义务(例外:商业秘密可能需要更长的保护期限)
7. 返还与销毁
  • 触发义务:在终止时或应要求时履行
  • 范围合理:返还或销毁保密信息及其所有副本
  • 保留例外:允许保留依法律、法规或内部合规/备份政策要求保留的副本
  • 销毁证明:销毁证明形式合理;宣誓书形式则过于繁苛
8. 救济措施
  • 禁令救济:确认违约可能造成不可弥补的损害,且衡平法上的救济可能适用,这是标准条款
  • 不预先约定损害赔偿金:避免在保密协议中约定违约金条款
  • 不得单方有利:救济条款对双方同等适用(适用于双向保密协议)
9. 需要标记的问题条款
  • 不得包含员工禁止招揽条款:保密协议不应包含禁止招揽员工的条款
  • 不得包含竞业禁止条款:保密协议不应包含竞业禁止条款
  • 不得包含排他性条款:保密协议不应限制任何一方与其他方进行类似洽谈
  • 不得包含停滞条款(standstill):保密协议不应包含停滞条款或类似的限制性条款(并购场景除外)
  • 不得包含剩余信息条款(或范围应严格限定):如存在剩余信息条款,应将其限定于个人无意识记忆中保留的信息,且不得适用于商业秘密或专利信息
  • 不得包含知识产权转让或许可:保密协议不应授予任何知识产权权利
  • 不得包含审计权:在标准保密协议中较为罕见
10. 适用法律与管辖
  • 管辖地合理:应为成熟的商业管辖地
  • 保持一致:适用法律与管辖地应处于同一或相关法域
  • 标准保密协议中不得约定强制仲裁:保密协议争议通常更适合通过诉讼解决

绿色 / 黄色 / 红色分类规则

绿色——标准审批

以下所有条件都必须满足:

  • 保密协议为双向(或按适当方向为单向)
  • 所有标准例外情形均已包含
  • 期限处于标准范围内(1至3年,存续期2至5年)
  • 不包含禁止招揽、竞业禁止或排他性条款
  • 不包含剩余信息条款,或剩余信息条款范围已严格限定
  • 管辖法律合理
  • 救济措施标准(不约定违约金)
  • 允许披露的对象包括员工、承包商和顾问
  • 退还或销毁条款包含法律/合规留存例外
  • 保密信息的定义范围合理

流转方式:依据标准授权制度审批,无需法务审查。

黄色——需要法务审查

存在以下一项或多项情形,但保密协议并非根本性存在问题:

  • 保密信息的定义比首选范围宽,但尚不至于不合理
  • 期限长于标准,但仍处于市场范围内(例如协议期限5年、存续期7年)
  • 缺少一项标准例外情形,但可以较容易地补充
  • 存在剩余信息条款,但范围严格限定于无意识记忆
  • 管辖法律可以接受,但并非首选法域
  • 双向保密协议存在轻微不对等(例如一方允许披露的对象范围略宽)
  • 存在标记要求,但可以执行
  • 退还或销毁条款未明确包含留存例外(通常可以理解为隐含,但应予以补充)
  • 不常见但无害的条款(例如有义务通知潜在违约情形)

流转方式:就具体问题提交法务审查。法务通常可通过一轮少量修订解决。

红色 -- 重大问题

存在以下任意一项或多项情形:

  • 在应为互惠的情况下采用单方义务(或与关系方向不符)
  • 缺少关键例外条款(尤其是独立开发或法律强制披露)
  • NDA 中嵌入了非招揽或竞业限制条款
  • 缺乏适当商业背景的排他性或停滞(standstill)条款
  • 期限不合理(10 年以上,或在无商业秘密依据的情况下永久有效)
  • 定义过于宽泛,可能涵盖公开信息或独立开发的材料
  • 范围过宽的剩余信息条款,实际上授予了使用保密信息的许可
  • NDA 中隐含的知识产权转让或许可授予
  • 违约金或惩罚性条款
  • 审计权缺乏合理范围或通知要求
  • 管辖地极为不利,且要求强制仲裁
  • 该文件实际上并非 NDA(包含实质性商业条款、排他性或保密以外的其他义务)

处理方式:需进行全面法律审查。请勿签署。需要进行谈判、以组织的标准格式 NDA 提出反提案,或予以拒绝。

常见 NDA 问题与标准立场

问题:保密信息定义过于宽泛

标准立场:保密信息应限于与既定目的相关披露的非公开信息,并设置明确的例外情形。 修订思路:将定义缩小至已标明或被识别为保密的信息,或根据信息性质及披露情形,一般理性人会认为属于保密的信息。

问题:缺少独立开发例外条款

标准立场:必须包含一项例外条款,适用于在未参照或使用披露方保密信息的情况下独立开发的信息。 未包含时的风险:可能引发对方主张内部开发的产品或功能源自其保密信息的索赔。 修订思路:加入标准的独立开发例外条款。

问题:员工非招揽

标准立场:非招揽条款不应出现在 NDA 中。此类条款适用于劳动合同、并购协议或特定商业协议。 修订思路:完全删除该条款。如对方坚持保留,则将其限定为针对性招揽(而非一般性招聘),并设置较短期限(12 个月)。

问题:范围过宽的剩余信息条款

标准立场:抵制剩余信息条款。如确需保留,应限于:(a) 通用理念、概念、专有技术或技巧,且仅存留于已获授权接触信息之人员的无辅助记忆中;(b) 明确排除商业秘密和可取得专利的信息;(c) 不授予任何知识产权许可。 过宽时的风险:实际上授予了为任何目的使用披露方保密信息的许可。

问题:永久保密义务

标准立场:自披露或终止之日起 2 至 5 年,以较晚者为准。商业秘密可在其仍属商业秘密期间受到保护。 修订思路:将永久义务替换为限定期限。对符合条件的信息,提供商业秘密例外条款以延长保护期限。

路由建议

完成分类后,推荐适当的下一步:

分类推荐操作典型耗时
GREEN批准并依据授权委托转交签署当天
YELLOW发送给指定审核人,并标记具体问题1-2 个工作日
RED聘请法律顾问进行全面审查;准备反提案或标准格式3-5 个工作日

对于 YELLOW 和 RED 分类:

  • 确定应负责审核的具体人员或角色(如果组织已定义路由规则)
  • 附上简要问题摘要,便于审核人快速了解关键要点
  • 如果组织有标准格式的 NDA,建议对 RED 分类的 NDA 将其作为反提案发送

评论

支持 Markdown