loot
每一次對話都會掉寶。大部分寶物都會死在聊天紀錄中。你的任務是：找出它們，全部記錄下來，根據證據而非熱情來評斷它們，並且只在使用者同意後，才發布那些真正值得發布的稀有物品。
loot 的大部分價值在於 LOOT.md：一份記錄使用者所有發現的持續更新檔案。發布只是例外情況。
Loot 是對話中任何有價值的部分，而不僅僅是意外發現：
| 類型 | 樣子 | 常見形式 |
|---|---|---|
| 成品 | 對話所圍繞的應用程式、工具或腳本 | 儲存庫 |
| 元件 | 一個可以在這個專案之外獨立運作的片段（hook、解析器、設定檔、提示詞） | 儲存庫或 Gist |
| 技巧 | 一個訣竅、修復方法或技術（讓 X 快了 4 倍、讓 Y 能在本機運作） | 文章 + Gist 或儲存庫 |
| 知識 | 使用者給你的、讓輸出品質變好的糾正和回饋 | 技能 |
| 故事 | 從問題到結果的過程，包括死路 | 文章 |
| 數據 | 基準測試、比較、測量結果 | 文章或儲存庫 README |
一次對話通常包含多個項目。一個項目也常常值得多種形式（儲存庫 + 文章 + 示範）。
模式
| 指令 | 功能 |
|---|---|
/loot | 掃描本次對話，顯示表格，詢問要發布什麼 |
/loot "<主題>" | 只看一個東西（更節省成本）：例如「那個 ffmpeg 技巧」 |
/loot 2, /loot all | 發布第 2 個掉落物，或發布所有評級為「稀有」或以上的掉落物，不詢問要發布哪個 |
/loot --list | 列出近期過去的對話以供選擇 |
/loot <session.jsonl> | 掃描過去的一次對話而非本次 |
/loot review | 重新評級已存在於 LOOT.md 中的內容（參見步驟 6） |
1. 掃描
閱讀整個對話及其觸及的檔案。對於過去的對話，或當本次對話的前面部分已被摘要時，改為閱讀對話記錄：
node <此技能的路徑>/scripts/transcript.mjs list # 列出最近的 Claude Code + Codex 對話
node <此技能的路徑>/scripts/transcript.mjs read <檔案> # 濃縮文字，機密已遮罩
本次對話自己的記錄是 ~/.claude/projects/<專案>/ 中最新的檔案。如果你無法越過摘要讀取內容，請在表格中說明：早期的發現可能遺失。列出候選項目。對於每個項目，記錄它的功能以及它確實能運作的證據（測試、基準測試、前後對比、使用者的反應）。
如果一個項目僅能在該使用者的設定中運作且無法通用化，如果它主要是他人的程式碼，或是使用者的私人或客戶工作，則將其丟棄。請勿在表格中提及對話中的機密、憑證或個人資料。
2. 評級
評級是一個過濾器，它的工作是說「不」。你對自己剛協助完成的東西是個糟糕的評判者：你無法判斷什麼對世界來說是新鮮的，而且你傾向於恭維使用者。因此，稀有度來自證據，並且評判是在脫離對話的情況下進行的。
為每個候選項目收集證據：
- 查詢：一個陌生人遇到這個問題時會在搜尋框中輸入的字詞
- 搜尋：執行搜尋（網路、GitHub、npm/PyPI），並列出最接近的結果及連結。搜尋它的功能，而不是它的名稱。如果沒有搜尋工具：標記為「未檢查」。
- 證明：一個在對話中實際發生的測試、基準測試或前後對比，並附上位置（指令、檔案、訊息），或「無」。永遠不要憑記憶重建證據：AI 筆記會發明名稱、數字和細節。
- 優勢：它相對於最接近的結果所擁有的額外功能，如果可能的話，需要被量化
在其他地方進行評級。 如果你能啟動一個子代理，只給它候選項目及其證據，絕不給它對話內容，並附上以下簡短指示：「根據以下門檻評級每個項目。首先假定為「普通」，只有當其證據達到門檻時才升級一個項目。若不確定，則評為較低的等級。僅使用給定的證據；絕不添加或假設任何證據。對於任何只差一項要求就能達到下一等級的項目，指出能讓它升級的最便宜的證據。」如果你無法做到，請在評級之前，先寫下每個項目被歸類為「普通」的最強理由。
| 稀有度 | 需要全部滿足 | 形式 |
|---|---|---|
| 普通 | 低於「稀有」的任何情況 | LOOT.md 中的一行 |
| 稀有 | 一個真實的查詢；一個被引用且沒有找到等效物的搜尋，或一個相對於最接近結果的量化優勢；它確實能運作的證明 | Gist、短篇部落格文章、或一個小型儲存庫或技能 |
| 史詩 | 「稀有」的條件，加上一個相對於具名替代方案的量化優勢，並且它能從全新 clone 的環境中執行 | 儲存庫或技能、文章、示範、發布草稿 |
硬性規則：
- 「未檢查」或「無證明」意味著「普通」，無論感覺多好。
- 存在等效物且優勢未被量化：歸類為「普通」。從其他專案的 README 中論證的優勢不算量化。
- 持平則向下取整。
- 接近但未達到者會獲得下一步行動。 一個只差一項要求就能達到下一等級的項目會被標記為
[COMMON, near Rare]或[RARE, near Epic]，並獲得一個next:行：能讓它升級的最便宜的證據，以及大致所需的時間。這將一個「不」變成了一個使用者可以選擇的待辦事項。 - 預期幾乎所有東西都是「普通」。如果一次對話中有超過一個項目的評級高於「普通」，請說明為什麼這次對話是例外。
- 「普通」不是失敗。它是防止工作成果遺失的日誌條目。
顯示 loot 表格，附上任何高於「普通」的項目的證據，然後停止：
LOOT: 3 個掉落物
1. [RARE, near Epic] remotion-ae-transitions: 在 Remotion 中實現 After Effects 風格的轉場，完全本地化
查詢: "remotion after effects transitions"
搜尋: @remotion/transitions（滑動、淡入淡出、擦除），一個付費模板包；都沒有做這些
證明: 在對話中渲染並通過了 6 種轉場效果
優勢: 未量化，因此非史詩 → Gist + 短篇部落格文章
下一步: 使用 @remotion/transitions 渲染同樣的 3 個鏡頭並比較；然後從全新 clone 執行（約 45 分鐘）
2. [COMMON] ffmpeg 雙遍技巧：記錄在 ffmpeg wiki 中 → LOOT.md
3. [COMMON] 自訂字體載入器：僅在這個專案中有用 → LOOT.md
要發布哪個？（輸入數字、「all」或「none」）
最多顯示 7 個掉落物，最強的優先。所有其他項目在「noted」下只佔一行。
顯示表格後，將其附加到專案根目錄的 LOOT.md 中（如果檔案不存在則建立它），並註明日期。一個掉落物只有在未來某次對話如果沒有它就會出錯或需要重做實際工作時，才值得一個完整的條目。否則，它只是一個單行的「noted」條目。這個日誌只有在保持可讀性時才有用。
3. 鍛造
對於每個被選中的項目，在目前儲存庫歷史之外的新資料夾（預設為 ../<slug>，或使用者指定的位置）中建構最終成品。閱讀 references/forge.md 以獲取每種形式的檢查清單。簡而言之：
- 將其通用化。 刪除專案名稱、硬編碼路徑、客戶細節和無用程式碼。它必須能夠根據 README 中的步驟，從全新 clone 的環境中執行。執行它。
- 為它命名。 簡短、好記、能說明它的功能。檢查名稱是否可用：
gh search repos <name>，npm view <name>（exit 1 表示可用）。 - 標語。 一行話，告訴陌生人這個專案是做什麼的以及為誰而做。
- 標誌。 簡單，一或兩種顏色，在 16px 時可讀，在淺色和深色背景上都能正常顯示。
- 社交預覽圖。 一張 1280×640 的卡片（包含 Logo、名稱、標語），讓分享連結時能顯示圖片，而不是空白的 GitHub 卡片。
- README。 先說結果，然後是快速入門，最後是運作原理。
- 證明。 一個測試、一個基準測試或一個前後對比。絕不發明數字。
技能： 如果選擇的形式是技能，請遵循與此技能一同發布的 skill-factory 技能（../skill-factory/SKILL.md），並將該項目的證據（查詢、搜尋結果、證明、優勢）作為起始規格。跳過該項目的步驟 3–5：skill-factory 會自行測試、審查和把關發布。
4. 檢查（絕不跳過）
-
掃描你將要發布的每個資料夾，尋找機密：
- 總是執行：
node <此技能的路徑>/scripts/scan.mjs <資料夾> - 此外，如果已安裝
gitleaks：gitleaks dir <資料夾>，並且當資料夾有 git 歷史時執行gitleaks git <資料夾>。
修復每個發現，或者將誤報標記為
loot:allow並說明原因。手動檢查每個warn行。絕不推送未經 gitleaks 掃描的現有 git 歷史；如果沒有 gitleaks，則改為從全新的git init開始發布。 - 總是執行：
-
閱讀將要發布的每個檔案。尋找個人資料、客戶名稱、內部主機名稱、私人儲存庫連結以及受其他授權條款保護的程式碼。
-
向使用者展示一份清單：每個目的地（儲存庫名稱、公開或私人、部落格草稿或已發布）、檔案、標語。請求明確的同意。這個「同意」僅涵蓋該清單中的內容，不多也不少。
5. 發布
閱讀 references/ship.md 以獲取指令和備援方案。優先使用你自己的工具；如果不行，則交給使用者一個可以直接執行的指令或檔案。
- 儲存庫：
gh repo create，描述，主題標籤，推送。 - 文章：當 token 已設定時，在 dev.to 或 Hashnode 上建立草稿；否則建立一個 Markdown 檔案。Medium：Markdown 檔案加上匯入說明。
- 發布貼文（Show HN、X、Reddit），僅限「史詩」等級：在一個被
.gitignore忽略的launch/資料夾中建立草稿。絕不實際發布它們。 - 最後提供所有已發布內容的連結以及任何遺留給使用者的事項。
6. 回顧（/loot review）
一次對話的評級只是一個猜測。證據會隨著時間累積：
- 閱讀
LOOT.md。將實際上是同一件事（相同的核心想法，即使措辭不同）的條目歸為一組。 - 當情況發生變化時，重新評級一個掉落物：它在 3 次或更多對話中出現過，它獲得了證明（使用者、基準測試、有人問起它），或者新的搜尋找不到等效物了。使用相同的證據規則和相同的外部評級者。
- 顯示哪些有所變動以及原因。在
LOOT.md中撰寫一個註明日期的「回顧」章節；絕不重寫舊條目。然後提議發布任何現在評級為「稀有」或更好的項目。
使用代理已有的資源
| 需求 | 最佳方案 | 總是能用的備援方案 |
|---|---|---|
| Logo / 封面圖片 | 你自己的圖片生成功能或一個圖片 MCP（如果你有的話） | 手寫 SVG |
| 機密掃描 | gitleaks（也涵蓋 git 歷史） | 內建的 scripts/scan.mjs |
| 示範影片 | Remotion (Node) | 截圖 + GIF |
| 截圖 | 瀏覽器工具 | 向使用者索取一張 |
| 「已經存在了嗎？」 | 網路搜尋 | 標記為「未檢查」（將其上限限制在「普通」） |
| 過去或被摘要的對話 | scripts/transcript.mjs（Claude Code， Codex） | 請使用者貼上或匯出對話記錄 |
| 獨立評級 | 一個從未見過對話內容的子代理 | 先寫出最強的理由來說明為何它是「普通」 |
| 發布儲存庫 | gh CLI | 列印出指令 |
| 發布文章 | 具有現有 token 的平台 API | Markdown 檔案 |
規則
- 沒有使用者對確切清單的明確同意，任何東西都不能公開。
- 絕不要求輸入、輸入或儲存憑證。如果某個工具尚未登入，則使用備援方案。
- 絕不發布機密、個人資料、或客戶或僱主的工作。
- 尊重授權條款：不要重新授權不是你撰寫的程式碼。
- 不虛構證明：不偽造基準測試、使用者、引言或星星數。
- 使用聊天中使用者的語氣來寫作，不要像新聞稿。