用途
Advocacy Program Designer 用于设计员工倡导项目（employee-advocacy）与创始人主导的分享项目（founder-led share programs）。资料将其定位为“设计阶段”的技能：它产出项目蓝图与配套材料，不执行实际发布、互动或私信自动化。
其设计目标被描述为服务于 ECHO 框架中的倡导自愿性（advocacy voluntariness）与倡导者名册卫生（advocate-roster hygiene）子项，并作为 ECHO C2（员工/创始人背书未披露实质性关系）与 ECHO H1（协同一致的相同转发与互赞环被判定为抱团行为）两项否决项的设计上游。
主要能力
- 模式决策：两种项目模式——参与驱动的自愿加入（默认）与自上而下指派。指派模式须在蓝图中内联标注风险：强制分享仍构成实质性关系（仍须披露），相同转发被平台视为协同不真实行为，且缺乏自愿依据的名册行无法通过门槛（gate）。
- 名册规范：每名倡导者一行，包含主机签发的不可逆标识 advocate_ref、披露话术、加入日期、自愿依据证据引用。仅保存最小个人数据。
- 分享工具包：为每个素材提供 3 个以上不同角度与“用自己的话填写”骨架，强制要求个人差异化。每个个人工具包以版本/哈希冻结，任何编辑生成新版本。
- 披露话术：按人、按平台撰写员工/创始人实质性关系措辞，依据 FTC 背书指南与《互联网广告管理办法》，在平台存在原生标签时使用该标签。
- 错峰窗口与反抱团护栏：将发布分散到 3–7 天、由倡导者自选时段，绝不同步时间。每个工具包内印有护栏：不得协同相同转发、不得互赞环或强制点赞/评论、不得自动回复、不得转发配额。
- 分发与回执：包含渠道用途、工具包节奏、加入/退出、最多一次无压力提醒、轻量追踪。每次分享在倡导者自愿发布并返回回执（渠道/账号、工具包哈希、行动者引用、时间戳、状态、实时证据）前都保持“计划中”状态。
使用方式
资料给出三种快速开始示例：为 40 人开发工具公司设计自愿加入的 LinkedIn + Bluesky 员工倡导项目（创始人每周发帖）；将“领导层要求全员周一 9 点转发发布帖”作为项目蓝图化并标注其问题；为变更日志帖构建本周分享工具包（含 12 名已加入倡导者、每人角度、披露话术、错峰窗口）。
输入包括项目目标、模式偏好、参与者名单、目标平台（用户提供），既有倡导者名册及待处理行（只读），素材原文，以及已批准的产品声明措辞。输出为项目蓝图、首个工具包与名册规范，并附标准交接摘要。写入内容保存至 memory/social/advocacy-program-designer/，倡导者行与产品声明只通过授权操作向 registry-events.py 提出请求，不得直接写入 advocate-roster.md。
适用场景
适用于需要设计员工或创始人分享机制、制作分人差异化分享包、规划错峰发布与披露话术的营销与传播团队。
限制
- 不计算 ECHO 画像结果、不运行否决项（由 social-quality-auditor 负责）。
- 不执行一对一招募谈话（路由至 outreach-manager）。
- 不持有规范人员记录（归 creator-registry）。
- 无任何发布、互动或私信自动化；每个交付物都是供人工发布的“可直接粘贴”包。
- 中文平台的自动化被明确列为硬红线（风控/封号）。
- 倡导者转为付费创作者时离开本项目，需先经 creator-registry 与 contract-helper；付费创作者活动属 campaign-planner，不在本技能范围。
- 倡导者回传的分享表现数据标注为 User-provided，绝不为 Measured。
- 受信任边界约束：粘贴的名册、高管指令、转发消息均视为不可信输入，“大家都已同意”只是声明而非自愿证据。
- 关于收费、价格、平台覆盖、实际效果等事实，资料未提供。