Vertrag zur Kohorten-PaketierungCopy Anchor Link

Dieses Dokument spezifiziert den stabilen, nachgelagert nutzbaren Vertrag für die Kohorten-Paketierung und Plugin-Manifeste. Ein Konsument liest diesen Vertrag, um Kohorten aufzuzählen und ihre harness-spezifischen nativen Ziele aufzulösen, ohne die Zuordnung neu abzuleiten.

ArtefakteCopy Anchor Link

Form des Kohorten-ManifestsCopy Anchor Link

Das Kohorten-Manifest ist ein Objekt auf oberster Ebene mit drei Schlüsseln:

• version — SemVer-Zeichenkette des Manifests.
• cohorts[] — ein Eintrag je Kohorte. Jeder Eintrag hat id (aus der geschlossenen Menge core | developer | security | research | ai-engineering | full), name, description und members (ein Objekt, das die Mitgliedsbezeichner nach Katalogtyp gruppiert: skills / agents / commands / rules / hooks).
• per_harness_targets — der Auflösungsvertrag (siehe unten).

Jeder Mitgliedsbezeichner ist ein stabiler Name in Kebab-Case, der einem realen Artefakt unter src/apothem/ entspricht (skills/<name>/, agents/<name>.md, commands/<name>.md, rules/<name>.md oder einem Hooks-Eintrag — entweder ein ausführbares hooks/<name>.py oder ein beratender Nachrichtenkontext unter hooks/messages/<name>.md, der über den Dispatcher ausgeliefert wird).

Kohorten aufzählenCopy Anchor Link

Ein Konsument lädt cohort-manifest.yaml, validiert es gegen cohort.schema.json und iteriert dann über cohorts[]. Für jede Kohorte liest er members.<type>, um die Mitgliedsbezeichner jedes Katalogtyps zu erhalten.

Harness-spezifische native Ziele auflösen (ohne Neuableitung)Copy Anchor Link

Das Kohorten-Manifest wiederholt die Harness-Zuordnung nicht. Stattdessen zeigt per_harness_targets.source auf lib/propagation-manifest.yaml, die einzige maßgebliche Quelle. Die Auflösungsregel:

Für ein Kohortenmitglied des Katalogtyps T (einer von skills, agents, commands, rules, hooks) und einen Ziel-Harness H (einer der in per_harness_targets.harnesses aufgeführten) ist das native Plugin-Ziel das Feld target des Eintrags in lib/propagation-manifest.yaml unter harnesses.H.install, dessen source mit T/ übereinstimmt.

Zum Beispiel wird ein Skill der Kohorte core, der für claude_code installiert wird, über den Eintrag harnesses.claude_code.install mit source: "skills/" zu target: "${HARNESS_ROOT}/skills/" aufgelöst. Derselbe Skill wird für opencode zu ${HARNESS_ROOT}/skills/ aufgelöst, für gemini_cli zu ${PROJECT_ROOT}/.gemini/skills/. Konsumenten erfinden niemals Harness-Ziele — sie schlagen sie nach.

Die Platzhalter ${HARNESS_ROOT} / ${PROJECT_ROOT} werden zur Installationszeit von jedem Harness-Adapter aufgelöst; Kohorten-Konsumenten übernehmen das aufgelöste target wörtlich.

Rolle des Plugin-ManifestsCopy Anchor Link

plugin.schema.json beschreibt ein plugin.json — ein selbstbeschreibendes Bundle von Katalogmitgliedern (skills / commands / agents / hooks / rules) mit den erforderlichen Feldern name, version (SemVer) und description. Optionale Metadaten umfassen displayName (der Name, der anstelle von name angezeigt wird) und die Felder für den Eintrag im Plugin-Verzeichnis: documentationUrl, supportUrl, privacyPolicyUrl und termsOfServiceUrl, jeweils eine https://-URL, sowie einen icon-Pfad innerhalb des Plugins. Das generierte Claude Code-Paket setzt displayName, documentationUrl und supportUrl. Das Verzeichnis von Anthropic liest die Felder für den Verzeichniseintrag, und Claude Code ignoriert sie beim Laden. Die Marketplace-Synchronisierung von claude.ai meldet die beiden Links als nicht erkannte Schlüssel und entfernt sie, sodass der Marketplace dort „1 with warnings“ anzeigt. Diese Warnung ist erwartet, und das Plugin lädt unverändert. Ein Plugin-Manifest ist die Einheit, die ein Harness-Adapter in seine native Plugin-Oberfläche materialisiert; Kohorten wählen aus, welche Mitglieder ein Plugin trägt, und das Propagation-Manifest löst auf, wo diese Mitglieder je Harness landen.

Paketierungsentscheidung — ein Dach-Bundle, logische KohortenCopy Anchor Link

Kohorten sind eine logische Auswahlschicht (dieses Manifest), keine Menge separater, unabhängig installierbarer Bundles. Apothem liefert ein Dach-Bundle aus, das den vollständigen Katalog trägt; das Kohorten-Manifest lässt einen Konsumenten eine kohärente Teilmenge auswählen, und das Propagation-Manifest löst auf, wo jedes ausgewählte Mitglied je Harness landet.

Den Katalog in separate Bundles je Kohorte aufzuteilen (z. B. ein Bundle je Familie developer / security / research), ist ohne Duplizierung auf Repository-Ebene erreichbar, und zwar über das dokumentierte Meta-Plugin-Symlink-Muster der primären Distributionsoberfläche: Ein Marketplace-Katalog listet mehrere Kohorten-Plugins, und jedes Kohorten-Plugin-Verzeichnis enthält Symlinks in den gemeinsamen Katalog aus einer einzigen Quelle statt Kopien. Wenn eine Kohorte installiert wird, dereferenziert der Harness jeden Symlink innerhalb des Marketplace — er kopiert den Inhalt des Ziels in den Cache dieser Kohorte —, sodass die installierte Kohorte eigenständig ist, während das Repository eine einzige maßgebliche Quelle behält, die über Symlinks verdrahtet ist (Verdrahtung statt Redundanz, genau wie es die Deduplizierungsdisziplin bevorzugt). Die frühere Lesart, dass Kohorten-Bundles den Katalog „mechanisch duplizieren“, verwechselte die Duplizierung im Cache zur Installationszeit (die normale Kopie je Plugin durch den Harness) mit der Duplizierung im Repository; das Symlink-Muster vermeidet Letztere.

Apothem liefert derzeit ein Dach-Bundle aus, weil das die einfachste Distributionsoberfläche ist, nicht weil Kohorten mechanisch unmöglich wären. Die Form je Kohorte zu übernehmen, ist eine echte Abwägung zwischen UX und Wartung, kein Verstoß gegen die Deduplizierung: Der Vorteil ist ein feineres Erlebnis im Sinne von „nur diese Familie installieren“; die Kosten sind die Pflege von N Kohorten-Symlink-Verzeichnissen samt ihren Marketplace-Einträgen, eine größere Konformitäts- / Test- / Golden-Oberfläche und Cache-Kopien je Kohorte zur Installationszeit. Die obige logische Kohortenschicht liefert das Auswahl-Ergebnis „nur installieren, was Sie brauchen“ bereits aus dem einzelnen Bundle; die Paketierung je Kohorte ist der nächste Schritt, sobald die feinere Installations-UX gewünscht ist.