skill-creator

Skill Creator

一個用來建立新技能並反覆改善的技能。

整體來說，建立技能的流程如下：

• 決定你想讓技能做什麼，以及大致上該怎麼做
• 撰寫技能草稿
• 建立幾個測試提示詞，並在有技能權限的 Claude 上執行
• 協助使用者以質化和量化方式評估結果
  • 在背景執行測試的同時，如果還沒有量化評估，就先草擬一些；如果已經有，你可以直接使用或根據需要修改。然後向使用者說明這些評估（如果已存在，就說明現有的那些）
  • 使用 eval-viewer/generate_review.py 腳本向使用者展示結果，讓他們查看，同時也讓他們看看量化指標
• 根據使用者對結果的回饋來改寫技能（如果量化基準測試中出現明顯缺陷，也要一併修正）
• 重複直到滿意為止
• 擴充測試集，然後以更大規模再次嘗試

使用這個技能時，你的工作是判斷使用者目前處於哪個階段，然後跳進去幫助他們推進這些階段。舉例來說，如果他們說「我想做一個能做 X 的技能」，你可以幫助他們釐清需求、撰寫草稿、建立測試案例、決定評估方式、執行所有提示詞，然後重複循環。

另一方面，如果他們已經有技能草稿，你可以直接進入評估/迭代的部分。

當然，你應該保持彈性。如果使用者說「我不需要跑一堆評估，只要跟我一起感受就好」，你也可以照做。

技能完成後（但順序可以調整），你也可以執行技能描述最佳化工具（我們有專門的腳本），來最佳化技能的觸發效果。

可以嗎？很好。

與使用者溝通

技能建立者可能會被各種熟悉程度的使用者使用。如果你還沒聽說（但最近才開始流行），現在有個趨勢是 Claude 的強大能力正在激勵水管工打開終端機、父母和祖父母去 Google「如何安裝 npm」。另一方面，大部分使用者可能都還算熟悉電腦操作。

所以請注意上下文線索，來決定如何措辭！在預設情況下，給你一些概念：

• 「評估」和「基準測試」還算可以，但要注意
• 對於「JSON」和「斷言」，你需要看到使用者有明確的跡象顯示他們知道這些東西，才能不解釋直接使用

如果不確定，可以簡單解釋一下術語；如果擔心使用者聽不懂，也可以附上簡短定義。

---

建立技能

捕捉意圖

首先了解使用者的意圖。當前的對話可能已經包含使用者想要捕捉的工作流程（例如，他們說「把這個變成技能」）。如果是這樣，先從對話歷史中提取答案——使用的工具、步驟順序、使用者所做的修正、觀察到的輸入/輸出格式。使用者可能需要補足遺漏的部分，並且在進入下一步之前應該確認。

1. 這個技能應該讓 Claude 能夠做什麼？
2. 這個技能應該在什麼時候觸發？（使用者的哪些用語/情境）
3. 預期的輸出格式是什麼？
4. 我們是否應該設定測試案例來驗證技能是否正常運作？具有客觀可驗證輸出（檔案轉換、資料擷取、程式碼產生、固定工作流程步驟）的技能適合有測試案例。具有主觀輸出（寫作風格、藝術）的技能通常不需要。根據技能類型建議適當的預設值，但讓使用者決定。

訪談與研究

主動詢問關於邊界情況、輸入/輸出格式、範例檔案、成功標準和相依性的問題。等到這部分確定後，再撰寫測試提示詞。

檢查可用的 MCP——如果對研究有幫助（搜尋文件、尋找類似技能、查詢最佳實踐），可以透過子代理平行研究（如果有的話），否則直接內嵌進行。帶著背景知識來，減少使用者的負擔。

撰寫 SKILL.md

根據使用者訪談，填入以下元件：

• name：技能識別碼
• description：何時觸發、做什麼。這是主要的觸發機制——包含技能做什麼以及何時使用的具體情境。所有「何時使用」的資訊都放在這裡，而不是內文中。注意：目前 Claude 有「觸發不足」的傾向——在有用的時候卻不使用技能。為了對抗這個問題，請讓技能描述稍微「強勢」一點。例如，與其寫「如何建立一個簡單快速的儀表板來顯示內部 Anthropic 資料」，不如寫「如何建立一個簡單快速的儀表板來顯示內部 Anthropic 資料。請務必在使用者提到儀表板、資料視覺化、內部指標，或想要顯示任何公司資料時使用這個技能，即使他們沒有明確要求『儀表板』。」
• compatibility：所需的工具、相依性（可選，很少需要）
• 技能的其他部分 :)

技能撰寫指南

技能的結構

skill-name/
├── SKILL.md（必要）
│   ├── YAML frontmatter（name、description 為必要）
│   └── Markdown 指令
└── 捆綁資源（可選）
    ├── scripts/    - 用於確定性/重複性任務的可執行程式碼
    ├── references/ - 按需載入到上下文中的文件
    └── assets/     - 輸出中使用的檔案（範本、圖示、字型）

漸進式揭露

技能使用三層載入系統：

1. Metadata（name + description）——始終在上下文中（約 100 字）
2. SKILL.md 內文——技能觸發時始終在上下文中（理想少於 500 行）
3. 捆綁資源——按需載入（無限制，腳本可以在不載入的情況下執行）

這些字數是近似值，如果需要可以更長。

關鍵模式：

• 保持 SKILL.md 在 500 行以下；如果接近這個限制，請增加一層階層結構，並清楚指出使用技能的下一個步驟。
• 從 SKILL.md 中清楚引用檔案，並說明何時讀取它們
• 對於大型參考檔案（超過 300 行），包含目錄

領域組織：當技能支援多個領域/框架時，按變體組織：

cloud-deploy/
├── SKILL.md（工作流程 + 選擇）
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

Claude 只會讀取相關的參考檔案。

不意外原則

這是不言而喻的，但技能不得包含惡意軟體、利用程式碼或任何可能危及系統安全的內容。技能的內容不應讓使用者對其意圖感到意外。不要配合建立誤導性技能或旨在促進未經授權存取、資料外洩或其他惡意活動的請求。不過，像「角色扮演 XYZ」這樣的東西是可以的。

撰寫模式

在指令中偏好使用祈使句。

定義輸出格式——你可以這樣做：

## 報告結構
始終使用這個確切範本：
# [標題]
## 執行摘要
## 主要發現
## 建議

範例模式——包含範例很有用。你可以這樣格式化（但如果範例中有「輸入」和「輸出」，你可能想稍微偏離）：

## 提交訊息格式
**範例 1：**
輸入：Added user authentication with JWT tokens
輸出：feat(auth): implement JWT-based authentication

寫作風格

試著向模型解釋為什麼事情很重要，而不是使用嚴厲的 MUST。使用心智理論，並嘗試讓技能通用，而不是過度針對特定範例。先寫草稿，然後用全新的眼光審視並改進。

測試案例

撰寫技能草稿後，想出 2-3 個逼真的測試提示詞——真實使用者會說的那種話。與使用者分享：「這裡有幾個我想試試的測試案例。這些看起來對嗎？還是你想再加一些？」然後執行它們。

將測試案例儲存到 evals/evals.json。先不要寫斷言——只要提示詞。你將在下一步（測試執行期間）草擬斷言。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "使用者的任務提示詞",
      "expected_output": "預期結果的描述",
      "files": []
    }
  ]
}

完整結構請參閱 references/schemas.md（包括 assertions 欄位，你稍後會加入）。

執行與評估測試案例

這部分是一個連續的流程——不要中途停止。不要使用 /skill-test 或其他測試技能。

將結果放在 <skill-name>-workspace/ 中，與技能目錄同層級。在工作區內，按迭代組織結果（iteration-1/、iteration-2/ 等），每個測試案例有一個目錄（eval-0/、eval-1/ 等）。不要事先建立所有目錄——邊做邊建立。

步驟 1：在同一回合中啟動所有執行（有技能和基準線）

對於每個測試案例，在同一回合中啟動兩個子代理——一個有技能，一個沒有。這很重要：不要先啟動有技能的執行，然後再回來做基準線。一次全部啟動，這樣它們大約同時完成。

有技能執行：

執行此任務：
- 技能路徑：<path-to-skill>
- 任務：<eval prompt>
- 輸入檔案：<eval files if any, or "none">
- 儲存輸出到：<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 要儲存的輸出：<使用者關心的內容——例如「.docx 檔案」、「最終 CSV」>

基準線執行（相同提示詞，但基準線取決於上下文）：

• 建立新技能：完全沒有技能。相同提示詞，沒有技能路徑，儲存到 without_skill/outputs/。
• 改善現有技能：舊版本。在編輯之前，快照技能（cp -r <skill-path> <workspace>/skill-snapshot/），然後將基準線子代理指向快照。儲存到 old_skill/outputs/。

為每個測試案例撰寫 eval_metadata.json（斷言可以先留空）。根據測試內容給每個評估一個描述性名稱——不只是「eval-0」。目錄名稱也使用這個名稱。如果這次迭代使用新的或修改過的評估提示詞，請為每個新的評估目錄建立這些檔案——不要假設它們會從之前的迭代繼承。

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "使用者的任務提示詞",
  "assertions": []
}

步驟 2：在執行進行中草擬斷言

不要只是等待執行完成——你可以有效利用這段時間。為每個測試案例草擬量化斷言，並向使用者解釋。如果 evals/evals.json 中已經有斷言，請審查它們並解釋它們檢查什麼。

好的斷言是客觀可驗證的，並且有描述性的名稱——它們應該在基準測試檢視器中清晰可讀，讓瀏覽結果的人立即理解每個斷言檢查什麼。主觀技能（寫作風格、設計品質）更適合質化評估——不要強迫將斷言套用到需要人類判斷的事情上。

草擬完成後，更新 eval_metadata.json 檔案和 evals/evals.json。同時向使用者解釋他們會在檢視器中看到什麼——包括質化輸出和量化基準測試。

步驟 3：當執行完成時，擷取時間資料

當每個子代理任務完成時，你會收到包含 total_tokens 和 duration_ms 的通知。立即將這些資料儲存到執行目錄中的 timing.json：

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

這是擷取這些資料的唯一機會——它們透過任務通知傳遞，不會在其他地方持久化。逐個處理每個通知，而不是嘗試批次處理。

步驟 4：評分、彙總並啟動檢視器

當所有執行完成後：

1. 為每個執行評分——啟動一個評分子代理（或內嵌評分），讀取 agents/grader.md，並根據輸出評估每個斷言。將結果儲存到每個執行目錄的 grading.json 中。grading.json 的 expectations 陣列必須使用 text、passed 和 evidence 欄位（不是 name/met/details 或其他變體）——檢視器依賴這些確切的欄位名稱。對於可以程式化檢查的斷言，撰寫並執行腳本，而不是用肉眼檢查——腳本更快、更可靠，並且可以在迭代之間重複使用。

2. 彙總成基準測試——從 skill-creator 目錄執行彙總腳本：

   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   

   這會產生 benchmark.json 和 benchmark.md，包含每個設定的通過率、時間和 token 數，以及平均值 ± 標準差和差異。如果手動產生 benchmark.json，請參閱 references/schemas.md 了解檢視器預期的確切結構。
   將每個有技能版本放在其基準線對應版本之前。

3. 進行分析——閱讀基準測試資料，找出彙總統計可能隱藏的模式。請參閱 agents/analyzer.md（「分析基準測試結果」部分）了解要尋找什麼——例如無論技能如何都始終通過的斷言（無區別力）、高變異的評估（可能不穩定），以及時間/token 的取捨。

4. 啟動檢視器，包含質化輸出和量化資料：

   nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N \
     --skill-name "my-skill" \
     --benchmark <workspace>/iteration-N/benchmark.json \
     > /dev/null 2>&1 &
   VIEWER_PID=$!
   

   對於第二次迭代以上，也要傳入 --previous-workspace <workspace>/iteration-<N-1>。

   Cowork / 無頭環境： 如果 webbrowser.open() 不可用或環境沒有顯示器，請使用 --static <output_path> 來寫入獨立的 HTML 檔案，而不是啟動伺服器。當使用者點擊「提交所有評論」時，回饋會以 feedback.json 檔案下載。下載後，將 feedback.json 複製到工作區目錄中，供下一次迭代使用。

注意：請使用 generate_review.py 來建立檢視器；不需要撰寫自訂 HTML。

5. 告訴使用者類似：「我已經在瀏覽器中開啟了結果。有兩個分頁——『輸出』讓你可以逐一點擊每個測試案例並留下回饋，『基準測試』顯示量化比較。完成後，回到這裡告訴我。」

使用者在檢視器中看到的內容

「輸出」分頁一次顯示一個測試案例：

• 提示詞：給定的任務
• 輸出：技能產生的檔案，盡可能內嵌呈現
• 先前的輸出（第二次迭代以上）：摺疊區塊，顯示上次迭代的輸出
• 正式評分（如果已執行評分）：摺疊區塊，顯示斷言通過/失敗
• 回饋：文字框，輸入時自動儲存
• 先前的回饋（第二次迭代以上）：他們上次的評論，顯示在文字框下方

「基準測試」分頁顯示統計摘要：每個設定的通過率、時間和 token 使用量，以及每個評估的細項和分析師觀察。

導航透過上一個/下一個按鈕或方向鍵。完成後，他們點擊「提交所有評論」，這會將所有回饋儲存到 feedback.json。

步驟 5：讀取回饋

當使用者告訴你他們完成時，讀取 feedback.json：

{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "圖表缺少軸標籤", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "完美，很喜歡", "timestamp": "..."}
  ],
  "status": "complete"
}

空回饋表示使用者認為沒問題。將你的改進重點放在使用者有具體抱怨的測試案例上。

完成後關閉檢視器伺服器：

kill $VIEWER_PID 2>/dev/null

---

改善技能

這是循環的核心。你已經執行了測試案例，使用者已經審查了結果，現在你需要根據他們的反饋來改善技能。

如何思考改進

1. 從回饋中歸納。 大局觀是，我們正在嘗試建立可以被使用一百萬次（也許更多，誰知道呢）的技能，跨越許多不同的提示詞。在這裡，你和使用者只在少數幾個範例上反覆迭代，因為這樣可以加快速度。使用者對這些範例瞭如指掌，可以快速評估新的輸出。但如果你和使用者共同開發的技能只對這些範例有效，那就沒用了。與其進行繁瑣的過度擬合修改，或壓迫性的 MUST，如果遇到頑固的問題，你可以嘗試跳出框架，使用不同的隱喻，或推薦不同的工作模式。嘗試的成本相對較低，也許你會找到很棒的東西。

2. 保持提示詞精簡。 移除那些沒有貢獻的部分。確保閱讀對話記錄，而不僅僅是最終輸出——如果看起來技能讓模型浪費大量時間做無生產力的事情，你可以嘗試移除技能中導致這種行為的部分，看看會發生什麼。

3. 解釋原因。 盡力解釋你要求模型做的每一件事背後的原因。今天的 LLM 很聰明。它們有良好的心智理論，當給予良好的引導時，它們可以超越死記硬背的指令，真正完成事情。即使使用者的回饋簡短或沮喪，也要嘗試真正理解任務、使用者為什麼寫他們寫的內容，以及他們實際寫了什麼，然後將這種理解傳遞到指令中。如果你發現自己用全大寫寫 ALWAYS 或 NEVER，或者使用超級僵硬的結構，那就是一個黃旗——如果可能，重新框架並解釋推理，讓模型理解你要求的事情為什麼重要。這是一種更人性化、更強大、更有效的方法。

4. 尋找測試案例之間的重複工作。 閱讀測試執行的對話記錄，注意子代理是否都獨立撰寫了類似的輔助腳本，或者採取了相同的多步驟方法。如果所有 3 個測試案例都導致子代理撰寫了 create_docx.py 或 build_chart.py，這是一個強烈的信號，表示技能應該捆綁該腳本。寫一次，放在 scripts/ 中，並告訴技能使用它。這可以節省未來每次呼叫時重新發明輪子的時間。

這個任務非常重要（我們正在嘗試創造數十億美元的經濟價值！），你的思考時間不是瓶頸；慢慢來，仔細思考。我建議先寫一個修訂草稿，然後重新審視並改進。盡你最大的努力進入使用者的頭腦，理解他們想要和需要的東西。

迭代循環

改善技能後：

1. 將你的改進應用到技能中
2. 將所有測試案例重新執行到新的 iteration-<N+1>/ 目錄中，包括基準線執行。如果你正在建立新技能，基準線始終是 without_skill（無技能）——這在迭代之間保持不變。如果你正在改善現有技能，請自行判斷什麼作為基準線合理：使用者最初帶來的原始版本，還是上一次迭代。
3. 使用 --previous-workspace 指向先前的迭代來啟動檢視器
4. 等待使用者審查並告訴你他們完成了
5. 讀取新的回饋，再次改善，重複

持續進行直到：

• 使用者說他們滿意了
• 所有回饋都是空的（一切看起來都很好）
• 你沒有取得有意義的進展

---

進階：盲測比較

對於需要更嚴格比較兩個技能版本的情況（例如，使用者問「新版本真的比較好嗎？」），有一個盲測比較系統。閱讀 agents/comparator.md 和 agents/analyzer.md 了解詳細資訊。基本概念是：將兩個輸出提供給一個獨立代理，不告訴它哪個是哪個，讓它判斷品質。然後分析為什麼贏家獲勝。

這是可選的，需要子代理，而且大多數使用者不需要。人類審查循環通常就足夠了。

---

描述最佳化

SKILL.md frontmatter 中的 description 欄位是決定 Claude 是否呼叫技能的主要機制。在建立或改善技能後，提議最佳化描述以提升觸發準確度。

步驟 1：產生觸發評估查詢

建立 20 個評估查詢——混合應該觸發和不應該觸發的查詢。儲存為 JSON：

[
  {"query": "使用者提示詞", "should_trigger": true},
  {"query": "另一個提示詞", "should_trigger": false}
]

查詢必須逼真，並且是 Claude Code 或 Claude.ai 使用者實際會輸入的內容。不是抽象請求，而是具體且詳細的請求。例如，檔案路徑、關於使用者工作或情況的個人背景、欄位名稱和值、公司名稱、URL。一些背景故事。有些可能是小寫、包含縮寫、錯字或口語。使用不同長度的混合，並專注於邊界情況，而不是讓它們明確（使用者將有機會簽署）。

不好："Format this data"、"Extract text from PDF"、"Create a chart"

好："ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"

對於應該觸發的查詢（8-10 個），考慮覆蓋率。你想要相同意圖的不同措辭——有些正式，有些隨意。包含使用者沒有明確說出技能名稱或檔案類型但顯然需要它的情況。加入一些不常見的使用案例，以及這個技能與其他技能競爭但應該勝出的情況。

對於不應該觸發的查詢（8-10 個），最有價值的是接近命中——與技能共享關鍵字或概念但實際上需要不同東西的查詢。考慮相鄰領域、模糊措辭（天真關鍵字匹配會觸發但不應該觸發的情況），以及查詢觸及技能做某事但在其他工具更合適的上下文中的情況。

關鍵要避免的是：不要讓不應該觸發的查詢明顯不相關。作為 PDF 技能的負面測試，「寫一個費氏數列函數」太簡單了——它沒有測試任何東西。負面案例應該真正棘手。

步驟 2：與使用者審查

使用 HTML 範本向使用者展示評估集以供審查：

1. 從 assets/eval_review.html 讀取範本
2. 取代佔位符：
   • __EVAL_DATA_PLACEHOLDER__ → 評估項目的 JSON 陣列（周圍不要有引號——它是一個 JS 變數賦值）
   • __SKILL_NAME_PLACEHOLDER__ → 技能的名稱
   • __SKILL_DESCRIPTION_PLACEHOLDER__ → 技能的當前描述
3. 寫入暫存檔案（例如 /tmp/eval_review_<skill-name>.html）並開啟：open /tmp/eval_review_<skill-name>.html
4. 使用者可以編輯查詢、切換 should_trigger、新增/刪除項目，然後點擊「匯出評估集」
5. 檔案下載到 ~/Downloads/eval_set.json——檢查下載資料夾以取得最新版本，以防有多個（例如 eval_set (1).json）

這一步很重要——糟糕的評估查詢會導致糟糕的描述。

步驟 3：執行最佳化循環

告訴使用者：「這需要一些時間——我會在背景執行最佳化循環，並定期檢查進度。」

將評估集儲存到工作區，然後在背景執行：

python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --model <model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose

使用系統提示詞中的模型 ID（驅動當前會話的那個），以便觸發測試與使用者實際體驗相符。

在執行期間，定期 tail 輸出，向使用者更新目前在哪個迭代以及分數看起來如何。

這會自動處理完整的最佳化循環。它將評估集拆分為 60% 訓練和 40% 保留測試，評估當前描述（每個查詢執行 3 次以獲得可靠的觸發率），然後根據失敗情況呼叫 Claude 提出改進建議。它會重新評估每個新描述在訓練和測試上的表現，最多迭代 5 次。完成後，它會在瀏覽器中開啟一個 HTML 報告，顯示每次迭代的結果，並返回包含 best_description 的 JSON——根據測試分數而不是訓練分數選擇，以避免過度擬合。

技能觸發機制如何運作

了解觸發機制有助於設計更好的評估查詢。技能會出現在 Claude 的 available_skills 列表中，包含名稱和描述，Claude 根據描述決定是否諮詢技能。重要的是要知道，Claude 只會為它無法輕易自行處理的任務諮詢技能——簡單、單一步驟的查詢（如「讀取這個 PDF」）可能不會觸發技能，即使描述完全匹配，因為 Claude 可以直接使用基本工具處理它們。複雜、多步驟或專業化的查詢在描述匹配時會可靠地觸發技能。

這意味著你的評估查詢應該足夠實質，讓 Claude 真正受益於諮詢技能。像「讀取檔案 X」這樣的簡單查詢是糟糕的測試案例——無論描述品質如何，它們都不會觸發技能。

步驟 4：套用結果

從 JSON 輸出中取得 best_description，並更新技能的 SKILL.md frontmatter。向使用者展示前後對比，並報告分數。

---

打包與呈現（僅當 present_files 工具可用時）

檢查你是否可以存取 present_files 工具。如果沒有，跳過此步驟。如果可以，打包技能並向使用者呈現 .skill 檔案：

python -m scripts.package_skill <path/to/skill-folder>

打包後，引導使用者到產生的 .skill 檔案路徑，以便他們安裝。

---

Claude.ai 專用指令

在 Claude.ai 中，核心工作流程相同（草稿 → 測試 → 審查 → 改善 → 重複），但因為 Claude.ai 沒有子代理，一些機制會改變。以下是需要調整的地方：

執行測試案例：沒有子代理意味著無法平行執行。對於每個測試案例，閱讀技能的 SKILL.md，然後按照其指令自行完成測試提示詞。一次做一個。這不如獨立的子代理嚴謹（你寫了技能，也正在執行它，所以你有完整的上下文），但這是一個有用的合理性檢查——而且人類審查步驟可以補償。跳過基準線執行——只需使用技能按請求完成任務。

審查結果：如果你無法開啟瀏覽器（例如，Claude.ai 的 VM 沒有顯示器，或者你在遠端伺服器上），完全跳過瀏覽器審查器。相反，直接在對話中呈現結果。對於每個測試案例，顯示提示詞和輸出。如果輸出是使用者需要看到的檔案（如 .docx 或 .xlsx），將其儲存到檔案系統並告訴他們位置，以便他們下載和檢查。內嵌詢問回饋：「這個看起來如何？有什麼要改的嗎？」

基準測試：跳過量化基準測試——它依賴於基準線比較，而沒有子代理就沒有意義。專注於使用者的質化回饋。

迭代循環：與之前相同——改善技能，重新執行測試案例，詢問回饋——只是中間沒有瀏覽器審查器。如果你有檔案系統，仍然可以將結果組織到迭代目錄中。

描述最佳化：這部分需要 claude CLI 工具（特別是 claude -p），它只在 Claude Code 中可用。如果你在 Claude.ai 上，請跳過。

盲測比較：需要子代理。跳過。

打包：package_skill.py 腳本可以在任何有 Python 和檔案系統的地方運作。在 Claude.ai 上，你可以執行它，使用者可以下載產生的 .skill 檔案。

更新現有技能：使用者可能要求你更新現有技能，而不是建立新技能。在這種情況下：

• 保留原始名稱。 注意技能的目錄名稱和 name frontmatter 欄位——保持不變。例如，如果已安裝的技能是 research-helper，輸出 research-helper.skill（而不是 research-helper-v2）。
• 在編輯前複製到可寫入的位置。 已安裝的技能路徑可能是唯讀的。複製到 /tmp/skill-name/，在那裡編輯，並從複製版本打包。
• 如果手動打包，先在 /tmp/ 中暫存，然後複製到輸出目錄——直接寫入可能因權限而失敗。

---

Cowork 專用指令

如果你在 Cowork 中，主要需要知道的是：

• 你有子代理，所以主要工作流程（平行啟動測試案例、執行基準線、評分等）都可以運作。（但是，如果你遇到嚴重的超時問題，也可以串列執行測試提示詞。）
• 你沒有瀏覽器或顯示器，所以在產生評估檢視器時，使用 --static <output_path> 來寫入獨立的 HTML 檔案，而不是啟動伺服器。然後提供一個連結，讓使用者可以點擊在他們的瀏覽器中開啟 HTML。
• 由於某種原因，Cowork 設定似乎讓 Claude 在執行測試後不傾向於產生評估檢視器，所以再次強調：無論你在 Cowork 還是 Claude Code 中，在執行測試後，你應該總是產生評估檢視器讓人類查看範例，然後再自行修改技能並嘗試修正，使用 generate_review.py（而不是撰寫你自己的自訂 HTML 程式碼）。先說聲抱歉，但我接下來要用全大寫：在你自己評估輸入之前，先產生評估檢視器。你想盡快把它們放到人類面前！
• 回饋的運作方式不同：由於沒有執行中的伺服器，檢視器的「提交所有評論」按鈕會將 feedback.json 下載為檔案。然後你可以從那裡讀取它（你可能需要先請求存取權限）。
• 打包可以運作——package_skill.py 只需要 Python 和檔案系統。
• 描述最佳化（run_loop.py / run_eval.py）在 Cowork 中應該可以正常運作，因為它使用 claude -p 透過子程序，而不是瀏覽器，但請等到你完全完成技能製作且使用者同意狀態良好後再執行。
• 更新現有技能：使用者可能要求你更新現有技能，而不是建立新技能。請遵循上方 claude.ai 部分中的更新指南。

---

參考檔案

agents/ 目錄包含專用子代理的指令。當你需要啟動相關子代理時閱讀它們。

• agents/grader.md——如何根據輸出評估斷言
• agents/comparator.md——如何對兩個輸出進行盲測 A/B 比較
• agents/analyzer.md——如何分析為什麼一個版本勝過另一個

references/ 目錄有額外文件：

• references/schemas.md——evals.json、grading.json 等的 JSON 結構

---

再次強調核心循環：

• 確定技能的主題
• 草擬或編輯技能
• 在有技能權限的 Claude 上執行測試提示詞
• 與使用者一起評估輸出：
  • 建立 benchmark.json 並執行 eval-viewer/generate_review.py 來幫助使用者審查
  • 執行量化評估
• 重複直到你和使用者都滿意
• 打包最終技能並返回給使用者。

請在你的待辦清單（如果你有的話）中加入步驟，以確保不會忘記。如果你在 Cowork 中，請特別在待辦清單中加入「建立 evals JSON 並執行 eval-viewer/generate_review.py 讓人類可以審查測試案例」，以確保它被執行。

祝你好運！