已有基准报告、模式表或受众证据时，将其转化为有依据的…

在已有验证过的基准研究后，用于证据到执行的策略交接。

适用场景

解决思路

1. 确认输入为已验证证据，例如 benchmark reports、master tables、pattern tables、strategy tables、comment analyses 或 performance findings。
2. 对于结构化 artifact，确认输入 JSON 包含 `corePromise`、`hookOptions`、`workflow`、`sourceFacts` 和 `sourceBasis`。
3. 确保所有产出都基于可用证据。
4. 不要虚构：无来源依据的目标人群、与 benchmark 措辞矛盾的 hooks、无支持的产品声明、数据中未反映的受众动机。
5. 如果证据不完整，分开标注：`Observed from sources`、`Inference`、`Open question`。
6. 使用已提供或用户明确标识的最小充分证据集。
7. 优先使用结构化 artifacts：final report、strategy table、pattern table、master table，然后是 comment summaries。
8. 在提出建议前提取事实：winning lanes、重复的 hook shells、重复的结构类型、视觉格式倾向、用户语言模式、强示例。
9. 将事实映射到 brief 字段：source artifact、benchmark ids 或 examples、为什么该模式适合产品、正在测试的变量。
10. 保持每个概念狭窄：一个问题、一个 hook family、一个格式、一个测试变量。
11. 在调整 hooks 时保留 benchmark 语言，除非用户要求变体测试。
12. 返回 execution object：brief、concept list、hook set、script input 或 approved copy。
13. 对每个推荐，回答：要切掉什么问题？
14. 对每个推荐，回答：复用了什么 hook shell？
15. 对每个推荐，回答：属于哪个内容 lane？
16. 对每个推荐，回答：正在测试什么变量？
17. 对每个推荐，回答：哪些来源证据支持它？
18. 对每个推荐，回答：什么声明或受众动机只是推断？
19. 当所需的用户意图、来源证据或自有输入 artifacts 缺失，且猜测会改变结果时，停止。
20. 返回常见输出之一：campaign brief、concept candidates、hook library、lane prioritization、AB test matrix。
21. campaign brief 必须包含字段：`objective`、`priorityLanes`、`personaConstraints`、`approvedHookFamilies`、`prohibitedDirections`、`variablesToTest`、`sourceBasis`。
22. concept candidate 必须包含字段：`conceptId`、`problemToCut`、`hookType`、`hookDraft`、`targetLane`、`formatType`、`whyThisFits`、`sourceBasis`、`testVariable`。
23. 避免模糊想法，如 “make a productivity video”。
24. 避免复制 benchmark 内容而不适配具体产品变量。
25. 避免将具体 benchmark 语言改写成抽象品牌声明。
26. 避免将原始研究当作执行就绪，而没有 brief 或 concept object。
27. 避免将原始研究直接传入发布。
28. 返回结构化输出或明确的证据阻塞。
29. 仅将明确的 execution objects 移交给 script review、asset generation workflows 或 content packaging。
30. 从用户输入中选择最小匹配命令或工作流并直接运行。

适用边界 · 注意事项

• 任务是没有来源证据的 greenfield brainstorming。
• 用户需要最终 scripts：此技能不写最终脚本，应返回 script-ready brief 并发送到人工 script review gate。
• 用户需要视觉生成：此技能不做视觉生成，应在证据支持的 brief 存在后移交给 asset generation workflows。