wp-plugin-development

wp-plugin-development skill 總覽

wp-plugin-development 是一個以 WordPress 為核心的 skill，適合用來建立、重構與加固外掛，比起一般通用提示詞，能少很多猜測。它最適合處理外掛架構、hooks、啟用/停用/解除安裝行為、管理後台設定、資料儲存、cron jobs，以及安全性敏感的程式路徑。

這個 wp-plugin-development skill 是做什麼的

當你的任務不只是「寫一段 PHP」，而是「讓這個外掛在 WordPress 裡正確運作」時，就該使用 wp-plugin-development skill。它特別能幫你處理那些最常卡住進度的決策：bootstrap 檔應該放哪裡、hooks 要怎麼註冊、設定要如何安全儲存，以及在生命週期事件發生時該做什麼。

最適合的 wp-plugin-development 使用者與專案

這個 skill 很適合獨立外掛的後端開發、較大型 WordPress repo 內的外掛模組，以及既有 codebase 的維護工作。當你需要的是一份尊重 WordPress 慣例、而不是自己硬造一套框架的 wp-plugin-development 指南時，它特別有幫助。

wp-plugin-development skill 的差異在哪裡

它最大的價值在於工作流程紀律：在你動手改 code 之前，先帶你檢查外掛入口點、生命週期規則、安全防護線，以及支援性的參考檔。這讓 wp-plugin-development 比一次性的提示更實用，因為它是按正確順序來安排安裝、檢視與實作。

如何使用 wp-plugin-development skill

安裝並確認外掛目標

請在你正在編輯的 repo 情境中使用 wp-plugin-development 安裝指令：

npx skills add WordPress/agent-skills --skill wp-plugin-development

安裝完成後，先確認你實際要處理的是哪個外掛。在完整的站點 repo 中，先找出 wp-content/plugins/ 或 mu-plugins/ 底下正確的外掛，再開始修改。這是最常見的失敗點之一。

先提供正確的起始資訊給 skill

如果你一開始就提供這些資訊，效果最好：repo root、外掛路徑或主檔案（如果已知）、WordPress/PHP 版本，以及網站是 single-site 還是 multisite。如果你的目標牽涉到 WP-CLI 或發佈封裝，也要一開始就說明。這些細節會影響 API 選擇、相容性，以及建議的修正是否安全可套用。

用清楚點名工作的提示詞

好的輸入要具體，不要太寬泛。例如：

• “Refactor the plugin bootstrap so admin-only hooks are loaded lazily.”
• “Add a settings page with sanitization, capabilities, and saved defaults.”
• “Fix the activation routine so rewrite rules are flushed only after registration.”
• “Audit this plugin for nonce, escaping, and SQL safety issues.”

這些提示能幫 wp-plugin-development skill 走到正確路徑，而不是猜測你要的是結構、生命週期、設定，還是安全性工作。

先讀這些檔案

先從 SKILL.md 開始，再檢查 references/structure.md、references/lifecycle.md、references/settings-api.md、references/security.md、references/data-and-cron.md 和 references/debugging.md。如果 repo 內有這個腳本，就執行 scripts/detect_plugins.mjs，可以快速找出 plugin headers。這個順序能讓你最快從安裝走到可用輸出。

wp-plugin-development skill 常見問答

wp-plugin-development 只適合新外掛嗎？

不是。它同樣適合既有外掛的重構、修 bug 與整理清理。實務上，很多 wp-plugin-development 的使用情境，都是在修正已存在程式裡的 hook 時機、生命週期行為或安全性錯誤。

什麼情況下不該使用這個 skill？

如果你沒有在修改 WordPress 外掛程式碼，就不要用它。對一般 PHP 函式庫、只做主題的工作，或完全不碰外掛行為的 UI 文案修改，它都不算合適。如果你的任務不屬於 WordPress 外掛的後端開發，建議會太過特化。

這比一般提示詞更好嗎？

如果任務需要 WordPress 特有的決策，那答案是肯定的。一般提示詞可能也能產生可運作的 PHP，但 wp-plugin-development skill 會在 bootstrap 結構、activation hooks、Settings API 用法，以及 sanitization/escaping 上加上防護，讓結果更容易部署。

對初學者友善嗎？

友善，只要你能說明外掛目標，以及想修改哪個檔案。初學者通常最能受益於這個 skill 的檔案閱讀路徑，以及它在改 code 前先告訴你「應該先檢查什麼」的重點。

如何改進 wp-plugin-development skill

提供真正的限制條件，不只是功能需求

要讓結果最快變好，最重要的是把真正的限制一起說清楚：相容版本、multisite 行為、外掛是否已經上線，或你需要的是最小修補還是整理式重構。這能幫 wp-plugin-development skill 避開那些理論上正確、但對你的發佈流程不對的改動建議。

展示外掛目前的樣貌

如果你想要更好的 code changes，請提供主外掛檔、相關 class 名稱，以及目前的 hook 流程。例如：「bootstrap 在 my-plugin.php，admin code 會無條件載入，而且設定都存在單一 option array 裡。」這樣 skill 才有足夠脈絡，提出符合現有 repo 的結構，而不是硬塞一個新架構。

要求你真的能直接套用的輸出

好的需求會直接告訴 skill 你要回什麼：patch 計畫、逐檔編修策略、安全性檢查，或發佈清單。如果你需要的是針對特定成果的 wp-plugin-development 指南，就明確說你要「安全的最小變更」還是「更乾淨的架構，但要考慮 breaking changes」。

從症狀一路迭代到修正

如果第一次回覆太廣，就把問題縮到失敗模式本身：「activation hook 沒有觸發」、「settings 沒有儲存」、「cron 跑了兩次」或「nonce 檢查通過了，但缺少授權」。最有用的改進迴圈是：症狀 → 對應的參考檔 → 程式修改 → 再次檢查。這樣才能讓 skill 一直聚焦在真正阻礙採用的那一段外掛邏輯。