promote

promote skill 概览

promote 的作用

promote skill 会把 Claude 在自动记忆中反复出现、已经被验证有效的行为，提升为明确的项目规则。它不是让有用模式继续埋在 MEMORY.md 里，而是帮助你把这些内容迁移到 CLAUDE.md、.claude/rules/<topic>.md，或全局 Claude instruction file 中，让后续会话能够稳定遵循同一行为。

最适合自我改进型 Claude 工作流

当你的团队已经允许 Claude 从纠正、偏好和反复出现的项目约定中学习，但现在需要把其中某条经验固定下来时，就适合使用 promote。它尤其适合 Context Engineering 场景：MEMORY.md 用来记录观察和经验，而规则文件定义 agent 必须可靠遵守的行为。

好的例子包括：“这个 repo 里始终使用 pnpm”、“API handlers 必须验证输入”，或“billing code 的测试必须包含这些 fixtures”。不适合的例子包括一次性偏好、尚未达成共识的争议，或还没有在实际使用中验证过的规则。

promote skill 的实用价值

这个 skill 不只是一个复制粘贴提醒。它提供的是一套决策流程：明确模式、找到支持它的 memory 条目、选择正确的目标文件、写出可执行的规则，并在原始 memory 中保留 promotion 说明。重要之处在于，难点并不是编辑 markdown，而是判断某条 memory 是否值得永久执行，以及这条规则应该放在哪里。

如何使用 promote skill

promote 安装与仓库阅读路径

使用下面的命令从 GitHub skill collection 安装：

npx skills add alirezarezvani/claude-skills --skill promote

然后先阅读 SKILL.md。当前这个 repository path 是通过单个文件暴露 promote 工作流的，因此没有额外的 helper scripts、references 或 rule templates 需要检查。这让上手更简单，但也意味着在重要 repo 上使用前，你应该仔细查看命令示例和 target-selection table。

实际如何调用 promote

推荐的触发方式是 /si:promote，后面跟上你想固定下来的模式：

• /si:promote use pnpm instead of npm
• /si:promote API handlers need validation --target rules/api.md
• /si:promote tests for auth changes must include session expiry cases --target rules/testing.md --paths "src/auth/**/*.ts"

这个 skill 会先确认你指的具体行为是什么。如果请求比较含糊，它应该提出一个澄清问题，例如这条规则是全局适用，还是只适用于某些路径。然后它会在项目的 Claude auto-memory 文件 ~/.claude/projects/.../memory/MEMORY.md 中搜索相关条目，展示匹配结果，并确认这些 memory 是否足以支持这次 promotion。

把粗略目标变成高质量 prompt

较弱的 prompt 是：“promote our testing preference”。更好的 promote 使用方式，会同时给出行为、证据、范围，以及已知的目标文件：

/si:promote "When changing billing code, add regression tests for failed payment and retry paths" --target rules/testing.md --paths "src/billing/**/*.ts"

这样效果更好，因为 skill 可以写出可执行的规则，而不是模糊的偏好。建议包含：

• Claude 应该遵循的准确行为
• 这条规则适用于整个项目、特定文件类型，还是所有项目
• 如果规则有范围限制，提供示例路径
• 证明该模式有用的 memory 片段或具体事件

合并规则前的建议流程

promote 起草或修改规则后，要像审查生产配置一样审查它。确认这条指令简短、可验证，并且没有超出证据所支持的范围。对于项目级行为，CLAUDE.md 通常比较合适。对于更窄的行为，优先使用带路径范围的 .claude/rules/<topic>.md。如果是跨 repository 的个人约定，只有在该模式确实普遍适用时，才应使用全局 Claude instruction file。

promote skill 常见问题

promote 是用于 Context Engineering，还是普通 prompting？

promote 对 Context Engineering 最有价值，因为它把“观察到的行为”到“持久指令”的路径正式化了。普通 prompt 可以让 Claude 在一次会话中记住某件事；promote 则帮助判断这条学习是否应该成为 repo operating context 的一部分。

什么时候不应该使用 promote？

不要把 promote 用在未经验证的想法、临时 workaround、与团队规范冲突的个人口味，或本应放进 application code、tests、linters、CI 的指令上。规则在指导 agent 行为时很有用；但如果它变成可执行约束的替代品，就会带来风险。

这和手动编辑 CLAUDE.md 有什么不同？

手动编辑当然可行，但很容易跳过证据和范围判断。promote skill 增加了一套可重复的流程：找到 memory、确认目标行为、选择正确目的地，并留下 memory 已被 promoted 的痕迹。这样可以减少规则膨胀，也能帮助后来的维护者理解这条指令为什么存在。

promote 适合新手吗？

适合，前提是用户已经知道自己的 Claude project memory 和 rule files 放在哪里。新手可以从一个清晰的项目级模式开始，使用 --target claude.md，在熟悉 .claude/rules/ 约定之前，先避免使用 scoped path rules。

如何改进 promote skill 的效果

用更充分的证据提升 promote 结果

promote skill 在 source memory 足够具体时效果最好。调用前，先收集能证明规则必要性的准确 memory 条目、纠正记录或重复失败案例。“Claude keeps using npm” 比较弱；“In three sessions Claude ran npm commands, but this repo uses pnpm and has no package-lock.json.” 这样的证据更强。

避免常见的 promotion 失败

最常见的失败是过度 promotion：把一个很窄的观察提升成全局命令。另一个问题是写出听起来不错但不可执行的规则，例如 “write better tests”。更好的规则会明确触发条件、必需动作和适用范围：“For src/api/**/*.ts, validate request bodies before calling service functions.”

在第一版生成规则后继续迭代

拿到第一版 promote 输出后，继续检查这条规则是否过宽、过于模糊，或已经在别处重复出现。然后再细化。实用的后续 prompt 包括：

• “Make this rule enforceable in one paragraph.”
• “Narrow this to only API route files.”
• “Add one example and one non-example.”
• “Check whether this belongs in CLAUDE.md or .claude/rules/testing.md.”

维护健康的规则系统

好的 promote 指南应该避免规则层变得嘈杂。定期检查已经 promoted 的规则，关注冲突、过时约定，以及本应迁移到 tooling 中的指令。最理想的 promote 结果不是更多 markdown，而是因为 Claude 在正确范围内获得了正确的持久上下文，重复纠正变少了。