起草或审查红人合作协议时…

当合作已达成原则性共识、需要起草或审查红人/达人合作协议条款时使用。

适用场景

解决思路

1. 收集合同参数：捕获 party_ref、contact_ref、address_ref、signature_ref 以及合作细节（活动、期限、交付物、报酬）和附加条款（使用权、独家、审批、平台）；原始身份/联系方式/地址/签名输入仅作临时使用，用 references/templates.md §1 的收集表。
2. 起草协议：填写 11 节框架（范围、报酬、使用权、独家、审批、合规/FTC、保证、保密、赔偿、终止、杂项+签名）；参考安全的 WARM 摘要与仅外部使用的执行副本模板分开放在 references/templates.md §2；按交易规模缩放章节，小交易可删除白名单/广泛独家条款。
3. 解释关键条款：对每个实质性条款说明其覆盖内容、为何重要、需注意什么；条款指南见 references/templates.md §3。
4. 审查并标记：对任何收到的合同文本运行清单——必要条款是否齐全、红旗条款、逐条应对；绝不使用内置的期限、修改次数、周转时间或付款条件作为默认值；数值应对必须由用户提供或绑定到有来源日期、司法/市场兼容的锚点，否则标记为 TBD/NEEDS_INPUT；清单与表格见 references/templates.md §4-5。
5. 准备并授权电子签名执行：将完整可执行协议保留在外部电子签名/文档系统中，对最终文档字节计算 SHA-256，展示确切的 recipient_ref、文档哈希和交付渠道；发送签名是外部变更，需要绑定该元组的独立精确授权；起草、法律审查、WARM 保存、HOT 提升或先前的发送批准都不覆盖它；仅在授权提供商调用内解析原始收件人/联系人/地址；若任何文档字节、收件人或渠道变化，丢弃批准并请求新授权；元组或授权缺失时不得上传、路由或发送。
6. 签名后路由：若不存在最终创作者就绪简报，移交给 brief-generator；若简报已存在，继续创作者履约；当提交到达时，将其冻结版本交给 creator-content-auditor 进行修改/审批；仅当有效权利覆盖预期用途时，才将审计员批准的冻结资产路由到 content-amplifier；Spark/boost 路径额外需要匹配的已发布帖子，dark-post 路径则不需要；不要仅因协议已签署就跳过履约或内容门。
7. 内联返回起草的协议或审查备忘录；在确切的 WARM 保存路径提供仅参考的条款摘要；绝不将电子签名执行副本放在那里；任何 HOT 提升前单独询问。
8. 条款签署后，为通过 registry-events.py 向 memory/events/creators.ndjson 发送一行 operation: propose 更新（使用权窗口、独家范围、最终费率）请求另一项精确授权，供 creator-registry 核对；起草、签署、保存和签名交付是四个不同的授权面，互不授权。
9. 若已存在授权的轻量活动跟踪器，提议记录 stage: contracted 并将已签协议放入 evidence_refs；该 WARM 更新需要自己的精确保存授权且非权威。
10. 若简报已最终确定，不要仅为延长链条而调用另一个规划技能：将已签约简报交给创作者履约，在授权时记录后续提交，仅在内容提交后调用审计员。

适用边界 · 注意事项

• 合作尚未达成原则性共识、仍处于外联谈判阶段时——应使用 outreach-manager。
• 没有法律顾问审查前不要直接执行合同；本技能仅提供通用指导与模板。
• 缺少精确授权或 recipient_ref + 文档 SHA-256 + 渠道元组时，不要上传、路由或发送签名请求。