需要撰写或标准化红人/达人合作简报时…

适用于为单个或多个红人/达人创建、标准化、复用或收紧 campaign 简报，涵盖 TikTok、Instagram、YouTube 等平台内容。

适用场景

解决思路

1. 收集简报输入：活动/产品/平台/交付物/关键信息/CTA/时间线/报酬，以及适用的 `creator_ref`、`brand_ref`、`page_ref`、`shipping_ref`、`contact_ref`、`voice_source_ref`；把 HOT 指针解析到实际源记录。
2. 读取 `memory/projections/narrative.json`、`memory/projections/claims.json` 及相关 creator/channel 投影；在指定 offset 读取 Narrative/claims 投影。
3. 保持原始 creator/brand 名称与 handle、页面/素材文件夹 URL、收货地址、联系人姓名/邮箱/电话、hashtag、promo code、voice-source locator 仅为临时渲染/派发输入，不持久化。
4. 若需要创作者声音，按 `references/creator-voice-intake.md` 做 reference-safe intake。
5. 起草前读取已接受的 Narrative 和 claims 投影；检查 claim approval 上下文：audience、market、media、offer window、required disclaimer 必须匹配。
6. 无可用 canon 时只允许生成明确批准的 exploratory brief，绝不标记为 creator-ready/on-canon。
7. 填充 master template，并按平台调优；关键信息来自已接受 canon 和 context-valid claims。
8. 对未解决措辞标记 `[needs source]`；为每个 unresolved claim 提供精确的 `registry-events.py operation: propose` 请求以另行授权；在解决前阻止 creator-ready 状态。
9. 按 content-type 和 campaign-type 应用变化：按平台调整重点（TikTok hook/sounds、IG Reels/Stories/Feed、YouTube integration/Shorts），按活动类型调整（launch、review、event、ambassador、giveaway）；参考 `references/brief-templates.md#brief-variations-by-content-type`。
10. 确保简报覆盖全部必需部分：overview、key messages、deliverables、creative direction、timeline、compliance、compensation、contact。
11. 明确说明披露要求和 usage rights；用户已提供输入的地方不得保留占位符。
12. 核对交付物和数量与用户按平台要求一致。
13. 核对关键信息来自 accepted Narrative canon，claims 为 context-valid 或 visibly blocked，并存在 dependency tuple。
14. 默认内联返回 reference-safe creator brief。
15. 仅在获得 exact authorization 后保存到 `memory/influencer/brief-generator/YYYY-MM-DD-<topic>.md`；写入 canon/version/claims-offset 字段，并仅使用上述 opaque refs。
16. 已保存产物和 handoff 仅用 `creator_ref`、`brand_ref`、`page_ref`、`shipping_ref`、`contact_ref`、`brand_asset_ref`、`hashtag_ref`、`promo_code_ref`、`voice_source_ref` 表示 creator、brand、落地页、收货地、联系路径、素材、hashtag、promo terms、voice provenance；绝不持久化原始 identity/address/URL/contact/content 值或隐藏映射。
17. 每个 unresolved-claim proposal 都是单独的 exact `operation: propose` 授权；brief-save approval 不覆盖它。
18. 持久化 creator、channel、claim 或 campaign facts 时，只作为单独授权的 proposal 路由到其 owning registry；不要自动写 HOT 或 canonical views。
19. 生成 Handoff Summary：按 `skill-contract.md §Handoff Summary Format` 输出标准形状，包括 Narrative/claims dependency tuple；必填 `narrative_canon_id`、`narrative_canon_version`、`claims_projection_offset`、`dependency_status: verified | approved-fallback | blocked`，以及适用的 opaque refs；不要包含其 raw resolved values。
20. 准备投递但不要暗示已发送：`Send`、「deliver」、「share with creators」请求或标签只创建 pending outreach handoff，不授权 delivery。
21. 将简报交给 `outreach-manager`；仅在 delivery job 内临时解析 raw recipient/brand/page/contact values。
22. 通过 outreach 的 exact single-touch gate：独立批准 exact `recipient_ref`、channel、final rendered message/brief payload、一个 concrete ISO-8601 `dispatch_at` 加 timezone（若排期）；在 provider call 前立即运行 fresh eligibility 和 live-suppression checks。
23. 任何 recipient、channel、payload 或 schedule 变化都需要新的 approval。
24. 简报是 guidelines 不是 scripts：尊重创作者 voice，同时固定 key messages 和 compliance terms。
25. 无必需 live integrations：直接向用户索取 campaign details、deliverables、key messages、timeline、compensation 等输入即可端到端生成完整简报。
26. 可选 connectors 仅在可用时用于 enrichment：`~~influencer database` 临时解析 creator details 但保存/handoff 仅保留 `creator_ref` 和 opaque evidence refs；`~~social platform analytics` 确认当前平台格式规格和最佳表现帖子长度；`~~CRM` 获取分配的 `contact_ref` 和 prior brief versions，仅在授权 dispatch 时解析 raw contact details。
27. 若没有可用 connector，参考 `CONNECTORS.md` 的已验证免费/keyless recipe per category；但无一为必需。
28. 简报定义交付物后，主下一技能使用 `budget-optimizer` 决定创作者和平台之间的花费分配。
29. 若简报暴露新的交付物需求，交替使用 `campaign-planner` 重新规划 campaign scope；仅在其 exact single-touch authorization/preflight 后，用 `outreach-manager` 向选定创作者投递完成后的简报。
30. 维护 visited-set；若推荐技能本次会话已调用，停止并报告 chain-complete，而不是重跑；任何 handoff chain 最多 depth 3。

适用边界 · 注意事项

• 不适用于决定如何在多个创作者之间分配预算/花费；该场景应使用 budget-optimizer。
• 不适用于替代完整法律合同条款与合同审阅；需要法律条款时使用 contract-helper。
• 没有可接受的 Narrative/claims canon 时，不应生成 creator-ready/on-canon 简报；只能做明确批准的 exploratory brief。