プラグインエコシステムサイト

プラグインディレクトリは、信頼を獲得するか失うかが決まる場所です。訪問者が求めるのは形容詞ではなく、何をするプラグインか、誰が保守しているか、本番利用可能か、どう導入するか、実際の EmDash スタックでどう振る舞うかです。構造化された公開サイトにすることで、散在した README 断片ではなく一貫したページで回答できます。

各プラグインページが示すべきこと

最初に成果を示します。解決する課題、対応環境、運用負荷（Workers、D1、外部 API）です。続いて互換性、バージョン管理、ライセンスを明記します。ソース、ダウンロード、詳細ドキュメントへのリンクも分かりやすく配置します。ベータ版なら明確に示し、データや稼働率への意味を説明します。

具体的な導入ステップ

1. 単一のページテンプレートを定義する。 標準項目には、ステータス、カテゴリ、バージョン、価格モデル、互換性、リポジトリリンク、変更履歴を含めます。統一性があるほど比較しやすくなります。

2. 実態に合った導入手順を公開する。 現在のリポジトリ構造で動くコマンドや設定例を優先します。例えば EmDash モノレポで packages/plugins/<name> が正本なら、その前提で説明します。

3. 意味のある変更ごとにリリースノートを出す。 短い箇条書きでも未記載より有益です。可能なら GitHub の比較ビューやタグ付きリリースにリンクします。

4. 信頼シグナルを追加する。 メンテナー名、サポート窓口、セキュリティ前提はページ上に明記し、チャット依存にしません。外部 API を呼ぶプラグインは必要なシークレットとレート制限も文書化します。

5. ユースケースを相互リンクする。 プラグインが解決するシナリオに結び付けます。例：Forms はリード獲得、Webhook Notifier は自動化、Audit Log は複数編集者チーム向け。

例：新規掲載前の評価

公開前に次を確認します。1 行説明は実際のエクスポート内容と一致するか。スクリーンショットや図は正確か。ライセンス記載は正しいか。新規ユーザーが内部知識なしで導入できるか。1 つでも「いいえ」があれば、宣伝前に必ず修正します。

運用サイクル

毎月：未解決 issue を確認し、ステータス項目を更新。四半期：放置された掲載を廃止または「保守なし」として移行メモを追加。EmDash の大型リリース後：主要プラグインを再検証し、互換性表記を更新します。

成果

開発者はより速くプラグインを発見でき、導入時の想定外が減ります。エコシステムは単なるカタログではなく、実運用インフラとして認識されます。