mcpField
T
terms-of-service

terms-of-service

github.com/shawnpang其他371370 次安装32 周前更新
代码仓库

关于 terms-of-service

面向创始人的服务条款撰写技能,可用于产品上线、条款更新和风险审视。它按产品与受众识别风险,并提供条款结构、可执行性提示及呈现建议。

主要功能

  1. 01评估产品范围与受众
  2. 02识别产品相关责任风险
  3. 03按章节起草服务条款
  4. 04标记司法辖区可执行性问题
  5. 05提供条款展示与变更建议

适用场景

  1. 01为新产品上线准备服务条款
  2. 02功能或商业模式变化后更新条款
  3. 03检查责任限制和可接受使用政策
  4. 04处理企业客户条款协商前的准备

安装

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

$npx skills add https://github.com/shawnpang/startup-founder-skills --skill terms-of-service

安装后在 Claude Code 中输入/terms-of-service确认已加载。

详细介绍

服务条款

适用场景

当创始人需要为产品发布制定服务条款、更新现有条款以反映新功能或商业模式的变化,或评估当前条款是否充分保护公司时启用。用户询问可接受使用政策、责任限制或用户协议结构时,也应启用。

所需上下文

  • 来自 startup-context: 产品类型、平台、商业模式、定价结构、目标客户(B2B 还是 B2C)、目标市场、公司法律实体及其司法管辖区。
  • 来自用户: 产品的功能、用户与产品的交互方式、用户是否会创建或上传内容、产品是否集成第三方服务、付款/订阅结构、过往争议或已知风险领域,以及目标用户中是否包含会协商条款的企业客户。

工作流

  1. 范围评估——确定产品类型(SaaS、市场、API、移动应用)和受众(消费者、中小企业、企业)。这将决定条款的语气、可执行性处理方式,以及哪些条款不可或缺。
  2. 风险识别——梳理该产品特有的关键责任情形:数据丢失、服务中断、用户生成内容问题、集成故障、账单争议。
  3. 起草条款——使用下方模板撰写各个部分。采用通俗易懂的语言,同时确保措辞精准严谨。避免不必要的术语,同时保证条款具有可执行性。
  4. 可执行性审查——标记在某些司法管辖区可能无法执行的条款(例如,欧盟对一概排除责任的条款有限制,某些州和国家限制强制仲裁)。
  5. 呈现建议——建议条款的呈现方式(点击同意式还是浏览即同意式)、版本管理策略,以及如何通知用户条款变更。

输出格式

一份包含以下章节的服务条款文档。

章节模板
  1. 同意条款 — 说明如何表示接受(建议使用点击确认方式)、年龄要求,以及是否有权代表组织作出约束性承诺。
  2. 服务说明 — 说明产品的功能、不作出哪些保证,以及适用时的服务等级。
  3. 账户注册与安全 — 说明账户创建要求、用户对凭证的责任,以及账户共享政策。
  4. 可接受使用政策 — 列出禁止的活动(滥用、抓取、逆向工程、非法使用、竞争性基准测试)。内容应与产品具体相关。
  5. 用户内容与数据 — 说明谁拥有用户上传的内容、公司运营服务所需的许可授权,以及终止后如何处理数据。
  6. 数据所有权与可移植性 — 明确客户数据归客户所有。说明导出功能和格式。
  7. 知识产权 — 公司保留平台、商标和专有算法的所有权。用户获得使用服务的有限许可。
  8. 付款与账单 — 说明订阅条款、计费周期、价格变更通知期限、退款政策,以及付款失败时的处理方式。
  9. 免费试用与免费增值 — 说明免费套餐的具体条款、试用结束后的转付费预期、功能限制,以及试用期到期后的数据保留方式。
  10. 服务可用性与 SLA — 说明正常运行时间承诺(或无此承诺)、计划维护窗口以及不可抗力情形。
  11. 责任限制 — 规定赔偿上限(通常不超过此前 12 个月已支付的费用),并排除对后果性/间接损失的赔偿责任。
  12. 赔偿 — 用户应就滥用、内容违规以及因用户使用服务而产生的第三方索赔向公司作出赔偿。
  13. 终止 — 说明任一方如何终止协议、终止后如何处理数据(保留期限、删除时间表)以及继续有效的条款。
  14. 争议解决 — 说明适用法律、管辖权,以及适用时的仲裁条款和集体诉讼豁免条款。
  15. 条款修改 — 说明如何通知变更、通知期限(建议 30 天),以及继续使用服务如何视为接受变更。
  16. 其他事项 — 可分割性、完整协议、转让、弃权、通知。

框架与最佳实践

通俗易懂的写法
  • 使用非法律专业人士也能理解的语言,说明客户的义务和权利。
  • 始终统一使用“你”和“我们”,并在开头一次性定义。
  • 段落要简短;列举禁止活动时使用项目符号。
  • 将影响最大的条款(责任上限、自动续订、仲裁)加粗或突出显示。
  • 在每个章节旁设置“关键条款摘要”侧栏或标题,用一句通俗易懂的话解释该章节。
SaaS 特定注意事项
  • 数据所有权不容妥协。 客户数据必须明确归客户所有。公司仅获得提供服务所需的许可。
  • 汇总/匿名化数据。 如果你将客户数据汇总用于分析、基准测试或模型训练,应明确披露,并确保数据确实无法识别个人身份。
  • API 条款。 如果提供 API,应说明速率限制、身份验证要求,以及对再分发 API 输出内容的限制。
  • 集成责任。 明确说明,公司不对第三方集成,或应用户指示传递给第三方服务的数据负责。
  • 子处理商。 列出子处理商(托管、支付、分析)或提供相关链接。企业客户通常会对此有所期待。
可执行性保障措施
  • 点击确认优于浏览即同意。 要求用户采取肯定操作(勾选复选框、点击按钮)以接受条款。浏览即同意(“使用本网站即表示您同意”)的可执行性较弱。
  • 醒目披露。 在许多司法管辖区,仲裁条款、自动续订条款和责任限制必须醒目展示,才具有可执行性。
  • 消费者保护限制。 欧盟和英国的消费者法限制不公平条款。对于消费者,全面排除过失责任通常不可执行。
  • 自动续订法律。 加州(ARL)、FTC 指南和欧盟消费者指令要求清楚披露自动续订,并提供便捷的取消方式。
  • 单方面修改。 法院越来越严格地审查“我们可随时更改这些条款”之类的条款。应提供合理的通知期(30 天),并允许用户在不同意时终止服务。
B2B 与 B2C 的区别
  • B2B: 预计会就责任上限、SLA、赔偿和数据处理条款进行协商。应准备好企业版附加协议。
  • B2C: 消费者保护法的保护力度更大。仲裁可能受到限制,也可能适用冷静期。
  • 混合模式(自助式 B2B): 从标准条款开始,但应建立流程,允许企业客户通过主服务协议申请修改。

相关技能

  • privacy-policy — 必须一并起草。条款应引用隐私政策中的数据处理做法。定义(如“个人数据”)应保持一致。
  • contract-review — 企业客户对你的条款提出修订时,使用 contract-review 评估他们提出的修改。

示例

示例 1:B2B SaaS 产品

用户:“我们即将推出一个 B2B 分析平台,提供免费增值层级和每月起价为 $49 的付费套餐。我们需要服务条款。”

优质输出摘录:

6. 数据所有权与可移植性

您的数据归您所有。我们不对您提交给本服务的任何数据、内容或信息(“客户数据”)主张所有权。您授予我们一项有限的、非独占的许可,仅用于提供和改进本服务的客户数据。

您可以随时通过控制面板的导出功能,以 CSV 或 JSON 格式导出客户数据。您的账户终止后,我们将保留客户数据 30 天,以便您取回;之后,我们会从活动系统中永久删除这些数据,并在 90 天内从备份中移除。

我们可能会生成有关平台使用情况的汇总匿名统计数据(“汇总数据”),且无法据此识别您或任何个人用户。汇总数据归我们所有,我们可将其用于基准分析、研究和产品改进。

示例 2:包含用户生成内容的市场平台

用户:“我们的平台允许自由职业者销售数字模板。我们需要涵盖买家和卖家的条款。”

良好输出摘录:

5. 用户内容

**卖家:**您保留对所上传的所有模板和数字资产(“卖家内容”)的所有权。在平台上发布卖家内容,即表示您授予我们一项非独占、全球范围内的许可,允许我们在运营市场平台时展示、分发和推广您的卖家内容。您移除内容 30 天后,该许可终止,但买家已购买的副本除外。

**买家:**购买后,您获得的许可仅限于按照卖家的许可条款使用模板。您不会取得相关知识产权的所有权。除非卖家的许可明确允许,否则禁止转售、重新分发或再许可已购买的模板。

**我们的责任:**我们不会预先审核卖家内容。我们是平台,而非出版方。不过,对于违反本条款或适用法律的内容,我们保留将其移除的权利。


**免责声明:**此技能仅用于教育和规划目的,可生成服务条款草案,不构成法律建议。服务条款必须根据您的具体产品、业务模式和适用司法管辖区进行调整。条款的可执行性因司法管辖区而异,也取决于向用户呈现条款的方式。发布最终服务条款前,务必请合格的律师进行审查。

评论

支持 Markdown