wp-project-triage

wp-project-triage 技能概觀

wp-project-triage 的作用

wp-project-triage 技能是一個快速、具決定性的 WordPress repository 初步檢查器。它會辨識較可能的專案類型、偵測工具鏈與測試、找出版本線索，並輸出結構化報告，讓你不用猜就能選對工作流程。如果你需要用 wp-project-triage 來做 Workflow Automation，這類技能很適合在還沒編輯任何內容之前，先幫 agent 判斷下一步該做什麼。

適合誰使用

當你被丟進一個 WordPress codebase，卻需要先確認它是 plugin、theme、block theme、site、WP core，還是 Gutenberg 相關 repo 時，就該使用 wp-project-triage skill。它特別適合想在實作、審查或測試前，先有一個可重複、可一致的 triage 步驟的 agent 與維護者。

為什麼它不一樣

wp-project-triage 的核心價值不是文字摘要，而是決策支援。它會讀取 repository 訊號、套用防呆規則，並輸出一份比泛用 prompt 更值得信任的 JSON 報告。這讓它比起只用 LLM 針對幾個檔名去「猜這個 repo 是什麼」更適合。

如何使用 wp-project-triage 技能

安裝並指向 repo 根目錄

對於 wp-project-triage install，先用標準 skills 指令把技能加入你的 agent workspace，然後一定要從 repository root 執行，這樣 detector 才能檢查真正的專案結構。這個技能需要以檔案系統為基礎的環境，並可使用 bash 與 Node；有些工作流程也會仰賴 WP-CLI。

先讀這些檔案

先從 skills/wp-project-triage/SKILL.md 看起，接著查看 references/triage.schema.json 來理解報告的結構。repo 裡也包含 scripts/detect_wp_project.mjs，如果你想了解分類與訊號偵測怎麼運作，這是最關鍵的檔案。這三個檔案提供的資訊，會比只是粗略掃過目錄樹更多。

把模糊目標改寫成有用的 prompt

好的 wp-project-triage usage prompt，應該說清楚你要做什麼判斷，而不只是想做一次掃描。例如：「請在這個 repo 上執行 wp-project-triage，告訴我它看起來像 plugin 還是 block theme、目前有哪些工具，以及我在改 code 之前應遵守哪些防呆原則。」這樣能給技能足夠的意圖，產出可直接採取行動的 triage 報告。

用報告決定下一個工作流程

偵測器跑完後，根據輸出決定要再看 build config、test 設定、版本限制，還是內容結構。如果報告顯示 unknown，就應該把它視為一個訊號：先確認你是否在正確的根目錄，或是這個 repo 是否需要更好的偵測規則，而不是硬猜。當你新增 theme.json、block.json 或 build tooling 之後，也要重新執行偵測器。

wp-project-triage 技能 FAQ

wp-project-triage 只適用於 WordPress repos 嗎？

是的，這就是它的設計範圍。wp-project-triage guide 針對的是 WordPress 專案的常見型態，例如 plugins、themes、block themes、site repos、core 與 Gutenberg。如果你不在這個生態系內，通常用一般的檔案系統掃描器或其他 repo 分類器會更合適。

使用它一定需要 WP-CLI 嗎？

不一定。這個技能在只有檔案系統的環境中仍然有幫助，但某些後續工作流程可能會預期有 WP-CLI 或 WordPress 周邊工具。wp-project-triage 的目的，就是先告訴你目前有哪些東西，讓你判斷後面的步驟是否真的可行。

這比直接叫 AI 檢查 repo 更好嗎？

通常第一輪會更好。一般 prompt 可能會漏掉版本線索、忽略訊號，或在樹狀結構不夠明確時憑空補出不存在的結構。wp-project-triage 提供可重複的安裝與執行流程、明確的輸出契約，以及更聚焦的任務：先分類，再行動。

什麼情況下不該用它？

不要把它拿來取代 code review、安全審計或深入的架構分析。它是一層 triage，不是完整診斷。如果你已經知道確切的專案類型，且只是要做一個有針對性的 code 任務，那這一步可能不需要。

如何改善 wp-project-triage 技能

提供更乾淨的起始條件

要讓 wp-project-triage 的結果更好，最有效的方法是從真正的 repo root 執行，並避免 partial checkout 或巢狀工作目錄。如果 detector 掃到錯的資料夾，報告的可用性會立刻下降。這比華麗的 prompt 更重要。

提供會改變判斷的上下文

如果你想讓 wp-project-triage usage 更準，請明講你需要的具體結果：例如要分辨 plugin 還是 theme、偵測 build tool，或確認測試是否就緒。這能幫助你判斷報告是否已經足夠支撐下一步。好的追問可以問「最小且安全的修改路徑」，而不是「全部摘要」。

注意常見失敗模式

最常見的失敗模式，是因為訊號不足、repository 結構特殊，或忽略了某些目錄，導致分類變成 unknown 或過於簡略。另一種情況是，repo 只有產生出的檔案，卻缺少足夠的原始碼線索，結果你過度相信第一份報告。若發生這種情況，應該改善 detector 的輸入或擴充 ignore 規則，而不是自行臆測。

跑完第一次後持續迭代

先用第一份報告找出缺口，然後在補上 theme.json、block.json、測試設定或版本 metadata 之後，再重新執行 wp-project-triage。這個技能最適合用來做迭代式防呆：先偵測、再驗證、再調整，最後再偵測一次。