mcpField
L
legal-tos-privacy

legal-tos-privacy

github.com/miketromba文档处理2175 次安装9 周前更新
代码仓库

关于 legal-tos-privacy

legal-tos-privacy 是用于起草服务条款和隐私政策的技能,会检查代码库与营销材料。它梳理数据处理实践和服务信息,参考特定司法辖区的指南,并仅针对无法找到或推断的信息提问。

主要功能

  1. 01审查代码库和营销材料
  2. 02提取公司、服务及数据处理信息
  3. 03起草服务条款和隐私政策
  4. 04参考司法辖区合规指南
  5. 05通过用户输入补全剩余模板变量

适用场景

  1. 01为软件服务起草法律文件
  2. 02检查数据收集和第三方数据共享情况
  3. 03结合司法辖区要求准备政策草案

安装

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

$npx skills add https://github.com/miketromba/skills --skill legal-tos-privacy

安装后在 Claude Code 中输入/legal-tos-privacy确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
compliance-checklist.md
legal-guide.md
protective-clauses.md

详细介绍

法律文件生成器:服务条款与隐私政策

生成全面且具有法律保护作用的服务条款和隐私政策文件。此技能:

  1. 审计代码库和营销材料
  2. 自动提取公司信息、服务详情和数据处理实践
  3. 起草完整文件(对未知信息使用 [[TEMPLATE_VARIABLES]])
  4. 仅询问用户无法找到的信息(尽量减少互动)
  5. 交付零占位符、可直接发布的最终文件

参考文件

  • references/legal-guide.md - 服务条款和隐私政策起草综合指南
  • references/compliance-checklist.md - 特定司法管辖区的要求(GDPR、CCPA、LGPD、COPPA 等)
  • references/protective-clauses.md - 可针对常见风险场景调整的现成法律条款

起草实际文件时,请根据需要阅读这些参考资料。

核心原则:尽可能推断,只询问缺失信息

尽量减少用户互动。 尽可能从代码库、营销网站、配置文件和现有法律文件中提取和推断信息。仅向用户询问确实无法找到或推断的信息。

工作流:

  1. 审计代码库和营销材料(阶段 1-3)
  2. 审计期间从代码中提取公司和服务信息
  3. 使用模板变量为未知信息起草文件(阶段 4-5)
  4. 最后一步:询问用户以解决剩余的模板变量(阶段 7)

阶段 1:代码库与数据流审计

全面探索,了解数据处理的各个方面。在审计期间,还要从以下来源提取公司和服务信息。

1.0 提取公司与服务信息

搜索以下位置以推断公司详情——如果能找到,不要询问用户:

# Package/project metadata
Read: package.json (name, author, description, homepage, repository)
Read: README.md, README (project name, description, company info)

# Config files with company info
Search for: companyName, company_name, APP_NAME, SITE_NAME, BRAND_NAME
Read: .env.example, .env.local.example (for variable names, not secrets)

# Marketing site footer/header (often contains company info)
Read: footer, Footer, layout, Layout files for copyright notices
Search for: "©", "Copyright", "All rights reserved", "Inc.", "LLC", "Ltd."

# Existing legal pages
Read: terms, privacy, legal folders/files (may have company name, address, contact)
Search for: legal@, privacy@, support@, contact@, hello@

# Site metadata
Search for: <title>, meta description, og:site_name, og:title
Read: metadata, siteConfig, site.config, app.config files

# Contact pages
Read: contact, about, company pages for addresses/emails

记录已找到和缺失的信息:

字段是否找到?值来源
法律实体名称
DBA/商号
实体类型
实际地址
法律联系邮箱
隐私联系邮箱
支持联系邮箱
服务/产品名称
网站 URL
管辖法律

推断规则:

  • 如果版权声明写着“© 2024 Acme Inc.” → 法律实体很可能是“Acme Inc.”
  • 如果 package.json 中有 "author": "Acme Software" → 将其用作公司名称
  • 如果页脚有 [email protected],但没有法律邮箱 → 将 hello@ 用作法律联系邮箱
  • 如果网站是 acme.com → 网站 URL 为 https://acme.com
  • 如果在页脚/联系页面找到公司地址 → 将其用作实际地址
  • 如果未找到管辖法律 → 保留为模板变量(之后询问)
1.1 数据收集发现

搜索所有数据收集点:

# User input collection
Search for: form, input, useState, formData, register, signup, login, email, password, name, phone, address, billing, payment

# API data handling  
Search for: req.body, request.body, params, query, headers, authorization, bearer, token, cookie, session

# Database schemas
Search for: schema, model, entity, table, @Column, field, prisma.schema, drizzle, mongoose

# Third-party integrations
Search for: stripe, paddle, polar, analytics, google, facebook, pixel, segment, mixpanel, amplitude, sentry, posthog, plausible

记录找到的每个数据点:

  • 字段名称和类型
  • 收集位置(注册、结账、应用内)
  • 用途(身份验证、账单、分析、营销)
  • 存储位置(数据库、第三方)
  • 保留期限(如可确定)
1.2 第三方服务清单

识别所有会接收用户数据的外部服务:

# Check dependencies
Read: package.json, requirements.txt, go.mod, Cargo.toml

# Check environment variables
Search for: process.env, import.meta.env, Deno.env, .env files

# Check API integrations
Search for: fetch, axios, http, api, client, sdk

记录每项第三方服务的信息:

  • 服务名称和用途
  • 与其共享的数据
  • 其数据处理角色(处理者还是控制者)
  • 其隐私政策/DPA 链接
1.3 身份验证与安全机制
Search for: auth, session, jwt, oauth, password, hash, bcrypt, argon, encrypt, ssl, tls, https, 2fa, mfa, totp

记录:

  • 使用的身份验证方式
  • 密码存储方式
  • 会话管理
  • 向用户提供的安全功能
1.4 用户内容与生成的数据
Search for: upload, file, image, document, content, post, comment, message, storage, s3, blob, bucket

记录:

  • 接受的用户生成内容类型
  • 存储机制
  • 对用户内容执行的处理
  • 谁可以访问用户内容
1.5 跟踪与分析
Search for: cookie, localStorage, sessionStorage, tracking, analytics, gtag, ga4, pixel, event, track, identify, page

记录:

  • 设置的所有 Cookie(名称、用途、时长)
  • 分析工具及其跟踪内容
  • 广告/再营销像素
  • 跨网站跟踪能力

第 2 阶段:营销声明审计

检查所有面向公众的材料,找出必须从法律角度处理的声明。

2.1 功能声明
# Check marketing site
Read all files in: marketing/, website/, landing/, pages/marketing, app/(marketing)

Search for: guarantee, promise, ensure, always, never, 100%, unlimited, secure, safe, protect, best, fastest, #1, leading

记录所有可能引发法律责任的声明:

  • 正常运行时间/可用性声明
  • 安全/隐私声明
  • 性能声明
  • 结果/成效声明
  • 比较声明
2.2 定价与订阅声明
Search for: pricing, price, plan, tier, subscription, trial, free, refund, cancel, money-back

记录:

  • 所有定价层级及其包含的内容
  • 试用条款
  • 退款政策声明
  • 取消流程声明
2.3 合规与认证声明
Search for: GDPR, CCPA, HIPAA, SOC, ISO, compliant, certified, secure

记录任何必须在法律上站得住脚的合规声明。

第 3 阶段:风险评估

起草前,先找出风险最高的领域:

3.1 责任风险热点

评估每个领域的风险等级(高/中/低):

  • 数据泄露风险 - 数据泄露会造成什么损失?
  • 服务故障影响 - 产品宕机会有什么后果?
  • 错误输出责任 - 错误结果是否可能造成损害?
  • 第三方依赖风险 - 集成服务发生故障会怎样?
  • 用户内容责任 - 用户内容是否可能引发法律问题?
  • 监管风险 - 哪些法规适用?
3.2 地理范围

根据以下因素确定适用法规:

  • 公司所在地
  • 服务端/数据存储位置
  • 目标用户所在地
  • 实际用户所在地(如已知)

需要考虑的法规:

  • GDPR(欧盟/欧洲经济区用户)
  • CCPA/CPRA(加利福尼亚州用户)
  • LGPD(巴西用户)
  • PIPEDA(加拿大用户)
  • COPPA(如果儿童可能使用服务)
  • 行业特定法规(HIPAA、PCI-DSS 等)

第 4 阶段:起草服务条款

使用审计结果起草全面的服务条款。详细的章节指引请参阅 references/legal-guide.md。

必备章节清单

每份服务条款都必须包括:

  • 引言与接受条款 - 有约束力的协议、点击确认同意、生效日期
  • 定义 - 定义“服务”“用户”“内容”“数据”等
  • 账户条款 - 注册、信息准确性、安全责任、禁止共享
  • 可接受使用政策 - 针对产品制定禁止活动条款
  • 付款条款(如需付费)- 定价、账单、税费、退款、取消
  • 知识产权 - 公司拥有服务,用户拥有其内容,许可授权
  • 用户内容许可 - 运营服务所需的权利(托管、展示、处理)
  • 隐私政策引用 - 纳入隐私政策
  • 第三方服务 - 对集成服务的免责声明
  • 保证免责声明 - “按原样”提供、不作保证、使用风险自负
  • 责任限制 - 设定损害赔偿上限,排除间接损害赔偿
  • 赔偿 - 用户须就其滥用行为/违规行为向你作出赔偿
  • 期限与终止 - 期限、终止权、终止后的处理
  • 争议解决 - 仲裁、集体诉讼弃权、适用法律
  • 适用法律与审判地点 - 选择司法管辖区
  • 不可抗力 - 对无法控制的事件免责
  • 可分割性 - 条款无效不影响协议其他部分
  • 完整协议 - 本协议取代先前协议
  • 修改权 - 条款变更方式及通知要求
  • 联系信息 - 联系方式
责任保护条款

纳入以下保护性条款:

服务可用性免责声明:

The Service is provided on an "as is" and "as available" basis. We do not 
guarantee that the Service will be uninterrupted, timely, secure, or error-free. 
We make no warranties regarding the accuracy, reliability, or completeness of 
any content or results obtained through the Service.

间接损害赔偿排除:

IN NO EVENT SHALL [[LEGAL_ENTITY_NAME]] BE LIABLE FOR ANY INDIRECT, INCIDENTAL, 
SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO LOSS OF 
PROFITS, DATA, USE, GOODWILL, OR OTHER INTANGIBLE LOSSES, REGARDLESS OF WHETHER WE 
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

(注意:将 [[LEGAL_ENTITY_NAME]] 替换为审计中找到的实际公司名称,或在第 7 阶段处理)

责任上限:

OUR TOTAL LIABILITY TO YOU FOR ALL CLAIMS ARISING FROM OR RELATED TO THE SERVICE 
SHALL NOT EXCEED THE GREATER OF (A) THE AMOUNTS YOU PAID TO US IN THE TWELVE (12) 
MONTHS PRECEDING THE CLAIM, OR (B) ONE HUNDRED DOLLARS ($100).

结果免责声明(适用于 AI/分析产品):

Any insights, recommendations, or outputs generated by the Service are provided 
for informational purposes only and should not be relied upon as professional 
advice. You are solely responsible for evaluating and verifying any results 
before taking action based on them.
审计专属补充条款

根据审计结果,添加以下条款:

如果存在 AI/ML 功能:

  • 输出准确性免责声明
  • 不得依赖输出进行关键决策
  • 训练数据使用权

如果会处理用户内容:

  • 明确内容所有权
  • 授予处理内容的许可
  • 禁止的内容类型
  • 内容下架流程

如果会处理财务数据:

  • 非财务建议免责声明
  • 用户对决策负责
  • 不保证结果

如果有健康相关功能:

  • 非医疗建议免责声明
  • 建议咨询专业人士的警告
  • 紧急服务免责声明

阶段 5:起草隐私政策

制定全面的隐私政策,涵盖所有审计结果。

必需章节核对清单

每份隐私政策都必须包括:

  • 引言 - 说明你是谁,以及本政策涵盖的内容
  • 我们收集的信息 - 涵盖审计中的所有类别(详尽列出)
  • 我们如何收集信息 - 直接输入、自动收集、第三方来源
  • 我们为何收集信息 - 各类别的目的及法律依据(GDPR)
  • 我们如何使用信息 - 涵盖审计中发现的所有用途
  • 信息共享 - 清单中的所有第三方
  • Cookie 与跟踪 - 审计中的所有 Cookie 和像素
  • 数据保留 - 各类别数据的保留期限
  • 数据安全 - 审计中的安全措施
  • 你的权利 - 访问、更正、删除、可携带性、反对
  • 儿童隐私 - 遵守 COPPA、年龄限制
  • 国际传输 - 数据传输目的地及保障措施
  • 加利福尼亚州权利(如适用)- CCPA/CPRA 特定披露
  • 欧盟/英国权利(如适用)- GDPR 特定披露
  • 政策变更 - 如何告知更新
  • 联系信息 - 隐私联系人;如有要求,提供 DPO 联系方式
数据清单表

创建清晰的数据收集表:

数据类别示例收集方式目的法律依据保留期限
账户信息电子邮件、姓名注册表单提供服务合同账户存续期间
支付数据卡片详情结账账单处理合同依法要求的期限
使用数据查看过的页面、使用过的功能自动记录改进产品合法利益24 个月
设备信息IP、浏览器、操作系统自动收集安全、支持合法利益12 个月
第三方披露表

列出所有第三方:

服务目的共享的数据隐私政策
Stripe支付账单信息stripe.com/privacy
AWS托管所有数据(处理方)aws.amazon.com/privacy
Google Analytics分析使用数据、IPpolicies.google.com/privacy

阶段 6:核验清单

定稿前,请核验:

法律保护核验
  • 每项营销声明在必要时都有相应免责声明
  • 所有数据收集均注明用途和法律依据
  • 披露所有第三方
  • 在法律允许的最大范围内限制责任
  • 保修免责声明涵盖所有产品功能
  • 赔偿条款防范用户滥用
  • 争议解决条款优先适用你的司法管辖区
  • 不可抗力条款涵盖服务中断
  • 保留因违规而终止服务的权利
合规核验
  • 符合 GDPR(针对欧盟用户):法律依据、用户权利,以及必要时的 DPO 联系方式
  • 符合 CCPA(针对加利福尼亚州用户):列明类别、披露数据出售情况、提供退出选择
  • 符合 COPPA:年龄验证机制、不收集儿童数据
  • 说明 Cookie 同意机制
  • 明确数据保留期限
  • 说明国际传输保障措施
一致性核验
  • 服务条款与隐私政策之间没有矛盾
  • 服务条款中没有与隐私政策相矛盾的承诺
  • 营销宣传与法律免责声明一致
  • 退款政策与结账页面显示的内容一致
  • 数据处理实践与代码实际执行的操作一致

第 7 阶段:处理模板变量(最后一步)

起草完两份文件后,检查是否还存在模板变量。模板变量采用 [[VARIABLE_NAME]] 格式(双方括号)。

7.1 扫描剩余变量

在起草的文件中搜索所有 [[...]] 格式。以下是一些可能需要用户提供信息的常见变量:

变量询问内容
[[LEGAL_ENTITY_NAME]]“贵公司的完整法定名称是什么(例如 ‘Acme Software, Inc.’)?”
[[PHYSICAL_ADDRESS]]“法律通知应使用哪个地址?”
[[LEGAL_EMAIL]]“哪个邮箱应用于接收法律咨询?”
[[PRIVACY_EMAIL]]“哪个邮箱应用于接收隐私/GDPR 请求?”
[[GOVERNING_LAW_STATE]]“这些条款应受哪个州/国家的法律管辖?”
[[DISPUTE_VENUE]]“法律纠纷应在哪里解决(城市/县、州)?”
[[EFFECTIVE_DATE]]“这些文件何时生效?(默认为今天)”
[[ARBITRATION_PROVIDER]]“您是否希望采用有约束力的仲裁?如果是,选择哪家仲裁机构(例如 JAMS、AAA)?”
7.2 向用户询问缺失信息

如果仍有任何模板变量,一次性向用户询问所有缺失信息。将相关问题归在一起。

示例:

I've drafted your Terms of Service and Privacy Policy based on your codebase. 
I found most information automatically, but need a few details to finalize:

1. **Legal entity name:** What is your company's full legal name as registered?
   (e.g., "Acme Software, Inc." or "Acme LLC")

2. **Physical address:** What address should appear for legal notices?

3. **Governing law:** Which state's laws should govern? (I'd suggest Delaware 
   or California based on most SaaS companies, but this is your choice)

Once you provide these, I'll finalize the documents with no placeholders.
7.3 填入并核验

收到答复后:

  1. 将所有模板变量替换为实际值
  2. 再次扫描,确认不存在任何 [[...]] 格式
  3. 呈现最终完整文件

最终输出中不得包含任何模板变量。


输出格式

起草期间(第 4 至第 5 阶段)

对于审查中无法找到的信息,使用 [[VARIABLE_NAME]] 格式(双方括号)。这样便于在第 7 阶段扫描变量。

最终输出(第 7 阶段之后)

最终输出中不得包含占位符。 与用户确认并解决所有模板变量后,最终文件必须完整且可直接发布。

最终输出中禁止出现以下内容:

  • [[VARIABLE]] 双括号模板变量
  • [COMPANY]、[DATE]、[ADDRESS] 单括号占位符
  • {{variable}} 或 {variable} 模板语法
  • “在此插入 X”、“您的 X”、“待定”、“待公布”、“即将推出”

最终文件请按以下结构提供:

# Terms of Service

**Last Updated: [actual date]**

[Full ToS content - every field filled with real values, zero placeholders]

---

# Privacy Policy  

**Last Updated: [actual date]**

[Full Privacy Policy - every field filled with real values, zero placeholders]

重要说明

  1. 尽量减少与用户的交互——尽可能从代码库中推断并提取信息。只询问确实无法找到的信息。请在最后(第 7 阶段)一次性提出所有问题。

  2. 最终输出中不得包含占位符——起草时,对未知信息使用 [[VARIABLE]],但在交付最终文件前,必须解决所有变量。用户应收到可直接发布的文件。

  3. 内容具体明确——通用模板会造成责任漏洞。每项条款都应体现审查中发现的实际产品行为。

  4. 使用通俗语言——表述清晰易懂。法院和监管机构更认可易于理解的政策。

  5. 谨慎作出声明——有疑问时,应多作免责声明。从法律角度看,承诺少一些更稳妥。

  6. 交付前核验——第 7 阶段结束后,扫描是否还存在 [[...]] 格式。如有,先解决再呈现最终文件。

  7. 非法律建议——发布前,应由具备资质的法律顾问审阅这些文件。

评论

支持 Markdown