Skill-Factory
Baut einen Skill so, wie es ein sorgfältiger Maintainer tun würde, und hält die Veröffentlichung dann zurück, bis der Benutzer sie genehmigt. Funktioniert in jedem Agenten; jeder Schritt benennt das beste Werkzeug und einen Fallback, der immer funktioniert.
Eingabe: eine Skill-Idee oder ein Drop, den loot mit seinen Nachweisen (Abfrage, Suchergebnisse, Beweis, Randfall) übergeben hat. Zielordner: dort, wo der Benutzer es angibt, sonst ../<slug> außerhalb der Historie des aktuellen Repos.
1. Spezifikation
Schreibe SPEC.md: Ziel, Ein- und Ausgaben sowie eine Abnahmeliste, bei der jede Zeile testbar ist. Auf einer Seite. Wenn loot das Element übergeben hat, verwende dessen Nachweise erneut, anstatt erneut zu suchen. Frage den Benutzer nur dann, wenn zwei Interpretationen der Idee zu unterschiedlichen Skills führen würden.
2. Bauen, Tests zuerst
- Wenn der Agent einen Skill-Authoring-Helfer hat (in Claude Code:
anthropic-skills:skill-creator), verwende ihn für den Skill und seine Auswertungen. - Sonst schreibe
SKILL.mdselbst: Frontmatter mitname(kebab-case) und einerdescription, die sagt, was es tut und wann es ausgelöst wird, dann die Schritte. - Skripte erhalten Tests vor dem Code (
node:testoder pytest). Implementiere, bis sie bestehen. Schreibe Dateien mit deinem Dateibearbeitungswerkzeug, nicht mit Shell-Heredocs. - Führe jeden Test und jede Auswertung aus. Behalte den genauen Befehl und seine Ausgabe für Schritt 4.
3. Unabhängige Prüfung
Der Ersteller benotet seine eigene Arbeit nicht.
- Am besten: Starte einen Subagenten, der diese Unterhaltung nicht gesehen hat. Gib ihm nur den Zielordner und
references/release-checklist.mdmit dieser Kurzanweisung: „Prüfe den Skill in anhand der Checkliste. Antworte BESTANDEN oder NICHT BESTANDEN pro Punkt mit Datei:Zeilen-Nachweis. Wenn unsicher, NICHT BESTANDEN. Markiere jede Behauptung, die die Tests oder Auswertungen nicht belegen.“ - Fallback: Keine Subagenten: Schreibe für jeden Checklistenpunkt das stärkste Argument, dass er NICHT BESTANDEN ist, bevor du entscheidest.
Behebe jedes NICHT BESTANDEN, führe Tests erneut aus, prüfe erneut. Höre auf, wenn alle Punkte bestanden sind oder wenn ein Punkt beim Benutzer blockiert ist (sage welcher und warum).
4. Freigabesperre
Suche nach Geheimnissen: node <loot skill folder>/scripts/scan.mjs <ordner>, plus gitleaks dir <ordner> falls installiert. Zeige dem Benutzer dann ein Manifest und warte auf ein klares Ja:
- Repo-Name, öffentlich oder privat
- Version und Changelog-Eintrag
- die zu veröffentlichenden Dateien
- Testergebnisse und Auswertungsergebnisse (Befehl + Anzahl bestandener Tests), das Prüfergebnis
- alles, was übersprungen wurde
Ein „Ja“ deckt genau dieses Manifest ab. Dann veröffentliche ab einem frischen git init: Commit release vX.Y.Z, Tag, gh repo create und Push, und installiere den Skill dort, wo der Agent des Benutzers Skills lädt. Kein gh oder nicht angemeldet: Gib die Befehle aus. Niemals nach Anmeldedaten fragen, sie eingeben oder speichern.
5. Bericht
Eine kurze Nachricht in einfacher Sprache: Links, Testergebnisse, Prüfergebnis und was für den Benutzer noch zu tun bleibt.