promote
作者 alirezarezvanipromote 可將 MEMORY.md 中已驗證的 Claude auto-memory 模式提升到 CLAUDE.md 或 .claude/rules/,讓有用的行為成為持久的專案規則。搭配 /si:promote 使用,可確認證據、選擇合適目標,並撰寫有明確範圍的指令,支援可自我改進的 Context Engineering 工作流。
此 skill 評分為 78/100,對於想把已學到的行為提升為可執行專案指令的 directory 使用者來說,是相當穩健的上架候選。它的觸發與執行方式足夠清楚,但由於缺少安裝指引與外部佐證文件,採用門檻仍略高。
- 觸發條件清楚:frontmatter 說明可在使用者執行 `/si:promote`,或要求將已學到的行為永久化時使用。
- 操作流程具體,包含使用範例、逐步流程、目標選擇指引,以及用於 MEMORY.md 的 shell 搜尋指令。
- 能帶來實際的 agent 工作流效益,將非正式的 auto-memory 模式轉換為持久的專案規則,例如 `CLAUDE.md` 或 `.claude/rules/<topic>.md`。
- 未提供安裝指令、README、scripts 或支援檔案,因此使用者需要從周邊的 skill 生態自行推斷安裝方式。
- 目前依據僅限於一份 SKILL.md;`MEMORY.md` 的路徑與搜尋方式,可能需要依不同 Claude/專案設定調整。
promote skill 概覽
promote 會做什麼
promote skill 會把 Claude 在 auto-memory 中反覆出現、已被驗證有效的行為,提升為明確的專案規則。與其讓有用的模式埋在 MEMORY.md 裡,promote 會協助把它移到 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 entries、選擇正確的目標檔案、寫出可執行的規則,並在原本的 memory 中保留 promotion note。這很重要,因為真正困難的不是編輯 markdown,而是判斷某段 memory 是否值得被永久強制執行,以及這條規則應該放在哪裡。
如何使用 promote skill
promote 安裝與 repository 閱讀路徑
從 GitHub skill collection 安裝這個 skill:
npx skills add alirezarezvani/claude-skills --skill promote
接著先閱讀 SKILL.md。目前這個 repository path 只用單一檔案呈現 promote 工作流程,沒有額外的 helper scripts、references 或 rule templates 可檢查。這讓導入變得簡單,但也代表你在重要 repo 上使用前,應該仔細看過 command examples 和 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 file,也就是 ~/.claude/projects/.../memory/MEMORY.md 底下搜尋相關 entries,顯示符合項目,並確認這些 memory 是否足以支持 promotion。
把粗略目標轉成有效的 promote 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 phrase 或事件
合併規則前建議採用的流程
promote 起草或編輯規則後,請像審查 production configuration 一樣審查它。確認指令夠短、可測試,而且沒有超出證據所支持的範圍。若是專案層級的行為,通常適合放在 CLAUDE.md。若是範圍較窄的行為,建議使用 .claude/rules/<topic>.md 並搭配 path scope。若是跨 repositories 的個人慣例,只有在該模式真的具備普遍性時,才使用全域 Claude instruction file。
promote skill 常見問題
promote 是給 Context Engineering 用,還是一般 prompting 用?
promote 對 Context Engineering 最有價值,因為它把「觀察到的行為」到「持久指令」之間的路徑正式化。一般 prompts 可以要求 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 的規則。
如何改進 promote skill
用更好的證據改善 promote 結果
promote skill 在來源 memory 夠具體時效果最好。呼叫它之前,先收集能證明這條規則有必要存在的確切 memory entry、修正紀錄或反覆失敗案例。「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 輸出後,檢查這條規則是否太廣、太模糊,或已經在其他地方重複存在,然後再細修。實用的後續 prompts 包括:
- “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.mdor.claude/rules/testing.md.”
維持規則系統健康
好的 promote 指南應該避免規則層變得吵雜。請定期檢查已 promoted 的規則是否互相衝突、慣例是否過時,以及哪些指令應該移進 tooling。最好的 promote 成果不是更多 markdown,而是因為 Claude 在正確範圍內收到正確且持久的 context,所以重複修正變少。
