コホートパッケージング契約Copy Anchor Link

このドキュメントは、コホートのパッケージングとプラグインマニフェストに関する、下流で利用できる安定した契約を規定します。 コンシューマーはこの契約を読んで、コホートを列挙し、ハーネスごとのネイティブターゲットをマッピングを再導出せずに解決します。

アーティファクトCopy Anchor Link

コホートマニフェストの形状Copy Anchor Link

コホートマニフェストは、3 つのキーを持つトップレベルのオブジェクトです。

• version — マニフェストの SemVer 文字列。
• cohorts[] — コホートごとに 1 つのエントリ。各エントリは id（閉じた集合 core | developer | security | research | ai-engineering | full のいずれか）、name、 description、members（メンバー識別子をカタログタイプ別にまとめたオブジェクト: skills / agents / commands / rules / hooks）を持ちます。
• per_harness_targets — 解決の契約（後述）。

各メンバー識別子は安定したケバブケースの名前で、src/apothem/ 配下の実在するアーティファクトに対応します （skills/<name>/、agents/<name>.md、commands/<name>.md、rules/<name>.md、またはフックのエントリ — 実行可能な hooks/<name>.py か、ディスパッチャーを通じて配信される hooks/messages/<name>.md のアドバイザリーメッセージコンテキストのいずれか）。

コホートの列挙Copy Anchor Link

コンシューマーは cohort-manifest.yaml を読み込み、cohort.schema.json に対して検証してから、cohorts[] を反復処理します。 各コホートについて members.<type> を読み取り、各カタログタイプのメンバー識別子を取得します。

ハーネスごとのネイティブターゲットの解決（再導出なし）Copy Anchor Link

コホートマニフェストは、ハーネスのマッピングを再記述しません。 代わりに、per_harness_targets.source が、唯一の信頼できる情報源である lib/propagation-manifest.yaml を指します。 解決ルールは次のとおりです。

カタログタイプ T（skills、agents、commands、rules、hooks のいずれか）の コホートメンバーと、ターゲットハーネス H（per_harness_targets.harnesses に列挙されたもののいずれか）について、 ネイティブプラグインターゲットは、lib/propagation-manifest.yaml の harnesses.H.install 配下にあり、source が T/ に一致するエントリの target フィールドです。

たとえば、claude_code 向けにインストールされる core コホートのスキルは、 source: "skills/" を持つ harnesses.claude_code.install エントリを通じて target: "${HARNESS_ROOT}/skills/" に解決されます。 同じスキルは、opencode では ${HARNESS_ROOT}/skills/ に、gemini_cli では ${PROJECT_ROOT}/.gemini/skills/ に解決されます。 コンシューマーがハーネスターゲットを独自に作り出すことは決してありません — 参照して調べます。

${HARNESS_ROOT} / ${PROJECT_ROOT} プレースホルダーは、インストール時に各ハーネスアダプターによって解決されます。 コホートのコンシューマーは、解決済みの target をそのまま扱います。

プラグインマニフェストの役割Copy Anchor Link

plugin.schema.json は plugin.json を記述します。これは、必須の name、SemVer の version、description を持つ、 カタログメンバー（skills / commands / agents / hooks / rules）の自己記述的なバンドルです。 任意のメタデータは、displayName（name の代わりに表示される名前）と、プラグインディレクトリへの掲載用フィールドである documentationUrl、supportUrl、privacyPolicyUrl、termsOfServiceUrl（それぞれ https:// の URL）、 さらにプラグイン内の icon パスを扱います。 生成される Claude Code パッケージは、displayName、documentationUrl、supportUrl を設定します。 Anthropic のディレクトリは掲載用フィールドを読み取り、Claude Code は読み込み時にそれらを無視します。 claude.ai のマーケットプレイス同期は、この 2 つのリンクを認識されないキーとして報告して取り除くため、そこでのマーケットプレイスには「1 with warnings」と表示されます。 この警告は想定どおりであり、プラグインは変わらずに読み込まれます。 プラグインマニフェストは、ハーネスアダプターがそのネイティブプラグイン面にマテリアライズする単位です。 コホートはプラグインがどのメンバーを携えるかを選択し、伝播マニフェストはそれらのメンバーがハーネスごとにどこへ配置されるかを解決します。

パッケージングの決定 — 1 つの包括バンドル、論理的なコホートCopy Anchor Link

コホートは論理的な選択レイヤー（このマニフェスト）であり、それぞれ独立してインストールできる別々のバンドルの集合ではありません。 Apothem は完全なカタログを携える 1 つの包括バンドルを出荷します。 コホートマニフェストはコンシューマーが一貫したサブセットを選べるようにし、伝播マニフェストは選択された各メンバーがハーネスごとにどこへ配置されるかを解決します。

カタログをコホートごとの別々のバンドルに分割すること（たとえば developer / security / research のファミリーごとに 1 つのバンドル）は、 主要な配布面が文書化しているメタプラグインのシンボリックリンクパターンを使えば、リポジトリレベルの重複なしに実現可能です。 1 つのマーケットプレイスカタログが複数のコホートプラグインを列挙し、各コホートプラグインのディレクトリは、 コピーではなく、単一ソースの共有カタログを指すシンボリックリンクを保持します。 コホートがインストールされると、ハーネスはマーケットプレイス内の各シンボリックリンクを逆参照し — ターゲットの内容をそのコホートのキャッシュへコピーし — その結果、インストールされたコホートは自己完結する一方で、リポジトリはシンボリックリンクで配線された 1 つの信頼できる情報源を保持します （重複排除の規律が好むとおり、冗長性ではなく配線です）。 コホートバンドルがカタログを「機械的に重複させる」という以前の解釈は、インストール時のキャッシュの重複 （ハーネスの通常のプラグインごとのコピー）とリポジトリの重複を混同していました。シンボリックリンクパターンは後者を回避します。

Apothem が現在 1 つの包括バンドルを出荷しているのは、それが最も単純な配布面だからであり、コホートが機械的に不可能だからではありません。 コホートごとの形式を採用することは、重複排除の違反ではなく、本当の意味での UX と保守のトレードオフです。 利点は「このファミリーだけをインストールする」という、よりきめ細かい体験です。 コストは、N 個のコホートシンボリックリンクディレクトリとそのマーケットプレイスエントリの保守、より大きなコンフォーミティ / テスト / ゴールデンの面、 そしてコホートごとのインストール時のキャッシュコピーです。 上記の論理的なコホートレイヤーは、単一のバンドルから「必要なものだけをインストールする」という選択の成果をすでに提供しています。 コホートごとのパッケージングは、よりきめ細かいインストール UX が求められるときにはいつでも次のステップになります。