品牌故事库构建器
把访谈与案例整理成可复用、可溯源的品牌故事单元。
技能明确要求将输入视为不可信、尊重用户数据使用权、标记未验证证据、保存前请求确认，并通过提案机制限制注册表写入；未见恶意、凭据窃取或破坏性默认行为。扣7分：仍涉及写入故事库、claims/narrative 事件和开放事项，权限边界、用户确认点、回滚方式及实际授权运行时未在本技能内完整说明，外部公开材料确认还可能向 Firecrawl 发送 URL。
触发条件、输入、输出、停止规则和异常分支（缺少 pillars 时 NEEDS_INPUT、缺少张力时排除故事）较清楚，且依赖标准注册表流程。扣12分：本次仅静态阅读，未执行复现；关键引用文件、registry-events.py 和运行环境行为未在选定文件中验证，授权提案失败、写入失败和格式错误的诊断反馈不足。
目标用户、输入材料、故事类型、输出结构、非适用范围及上下游技能均有明确声明；无连接器也可使用用户粘贴材料，并有中英双语元数据。扣3分：中文支持主要体现在标签和描述，实际工作指令与输出模板没有完整中文规范；对不同主机和中文用户数据格式的边界说明有限。
前置元数据完整，版本为18.0.0，许可证明确，Quick Start、契约、数据源、步骤、保存规则、引用材料和下一技能齐全，信息分层良好。扣5分：缺少本技能专属 changelog、维护负责人和更新路径；引用较多仓库内文件但未提供其内容，且 SECURITY.md 的支持版本仍写17.x，与本技能18.0.0存在治理信号不一致。
技能给出了可直接套用的故事单元字段、弧线结构、pillar/claim 映射、证据标签和交接目标，理论上能产出可复用故事库。扣8分：静态评估不能验证实际产出；核心结果依赖既有 message house、brand voice、claims ledger、用户有权使用的材料和可用注册表流程，缺少这些输入时不能完成，且仍需人工审阅事实、权利和叙事质量。
文件提供了明确的证据标签规则、claims ledger 映射、proposal 事件路径、仓库版本和部分 CI/测试材料，具备一定审计线索。扣5分：提供的测试主要覆盖架构和通用审计验证器，并未覆盖本技能的故事分类、映射、权限确认或提案路径；没有第三方执行证据或独立复现结果，因此仅给静态上限5分。
- 仅凭静态文件无法确认 registry-events.py 的授权、失败处理或回滚是否实际有效。
- 不要把 User-provided 或 Measured 标签当作事实 substantiation；claims registry 仍需独立裁决。
- 使用公开客户材料前应确认授权、隐私和第三方抓取边界；Firecrawl 会产生数据外发风险。
- 技能版本为18.0.0，但安全策略显示当前支持线为17.x，需在安装前确认版本治理状态。
这个 Skill 能做什么，适合哪些场景？
Story Bank Builder 面向已有消息屋和品牌声音的团队，整理起源、创始人、客户、转型与证据故事。它把每个故事绑定到一个消息屋支柱和 claims ledger ID，并为每条证据标注 Measured、User-provided 或 [needs source]。输出是故事库文档，而不是最终长文案、消息屋或品牌语调规范。它适合需要让网站、销售材料和社交渠道复用同一套有来源故事的团队。
读取用户提供的访谈记录、案例笔记、客户推荐语和输赢材料，以及消息屋支柱、品牌声音和只读的 claims ledger；将原始材料拆分为起源、创始人、客户、转型和证据故事；为每个单元撰写一句 premise 和 situation→tension→change→outcome 弧线，绑定一个支柱与相关 claim ID；标注每条证据的来源状态，列出 [needs source] 缺口，并按授权流程向 registry-events.py 提交未核实证据的 propose 请求；最终生成故事库和标准交接摘要。
- 品牌策略团队已有消息屋和支柱，需要把创始故事与客户案例整理成可复用素材。
- 市场团队拥有访谈和推荐语，但需要将不同材料拆成独立的起源、客户和转型故事。
- 内容团队准备跨网站、销售演示和社交渠道复用同一批有来源的证明故事。
- 团队发现某些故事缺少可核实证据，需要在发布前集中标记并提交待审核项目。
这个 Skill 有哪些优点和局限？
- 按固定故事弧线整理真实访谈、案例和推荐语，便于下游复用。
- 每个故事绑定一个消息屋支柱和 claim ID，支持来源追踪。
- 明确区分 Measured、User-provided 和 [needs source]，不会把未核实数字当作事实。
- 不要求连接器；可使用用户粘贴的数据运行。
- 依赖已经存在的消息屋支柱、品牌声音和 claims ledger，不能独立完成品牌定位。
- 不会判断证据是否真实；未核实证明必须交给 offer-claims-registry。
- 不会产出完成的长篇文案、案例页面或 proof module。
- 涉及公共客户材料的确认时可调用 Firecrawl 等连接器，网络与授权条件会增加流程复杂度。
如何安装这个 Skill？
安装整个仓库：在 Claude Code 中运行 /plugin marketplace add aaron-he-zhu/aaron-marketing-skills，再运行 /plugin install aaron-marketing@aaron；兼容 Agent Skills 的通用主机可运行 npx skills add aaron-he-zhu/aaron-marketing-skills，也可直接 git clone https://github.com/aaron-he-zhu/aaron-marketing-skills。仓库未提供独立于集合之外的安装步骤。
如何使用这个 Skill？
确认已有消息屋支柱和品牌声音后，使用例如：Build a story bank for [product] from these customer interviews and case notes: [paste]. Tag each story to a pillar. 或 Assemble our origin, founder, and transformation stories and map each proof point to a claims-ledger ID. 若没有支柱，技能应停止并转交 message-system-architect。交付后会询问是否保存结果；未经确认不应写入 memory。
这个 Skill 与同类方案有什么区别？
与 message-system-architect 相比，它消费消息屋和支柱，而不是创建它们；与 content-writer 相比，它产出结构化故事素材，而不是成稿；与 offer-claims-registry 相比，它记录和提交证据缺口，但不裁定证明是否成立；与 narrative-cascade-planner 相比，它先建立故事库，后者再把故事映射到各个渠道。