部門共享：上 PR 給 team-skill-lab

個人 skill 是工具，部門 skill 是資產。本課教你怎麼從前者升到後者。

課程目標

認識部門 skill repo claude-team-skill-lab：所有部門共享 skill 都住這
學會 sync-skill-lab 流程：從 GitHub 拉最新 skill 到本機
學會把你的 skill 上 PR 給部門
學會用 skill-optimize ratchet 把 skill 從 experimental 升到 active
課後 Lab：拿你寫好的 skill 真正交一個 PR

一、為什麼要分享？

第 8 課最後說過——個人 skill 是工具，部門 skill 是資產。

具體差別：

	個人 skill（住 `~/.claude/skills/`）	部門 skill（住 `claude-team-skill-lab` repo）
誰能用	只有你	全部門
維護者	你	部門集體
風險	你自己	PR review 把關
累積	每個人重新發明輪子	一次寫，N 個人受惠

如果你的 skill 解決的問題至少還有 2 個同事也有——上 PR。如果只有你才會用（例如綁你個人習慣的）——留在個人目錄就好，不要污染部門。

二、認識 `claude-team-skill-lab`

部門 skill repo 結構：

claude-team-skill-lab/
├── skills/
│   ├── workflow/         # 業務流程、評估、報告
│   ├── engineering/      # Code review, testing, debugging
│   ├── research/         # 技術調研、市場分析
│   └── writing/          # 文件、blog、公告
├── skill-spec-drafts/    # spec 暫存（從 skill-spotter hand-off）
├── SKILL_CONVENTION.md   # 部門撰寫規範（你已經讀過）
├── README.md
└── ...

每個 skill 一個資料夾，分類放 workflow/ engineering/ 等。

怎麼放分類？

分類	適用
`workflow/`	業務流程、評估、報告、部署、收尾
`engineering/`	Code review、testing、debugging、refactoring
`research/`	技術調研、市場分析、競品比較
`writing/`	文件、blog、LinkedIn、公告

不確定 → 放最接近的，未來可以重歸。

三、`sync-skill-lab` —— 拉 skill 到本機

部門 skill 寫好 PR 進 repo 後，怎麼到你電腦？

跑：

/sync-skill-lab

它做：

cd ~/GitHub/claude-team-skill-lab && git pull
把 skills/<category>/<skill-name>/ 同步到 ~/.claude/skills/<skill-name>/
告訴你哪些 skill 是新的、哪些有更新

注意：預設只 sync 部分 skill（依 sync-skill-lab 的 allowlist），其他要手動加進去。詳細看 sync-skill-lab 的 SKILL.md。

你應該每週跑一次

部門其他人會持續加 skill。每週跑一次 /sync-skill-lab 確保你拿到最新版。

四、上 PR 流程

Step 1：先確認 skill 在個人目錄能跑

別跳這步。實戰用過 ≥ 3 次，沒大問題，再考慮上 PR。

Step 2：跑 `/audit-skill`

/audit-skill ~/.claude/skills/<your-skill>/

確認沒有 PII / 安全問題。第 8 課教過。

Step 3：搬到 repo 對應分類資料夾

cp -r ~/.claude/skills/weekly-report ~/GitHub/claude-team-skill-lab/skills/workflow/

選對分類資料夾。

Step 4：對齊 SKILL_CONVENTION.md

打開部門規範：

cat ~/GitHub/claude-team-skill-lab/SKILL_CONVENTION.md

檢查：

name 是否 kebab-case？
description 是否符合公式？
body 結構是否照建議？
frontmatter 必填欄位齊不齊？

不對齊就先改。

Step 5：開 PR

cd ~/GitHub/claude-team-skill-lab
git checkout -b add-weekly-report-skill
git add skills/workflow/weekly-report/
git commit -m "feat(skill): 新增 weekly-report — 週報草稿生成器

每週五掃 git log + memhall episode，整理成 3 段式週報。
v0.1 experimental，已實戰 5 次，待部門 review。

驗證：audit-skill pass / 已用 3 次"
git push -u origin add-weekly-report-skill

PR 在 GitHub 開出來後，部門 maintainer 會 review。

Step 6：Review 期間做什麼？

通常 maintainer 會給 3 類回饋：

格式問題（description 不夠 pushy / body 太長）→ 改 SKILL.md
安全問題（PII / allowed-tools 太鬆）→ 改 + 重跑 audit-skill
重疊問題（跟既有 skill 太像）→ 討論是否合併

通常 1-3 輪 round 後 merge。

五、`skill-optimize` —— 從 experimental 升到 active

skill merge 進部門後，status 一開始是 experimental。要升到 active，部門慣例是跑一次 skill-optimize ratchet。

什麼是 Ratchet？

棘輪——只往一個方向轉，不往回。skill-optimize 的意思是：

對你的 SKILL.md 跑 9 維 rubric 打分（structure + effectiveness + conciseness）
提案一個目標性改進
commit 改進
獨立 subagent 重新打分
只保留有量化進步的改動

跑：

/skill-optimize ~/.claude/skills/<your-skill>/

跑 5-10 輪 → 分數收斂 → status 從 experimental 改成 active → 再 PR。

為什麼這個流程值得？

部門 active skill 會被推薦給所有同事。如果一個 skill 沒驗證過品質就 active，會擴散垃圾——所以 ratchet 是品質 gate。

六、部門 skill 文化的三層

部門目標是建立這個 funnel：

Layer 3：被廣泛使用的 active skill（部門共享）
   ↑ skill-optimize ratchet
Layer 2：experimental skill（PR merge 進部門 repo）
   ↑ /audit-skill + PR
Layer 1：個人 skill（住 ~/.claude/skills/）
   ↑ skill-creator + 實戰
Layer 0：對話裡的重複痛點
   ↑ skill-spotter mining

每堂課對應一層：

Lesson 1-2：認識 skill（Layer 0 → 開始注意重複）
Lesson 3-4：解剖 skill（Layer 0 → Layer 1）
Lesson 5-6：mining + triage（Layer 0 → Layer 1）
Lesson 7：寫 skill（Layer 1）
Lesson 8：避坑（Layer 1）
Lesson 9（這課）：上 PR + ratchet（Layer 1 → Layer 2 → Layer 3）

整個 funnel 走通 = 你從消費者升級成貢獻者。

七、結論：你學完了什麼

回頭看 9 課：

為什麼需要 skill — 越過認知牆
第一個 skill — 跑現成的看效果
解剖學 — SKILL.md 結構
description — 觸發機制
mining — 從對話找候選
三門診斷 — Hook / Skill / Agent 怎麼選
寫第一個 — skill-creator 對話
避坑 — 5 大坑 + audit-skill
部門共享（這課） — PR + ratchet

你現在是部門 skill 文化的貢獻者，不只是消費者。

課後 Lab：交出你的第一個 PR

這是課程的最終 lab。下週上課時 Maki 會檢查。

完成標準（必做）

跑過 /skill-spotter 至少 1 次，撈到至少 1 個候選
用 /skill-creator 把候選寫成 SKILL.md
在個人目錄實戰用過 ≥ 3 次
跑過 /audit-skill 確認無 PII / 安全問題
跑過 pii_scrub.py 確認無命中
PR 開出來，給 GitHub URL

進階（選做）

跑 /skill-optimize 做一輪 ratchet
在 PR 描述裡 cite 至少 1 個你學到的概念（progressive disclosure / 三門診斷 / pushy description）

提交方式

下週上課前，把 PR URL 貼到部門 Slack #skills-101-lab channel。

AI 協作：學了這個，跟 AI 怎麼配合？

從個人 skill 升到部門資產這條路，AI 能幫你 review 對齊規範、寫 PR 描述、做 ratchet——但部門 review 時的對話、討論、妥協只能你親自上。skill PR 不是「commit 完就結束」，是「對話的開始」。

你的人類優勢：

你知道 maintainer 的 review style——誰嚴格、誰彈性、哪些 reviewer 在乎安全 / 哪些在乎可讀性
你能判斷 reviewer 的回饋哪些該照單全收、哪些值得 push back

可以這樣跟 AI 說：

幫我寫 PR 描述。skill 名稱 [...]，cite 我學到的 3 個概念（progressive disclosure / 三門診斷 / pushy description）並各自連到對應 SKILL.md 段落。最後加一段「我預期 reviewer 可能挑戰的點」——讓我先準備回應。

練習題

恭喜你完成 Claude Skills 入門。

從現在開始，你看世界的眼睛變了——以前你看到「重複工作」覺得煩，現在你看到「重複工作」會想「這是個 skill 候選」。

這就是這堂課要送給你的禮物。