<img src="banner.png" width="100%" alt="ellmos-skill-creator banner">

ellmos-skill-creator

Herkunft und Entscheidung (Fork vs. Eigenbau)

Entscheidung: Eigenbau, kein Fork. Begründung, damit sie nicht verlorengeht:

• skill-creator (Anthropic, Marketplace claude-plugins-official) ist Apache-2.0 lizenziert (LICENSE-Text im Klon gelesen und verifiziert, 2026-08-24) — ein Fork wäre rechtlich sauber möglich und ist im Repo an anderer Stelle bereits das etablierte Muster (skills/third-party/grill-me, skills/third-party/grilling).
• Ein Fork hätte aber die komplette Eval-/Benchmark-Maschinerie des Originals mitgeschleppt (agents/{analyzer,comparator,grader}.md, eval-viewer/, 7 Scripts, 485-Zeilen-SKILL.md) — Fähigkeit, die bereits vorhanden und direkt aufrufbar ist (Skill: skill-creator:skill-creator). Nach .PLUGINS/CLAUDE.md Regel 4 ("Fähigkeiten prüfen, bevor nachgebaut wird") und dem Muster P10 ("zwei Schalter, die niemand vergleicht") wäre das Duplikat, keine Erweiterung.
• Die eigentliche Lücke ist rein ellmos-spezifisch und dem Original grundsätzlich unbekannt: Haus-Frontmatter (templates/SKILL.md), docs/CONVENTIONS.md, Anbieter-/User-/ellmos-Neutralität mit ellmos-Sensitivität, grounding-seed-Anbindung, Vendor-Awareness, Selbstaktualisierung.
• Dieser Skill enthält keinen Anthropic-Text (eigene Formulierung durchgehend) — löst also auch keine Apache-2.0-Attributionspflicht für Modifikationen aus. Er komponiert das Original, statt es zu kopieren: das ist zugleich der lizenzrechtlich sauberste und der wartungsärmste Weg.

Wann aktivieren

• "erstelle einen Skill für X", "neuen Skill bauen", "skill-creator nutzen"
• "mach diesen Skill ellmos-konform", "Skill auf Haus-Standard nachrüsten"
• Immer wenn der Zielort ein Skill in .AI/.SKILLS/skills/… (bzw. dessen kanonischer Plan-D-Klon) ist — nicht bei allgemeinen, ökosystemfremden Anfragen ("erstelle mir irgendeinen Claude-Skill ohne Bezug hierher").

Vorgehen

Schritt 1 — Interview/Entwurf/Eval delegieren

Ruf den offiziellen Skill: skill-creator:skill-creator auf für: Intent-Klärung, Entwurf der SKILL.md-Struktur, Testfälle, Eval-Loop, Description-Optimierung (scripts/improve_description.py). Nicht neu erfinden — dieser Teil ist generisch und im Original bereits gut gelöst.

Schritt 2 — ellmos-Haus-Scaffold aufsetzen (Pflicht, additiv zum Original-Format)

Ergänze das vom Original erzeugte SKILL.md um die neun Haus-Felder aus .SKILLS/templates/SKILL.md (bzw. AGENT.md/WORKFLOW.md/PROMPT.md je nach Typ), lies vorher .SKILLS/docs/CONVENTIONS.md für Kategorie-Ordner, Flat-Regel (<5 Dateien flach), Versions-Konvention (SemVer: MAJOR/MINOR/PATCH) und Mehrsprachigkeits-Sets (Core: DE+EN Pflicht). visibility startet immer auf private-only — Veröffentlichung ist eine spätere, geprüfte Nutzerentscheidung (.AI/VISIBILITY-POLICY.md), niemals Default. Diese Felder sind rein additiv zum Anthropic-Format (zusätzliche YAML-Keys neben name/description) — jeder so erzeugte Skill bleibt vollständig anthropic_compatible: true.

Schritt 3 — Prinzipien durchsetzen: anbieterneutral, userneutral, ellmos-neutral-aber-ellmos-sensitiv

Volltext + Codemuster: references/ELLMOS-PRINCIPLES.md. Kurzfassung: der erzeugte Skill muss allein lauffähig sein (bringt alles mit, was er braucht) und zugleich ellmos-Komponenten nutzen, sobald sie da sind — er entscheidet das selbst zur Laufzeit, nie fest verdrahtet. Das ist exakt das Muster, das grounding-seed bereits liefert (README: "cultivated landscape, not wildflower" / "viable alone, more productive together") — kein zweiter Erkennungsmechanismus wird erfunden, dieser Skill verweist produzierte Skills konsequent auf grounding_seed.detect_ecosystem().

Schritt 4 — config.json + connections.json mitliefern

grounding-seed ist bereits als Python-Paket importierbar (verifiziert 2026-08-24: import grounding_seed löst erfolgreich auf den lokal geklonten grounding-seed-Quellbaum auf, Plan-D-Klon) — es ist die kanonische Andockstelle, keine neue Datei erfinden. Für jeden produzierten Skill mit externem Bedarf (Programme, Dienste, Anbieter):

• config.json — Skill-eigene Einstellungen (Vorlage: templates/skill-config.template.json). grounding_seed.store.LocalStore(root) nutzt diesen Dateinamen standardmäßig für seine Rollen-Ablage — ein produzierter Skill kann also entweder sein config.json selbst als LocalStore-Backend verwenden ODER ihn getrennt halten, wenn er neben Rollen auch reine Verhaltens-Einstellungen braucht (dann zweite LocalStore(root, filename="connections.json")-Instanz).
• connections.json — die tatsächlich aufgelösten externen Andockstellen (welches Programm/welcher Dienst wurde gefunden, seit wann, mit welcher Herkunft) — Vorlage: templates/skill-connections.template.json, Schema ellmos.source-resolver.user-config.v1 (identisch zu source-resolver, laut grounding-seed-README bewusst so gewählt, damit eine spätere Migration in den echten source-resolver verlustfrei ist — siehe migration.py dort).

Details, CLI und Codebeispiel: references/ELLMOS-PRINCIPLES.md Abschnitt "Docking".

Schritt 5 — Anbieter-/Vendor-Bewusstsein einbauen

Volltext: references/VENDOR-AWARENESS.md. Kurzfassung: der produzierte Skill bekommt einen Abschnitt "Anbieter & Alternativen", der (a) den/die State-of-the-Art-Anbieter des Themas nennt (z. B. ElevenLabs für TTS), (b) mindestens einen Ersatzanbieter, (c) ellmos-eigene Komponenten explizit als gleichrangigen Kandidaten listet, wenn sie das Thema abdecken (z. B. ellmos-voice-io statt/neben ElevenLabs) — und bei passender Nutzeranforderung Installation/Umstieg vorschlägt, statt sie stillschweigend vorauszusetzen. Grundlage für "was ist auf dem System vorhanden": grounding_seed.scan.scan_resources([...]) (prüft shutil.which) plus .AI/.MCP/MCP-PROFILE-MANAGEMENT.md für ellmos-Kandidaten.

Schritt 6 — Selbstaktualisierung anlegen

Volltext: references/SELF-UPDATE.md. Kurzfassung: jeder produzierte Skill bekommt einen Abschnitt "Selbstaktualisierung", der (a) periodisch eine kurze Web-Recherche vorschlägt, um bei State-of-the-Art zu bleiben, (b) verwandte Skills/Workflows kennt und neue Alternativen benennt, die besser passen könnten, (c) eine kleine Lern-JSON mitführt (Vorlage: templates/skill-connections.template.json, Feld notizen/gelernt), die bei vorhandener ellmos-Memory-Komponente (USMC/Gardener) ausgelagert werden kann statt lokal zu wachsen — auch hier: erkennen statt fest verdrahten (grounding_seed.detect_ecosystem()).

Schritt 6b — Lernvertrag + Usecase-Abdeckung anlegen (wiederverwendbares Muster)

Volltext: references/LEARNING-CONTRACT-AND-COVERAGE.md. Kurzfassung: nicht nur dieser Skill selbst, sondern jeder von ihm produzierte Skill bekommt einen kleinen, wiederverwendbaren Lern-/Abdeckungs-Dateisatz — geprüft gegen etablierte Standards, kein Parallelstandard:

• evals/evals.json — wiederverwenden, nicht duplizieren: das ist bereits der skill-creator-Standard für vom Autor entworfene Testfälle.
• user-usecases.json — vom Nutzer tatsächlich vorgebrachte Anwendungsfälle, formgleich zu evals.json (Vorlage: templates/user-usecases.template.json).
• usecase-gaps.json — Abgleich: welche Nutzer-Usecases sind ungetestet/ungedeckt (Vorlage: templates/usecase-gaps.template.json).
• known-providers-and-abilities.json — Kandidatenraum bekannter Anbieter je Rolle, Felder an A2A/AgentSkill (id/name/description/tags) angelehnt, nicht erfunden (Vorlage: templates/known-providers-and-abilities.template.json).
• gap-closing-analysis.json — strukturelle Schließungswege je Lücke (ellmos-Modul, ellmos-Bundle, Fremdmodul, Neubau) — kein Duplikat von grading.json.eval_feedback (Vorlage: templates/gap-closing-analysis.template.json).
• config.json Feld lernvertrag — Verhaltenscodex (beste Option wählen, User als König, nie selbständig installieren, Update-Intervall) — bewusst als Erweiterung von config.json, keine siebte Datei.

Schemas: .SKILLS/schemas/{user-usecases,usecase-gaps,known-providers, gap-closing-analysis}-v1.schema.json — dieselbe Haus-Konvention wie skill-v1.schema.json. grounding-seed wurde für diesen Dateisatz geprüft und bewusst nicht erweitert (Begründung in LEARNING-CONTRACT-AND-COVERAGE.md) — nur connections.json bleibt sein Teil.

Schritt 7 — Registrieren, testen, committen

• Kategorie-Ordner nach .SKILLS/CLAUDE.md/SKILLS-MAP.md wählen; bei Zweifel skill-finder oder controlcenter_find_skill fragen, ob eine Familie schon existiert.
• testing/ (privacy_gate + Metadaten-Tests) laufen lassen, bevor committet wird.
• Registry-Dateien (registry/components.json, SKILLS-MAP.md, llms.txt) nicht von Hand editieren — die werden generiert (build_public_registry.py, build_skills_map.py, catalog.py). Läuft im kanonischen Klon gerade eine fremde, uncommittete Session, NICHT global regenerieren (mischt fremde und eigene Änderungen in einer Datei) — stattdessen den neuen Skill-Ordner isoliert committen und die Registry-Regeneration dem nächsten sauberen Lauf (skill-register-care) überlassen.
• git commit -- skills/<kategorie>/<name>/ — nur die eigenen, neuen Pfade.

Kompatibilität zum Anthropic-Format

Alle Zusatzfelder sind reine YAML-Erweiterungen neben name/description — ein Standard-Claude-Code ohne dieses Ökosystem liest weiterhin nur name/description und ignoriert den Rest. config.json/connections.json sind optionale Bundled Resources (wie in docs/CONVENTIONS.md vorgesehen), keine Pflicht-Abhängigkeit — ein Skill ohne sie funktioniert unverändert.

Verwandte Skills

• skill-creator:skill-creator — generische Interview-/Eval-Schleife (delegiert an, Schritt 1).
• skill-finder — Router für vorhandene eigene Skills (VOR dem Bauen prüfen: gibt es das schon?).
• skill-explorer — Landschafts-Audit + Web-Recherche nach neuen Skills/Plugins (Meta-Ebene: unser Skill-Bestand; dieser Skill hier macht stattdessen jeden einzelnen produzierten Skill selbst anbieterbewusst).
• skill-family-care, skill-register-care — Pflege nach dem Bauen.
• grounding-seed (Modul, .AI/.MODULES/.CONTROL/grounding-seed) — die tatsächliche Andock-/Selbstversorgungs-Logik, hier nur referenziert, nicht dupliziert.

Changelog

0.2.0 (2026-08-24)

• Nachtrag (Ticket T-20260824-218233618, Scope-Ergänzung): wiederverwendbares Lern-/Abdeckungs-Muster je produziertem Skill ergänzt — user-usecases.json, usecase-gaps.json, known-providers-and-abilities.json, gap-closing-analysis.json (neue Haus-Schemas in .SKILLS/schemas/) plus Lernvertrag-Feld in config.json. evals/evals.json (skill-creator) bewusst wiederverwendet statt dupliziert. grounding-seed geprüft — keine Erweiterung nötig (Begründung in references/LEARNING-CONTRACT-AND-COVERAGE.md), daher kein Folgeticket. Feldnamen für Anbieterkataloge an A2A-Protokoll (AgentSkill) angelehnt statt eigenes Vokabular.

0.1.0 (2026-08-24)

• Erstfassung. Entscheidung Eigenbau statt Fork getroffen und begründet (Ticket T-20260824-218233618). Delegiert generische Skill-Erstellung an skill-creator:skill-creator, ergänzt Haus-Scaffold, ellmos-Prinzipien, grounding-seed-Anbindung (config.json/connections.json), Vendor-Awareness und Selbstaktualisierung.