外掛目錄是建立或失去信任的關鍵位置。訪客不需要華麗形容詞，他們要知道外掛做什麼、誰在維護、是否可用於生產、如何安裝，以及在真實 EmDash 技術棧中的行為。結構化公開站點能把這些答案沉澱為一致頁面，而不是散落各處的 README 片段。
每個外掛頁面應證明什麼
先寫清結果：解決了什麼問題、支援哪些環境、運行依賴為何（Workers、D1、外部 API）。接著補充相容性、版本策略與授權條款。將原始碼、下載與進階文件連結放在明顯位置。若處於 Beta，請明確標註，並說明對資料與可用性的影響。
落地步驟
-
定義統一頁面模板。 標準欄位可包含狀態、分類、版本、定價模型、相容性、倉庫連結與更新日誌。結構一致可幫助使用者快速比較。
-
發布與實際一致的安裝說明。 優先提供能匹配目前倉庫結構的指令與設定片段。例如，當 EmDash 單倉中
packages/plugins/<name>為事實來源時，就應以該路徑為準。 -
每次關鍵變更都發布版本說明。 簡短條列也勝過沒有紀錄。可行時連到 GitHub 比對視圖或標籤發布頁。
-
增加信任訊號。 維護者名稱、支援渠道、安全邊界應寫在頁面上，而不是只在聊天中說明。呼叫第三方 API 的外掛也應文件化所需金鑰與速率限制。
-
關聯使用情境。 將外掛與其解鎖的業務情境對應：Forms 用於名單收集，Webhook Notifier 用於自動化，Audit Log 適合多人編輯團隊。
示例：新外掛上架前評估
頁面上線前請逐項檢查：一句話描述是否與程式碼實際輸出一致？截圖或示意圖是否正確？授權是否正確？新使用者是否能在無內部知識下完成安裝？只要有一項為「否」，請先補齊再推廣。
營運節奏
每月：檢視未關閉 issue 並更新狀態欄位。每季：下架廢棄條目，或標記為「unmaintained」並提供遷移說明。EmDash 大版本後：重測核心外掛並更新相容性說明。
結果
建置者能更快找到外掛、以更少意外完成採用，並把你的生態視為嚴肅基礎設施，而非宣傳型目錄。