memory-loader Skill：给 AI 记忆加控制层

最开始为了让 AI 更懂任务，最直接的办法是把背景、规则、模板和经验都写进 skill。它短期有效，但长期会把 skill 变成难维护的知识容器。

• skill 既要负责触发和执行，又要携带大量知识。
• 经验越沉淀，单个 skill 越重，修改成本越高。
• 知识被写死在执行入口里，不利于长期治理和跨场景复用。

Personal Knowledge Harness 解决了记忆分散，但也带来新的控制问题：当 skill、知识卡和原文材料都在增长时，AI 如果一股脑读取，反而会被上下文淹没。

• 上下文不是越多越好，弱相关材料会稀释当前任务主线。
• 旧经验如果没有边界，容易把已经过期的口径带进新任务。
• 记忆系统必须有控制层，否则“沉淀越勤”会变成“召回越乱”。

当 skill 变多后，第一件事不是让所有 skill 常驻，而是做一个隐藏的 loader：只有用户点名或任务匹配时，才去真实目录里发现和加载对应 skill。

• 活跃 skill 清单不再被当成本机完整能力清单。
• 低频 skill 按需发现，避免每次对话都带上全部说明。
• 这一步先控制的是“能力入口”，不是知识卡片。

隐藏 skill 解决了按需加载，但你又发现 Claude、Codex、OpenClaw 各自有 skill 目录，同一套自建能力没法稳定共享。于是共享 skill 目录成为第二层控制。

• 自研高频 skill 的真值源收敛到共享目录。
• 各 agent 入口通过共享源暴露，避免同名 skill 多处漂移。
• 这一步解决的是“能力是否一致”，不是“知识该读多少”。

skill 共享后，知识开始进入 Obsidian 三层体系。比如产品文档领域会沉淀模板、审查经验、spec-readiness、门禁规则，但一次 PRD 任务并不需要把所有卡片都塞进上下文。

• 领域变清楚，不代表每次都全量加载这个领域。
• 同一任务域下也要区分当前问题类型、阶段和证据需求。
• 知识卡片要服务任务判断，而不是证明知识库很完整。

下一步是把索引机制做成控制层：先判断任务属于哪个领域，再按问题类型选择少量卡片。索引不再只是列文件，而是告诉 agent 何时加载什么、不要加载什么。

• 根 README 负责领域选择，任务域 README 负责问题路由。
• 索引要写加载条件，而不是堆“当前有哪些卡”。
• 当索引变成目录时，就会重新制造上下文爆炸。

memory-loader / knowledge-context-pack 的价值不是替代 PRD、竞品、报价或复盘，而是在这些产出型 skill 前面先生成最小充分上下文包。

• 先解析当前任务，再决定主域、辅助域和候选上下文。
• 最终只加载 2-5 张正式卡、1-3 条能力层规则和少量必要原文证据。
• 同时说明未加载什么和原因，让“不读”也成为可审查的决策。

这个 skill 不直接写 PRD、不做竞品、不出报价、不做阅读追问。它站在这些工作流前面，帮它们决定该带哪些知识进入任务。

• prd-skill 需要它加载需求文档规则，而不是全量产品知识。
• competitive-analysis 需要它区分分析框架和实时事实。
• weekly-retro 和 reading-dialogue 需要它控制沉淀、候选和入库门禁。

memory-loader 的价值不是让 AI 记住更多，而是让 AI 在正确时间读取正确记忆。它把 Personal Knowledge Harness 从“有很多知识”推进到“知识能被稳定调用”。

• 当前形态是个人 AI 记忆控制 workflow。
• 团队复用潜力在于把知识库、skill 和多 agent 入口变成可治理的加载协议。
• 产品化方向可以是组织级 AI 记忆路由器、上下文包生成器或知识库召回控制台。