🧭 10 自建技能專案級遷移方案

📝 背景與延伸問題

🎯 方案目標

• 降低帳號切換影響：技能不再只綁在單一 Windows 使用者的個人目錄。
• 提高可搬移性：未來要備份、複製、交接、重建環境時更直觀。
• 保留自建規則：把「執行 技能名」這套習慣與對應技能一起整理。
• 便於後續維護：之後新增第 15、16 個技能時，也能直接沿用同一套專案結構。

📦 這次要納入專案級的 14 個技能

註：上表以目前 IDENTITY 約定中的 14 項自建技能為準。

🗂️ 建議的專案級結構

建議把技能搬到目前專案根目錄底下的 .workbuddy\skills\，讓它們直接成為這個 workspace 的一部分。

c:\Users\Administrator\WorkBuddy\20260407182837\
└─ .workbuddy\
   ├─ skills\
   │  ├─ upload-html\
   │  │  └─ SKILL.md
   │  ├─ allcompare\
   │  │  └─ SKILL.md
   │  ├─ ...（其餘 12 個技能）
   │  └─ readrecord\
   │     └─ SKILL.md
   └─ memory\
      └─ MEMORY.md

🛠️ 實施步驟（建議順序）

Step 1：盤點來源

• 確認 14 個自建技能目前都位於 C:\Users\Administrator\.workbuddy\skills\。
• 確認每個技能至少有可用的 SKILL.md 與必要輔助檔。
• 確認是否有技能其實依賴個人路徑、個人環境變數、外部腳本或固定工作區。

Step 2：建立專案級目標目錄

• 在目前工作區建立 c:\Users\Administrator\WorkBuddy\20260407182837\.workbuddy\skills\。
• 先不要刪除使用者層級版本，避免一次搬遷就失去可回退點。

Step 3：逐個複製 14 個技能

• 把上述 14 個技能資料夾複製到專案級目錄。
• 只搬要長期沿用的自建技能，不需要把整個使用者層級 skills 全部複製過來。
• 若技能內寫死其他工作區路徑，要一併改成目前專案實際使用的路徑。

Step 4：保留觸發規則

• 目前「執行 {技能名}」的使用習慣來自身份設定中的約定。
• 遷移時應一併整理觸發說明，避免之後出現「技能在，但不知道怎麼叫」的情況。
• 如果未來主公要完全專案化，我建議再做一份專案內的 skills-readme 或觸發對照頁。

Step 5：驗證

• 至少挑 3 個技能做實測，例如 torecord、updatememo、updatesk。
• 確認切換微信號後，在同一工作區中仍能照常呼叫。
• 若同名技能同時存在於使用者層級與專案層級，需再觀察實際優先順序。

Step 6：穩定後再決定是否淘汰舊版

• 在專案級技能穩定前，不建議立刻刪除 C:\Users\Administrator\.workbuddy\skills\ 裡的原版本。
• 建議先保留一段時間，等專案級版本反覆驗證完成後再決定是否精簡。

⚠️ 風險與注意事項

• 官方同步機制未明：目前公開資料沒有明確保證技能一定跟微信號雲端同步。
• 觸發約定要保留：只有技能資料夾還不夠，最好連呼叫方式一起文檔化。
• 不要一次全刪舊版：先雙軌並行，否則一旦專案級版本漏檔，會直接中斷使用。
• 跨電腦仍需搬工作區：專案級方案解決的是「跟專案走」，不是「自動雲端無感同步到所有電腦」。

📍 本次補充觀察

換句話說：

• 技能或腳本可以設計成非互動；
• 但工作台層仍可能因為涉及外部寫入、跨工作區同步或部署而要求人工確認。

因此，若未來要把整套流程做成真正遠端無人值守，還需要再分開處理「技能內容」與「執行平台權限確認」這兩層。

✅ 一句話結論