打開 skills.sh 的 24 小時排行榜，第一名不是會寫程式、剪影片或操控瀏覽器的 Skill，而是 find-skills：一個專門幫你找其他 Skill 的 Skill。
這聽起來有點荒謬，卻是生態系成熟時一定會出現的東西。早期選項少，大家靠記憶或朋友推薦；等數量多到逛不完，入口就比內容更值錢。搜尋引擎、App Store、套件管理器都走過同一條路。
截至 2026 年 7 月 15 日，它在 skills.sh 顯示約 250 萬次累積安裝，24 小時內又多了 1.89 萬次，兩個數字都很醒目。我的結論先講：值得裝，但我不會讓它替我做最後決定。
它到底做什麼？
find-skills 接手的是一段很普通、也很煩的流程。你描述需求，例如「我想找做 SEO 稽核的 Skill」；它用指令搜尋候選項，整理安裝數、來源與相關性，再提供安裝方式。
npx skills find seo audit
npx skills add <package-name>原始說明很坦白：推薦時會參考下載量、來源聲譽、GitHub 星數與排行榜位置，而且偏好已有一千次以上安裝的項目。這套規則很像有經驗的開發者第一次篩 npm 套件，並不神祕。
為什麼它會衝到第一名？
因為它剛好解決每個新手的第一個問題：我該裝哪一個？
影片生成 Skill 只服務想做影片的人；Gmail Skill 只服務需要寄信的人。find-skills 不挑用途。只要你相信 Agent 可以外掛能力，它就有出場機會。每一次新的 Skill 被發布，反而讓這個入口更有價值。
第二個原因更實際：它的第一次成功很快。你不用申請 API、不用登入第三方服務，也不用先準備測試資料。跑一次搜尋，畫面出現幾個候選項，成就感馬上到手。
實際好用在哪裡
1. 它能把模糊需求翻成可搜尋的詞
很多人卡在名稱。你心裡想的是「幫我整理訪談」，套件名稱可能寫 research synthesis、transcript analysis 或 customer discovery。把自然語言交給 Agent 拆關鍵字，確實比自己在目錄裡亂翻有效率。
2. 它會在「沒有適合結果」時停手
原始流程不只叫 Agent 推薦，也允許它承認找不到。這個細節比看起來重要。糟糕的推薦系統為了交作業，總會硬塞一個勉強相關的答案；好的工具知道空手而回有時比較安全。
3. 安裝流程接得很順
搜尋後直接給 npx skills add 指令，少了複製 repo、猜目錄與手動搬檔案。對剛開始摸 Agent Skills 的人，這種小摩擦才是最常見的棄用原因。
我介意的地方
第一個問題是「熱門者越來越熱門」。如果推薦規則偏好高安裝數，使用者又習慣挑第一個結果，新 Skill 即使寫得更好，也很難取得第一批曝光。久了，榜單不只反映選擇，還會製造選擇。
第二個問題是指標很粗。安裝數告訴你有人試過，沒告訴你後來有沒有留下；GitHub 星數可能屬於整個大型 repo，而不是單一 Skill；知名作者降低了來路不明的風險，也不代表每個版本都適合你的環境。
第三個問題是安全檢查容易被誤讀。skills.sh 頁面顯示它通過 Gen Trust 與 Socket 掃描，Snyk 則標示警告。這些結果值得看，但掃描通過不等於 Skill 每次採取的動作都符合你的預期。接著仍要打開內容，看它準備執行哪些指令、讀哪些檔案、把資料送去哪裡。
目錄可以替你縮小範圍，不能替你承擔安裝後的權限。
誰該裝，誰先別裝？
如果你剛開始組自己的 Agent 工作流，或每週都會接觸不同任務，我會裝。它很適合當第一輪探索工具：快速知道市場上有沒有現成解法，再決定要不要深入。
如果你的公司有固定白名單、需要鎖版本、每個外部套件都要走資安審核，那就不該讓它直接安裝。可以保留搜尋功能，但把「找到」和「加入生產環境」拆成兩個步驟。
我自己的使用方式是：先讓它列出三個候選，接著打開原始 SKILL.md，確認依賴、寫入範圍與失敗處理。只看排行榜第一名，跟在 App Store 看到第一名就交出相簿權限，沒有本質上的差別。
最後結論：裝，但保留懷疑
find-skills 沒有假裝自己會解決複雜任務。它只把搜尋、初篩與安裝接在一起，這件小事剛好位於整個 Skill 生態的入口，所以非常有用。
我給 8.4 分。失去的 1.6 分主要在推薦邏輯：它仍高度依賴人氣訊號。把它當雷達，你會省下不少時間；把它當裁判，你看到的世界會越來越窄。