技能介绍

问题在哪

多技能、多轮会话的营销项目里，关键词、竞品、达人、广告账户和已拍板决策会散落在对话与各类技能输出中。没有分层记忆时，要么每次 Session 重讲一遍上下文，要么把整库笔记塞进系统提示，很快撞上 token 与注意力上限；审计结论、开放事项和术语也容易和「当前战役事实」混在一起。

技能如何工作

本技能在仓库 memory/ 下实现 HOT / WARM / COLD 三层温度模型，覆盖 SEO/GEO、达人、付费广告与邮件等营销域。

HOT：memory/hot-cache.md 上限约 80 行 / 25KB，由 SessionStart 钩子自动注入会话摘要（经脱敏），承载当前优先级、核心关键词、竞品与进行中的战役要点。
WARM：按技能按需加载的专题记忆（如 memory/decisions.md、memory/open-loops.md、各域子目录）。
COLD：memory/archive/ 及历史审计/监控数据，仅在显式查询或回溯时读取。

生命周期只依赖可观测规则：用户或技能显式「promote / pin」才升温；按 last_updated 做降级与归档，不靠引用计数。典型流程包括：初始化目录结构 → 按 hot-cache → glossary → archive 的查找链解析指代 → 分析后写回热缓存与开放环 → 月度/季度归档。与审计类技能衔接时，在用户确认「Save these results?」后，可将结构化块写入 memory/audits/YYYY-MM.md；Stop 钩子不会自动落盘。

决策门禁：memory/decisions.md 中 approved_by 非 user 的条目视为 ADVISORY，审计类技能不得当作终局依据。热缓存超限时 PostToolUse 会告警，由 Agent 负责修剪建议，而非静默截断。

边界与注意

memory purge 仅处理工作区内的匹配行/文件，并记录 memory/audits/gdpr-purges.md；若 memory/ 在 Git 中，历史提交仍需用户自行 git filter-repo 等，技能不声称完整擦除。
写入第三方个人信息前，用户需自行确认 GDPR/CCPA 等法律依据；删除请求必须人工确认匹配范围，禁止自动全库删除。

截图预览

使用场景

新开 SEO/GEO 或付费战役时，在仓库按 State Model 初始化 `memory/` 并把优先级关键词、竞品与 live offer 写入 `hot-cache.md`。
完成排名检查或竞品分析后，按查找链确认 hero 词含义，并回写热缓存与 `memory/monitoring/rank-history/` 等监控文件。
审计类技能产出终稿后，在用户明确同意保存时，将结构化结论追加到 `memory/audits/YYYY-MM.md`，而非依赖 Stop 钩子落盘。
热缓存超过 80 行或 25KB、或 WARM 文件 `last_updated` 超过 90 天时，执行晋升/降级与 `memory/archive/` 归档并汇报受影响路径。

适合人员

串联 keyword-research、rank-tracker 与 content-quality-auditor 的 SEO 负责人，需要跨会话固定 hero 词、竞品与 `approved_by: user` 的决策。
维护多广告账户与 offer 变体的付费投放，要求 live offers 留在 HOT、历史素材按温度规则沉入 archive。
统筹达人 registry、邮件 consent 与月度汇总的营销运营，要同步 `open-loops.md`、glossary 与各域 `memory/influencer/`、`memory/email/` 写入。
在 `memory/entities/` 存过创始人或记者个人信息、需对 Art 17 请求执行 grep 确认、`purge` 脱敏并写 `gdpr-purges.md` 的项目负责人。