插件目录是建立或失去信任的关键位置。访客不需要华丽形容词，他们要知道插件做什么、谁在维护、是否可用于生产、如何安装、以及在真实 EmDash 栈中的行为。结构化的公开站点能把这些答案沉淀成一致页面，而不是散落在各处的 README 片段。
每个插件页面应证明什么
先写清结果：解决了什么问题、支持哪些环境、运行依赖是什么（Workers、D1、外部 API）。然后补充兼容性、版本策略与许可证。把源码、下载、深度文档链接放在显眼位置。若处于 Beta，请明确标注，并说明对数据与可用性的影响。
落地步骤
-
定义统一页面模板。 标准字段可包括状态、分类、版本、定价模型、兼容性、仓库链接、更新日志。统一结构可帮助用户快速比较。
-
发布与现实一致的安装说明。 优先提供能匹配当前仓库结构的命令和配置片段。例如，当 EmDash 单仓中
packages/plugins/<name>是事实来源时，就按该路径说明。 -
每次关键变更都发布版本说明。 简短要点也好过无记录。可行时链接到 GitHub 对比视图或标签发布页。
-
增加信任信号。 维护者名称、支持渠道、安全边界应写在页面上，而不是只在聊天里说明。调用第三方 API 的插件还应文档化所需密钥与速率限制。
-
关联使用场景。 将插件与其解锁的业务场景关联起来：Forms 用于线索收集，Webhook Notifier 用于自动化，Audit Log 适用于多人编辑团队。
示例：新插件上架前评估
页面上线前请逐项检查：一句话描述是否与代码实际导出一致？截图或示意图是否准确？许可证是否正确？新用户能否在无内部知识前提下完成安装？只要有一项为“否”，先补齐再推广。
运营节奏
每月：审查未关闭 issue 并更新状态字段。每季度：下线废弃条目，或标注“unmaintained”并提供迁移说明。EmDash 大版本后：复测核心插件并更新兼容性说明。
结果
构建者可以更快发现插件、以更少意外完成采用，并将你的生态视作严肃基础设施，而不是宣传手册。