Communitygithub.com

grahama1970/skill-creator

Leitfaden zur Erstellung effektiver Skills. Dieses Skill sollte verwendet werden, wenn Benutzer einen neuen Skill erstellen (oder einen bestehenden aktualisieren) möchten, der die Fähigkeiten von Codex mit spezialisiertem Wissen, Workflows oder Tool-Integrationen erweitert.

Was ist skill-creator?

Dieses Skill dient als umfassender Leitfaden zur Entwicklung modularer, selbstständiger Skills, die Codex von einem allgemeinen KI-Agenten in einen spezialisierten Assistenten für bestimmte Domänen oder Aufgaben verwandeln. Es beschreibt die Kernprinzipien effektiver Skills: Prägnanz (Kontextfenster als öffentliches Gut), abgestufte Handlungsfreiheit (je nach Aufgabenstabilität), Integrität der Validierung (Einsatz von Sub-Agenten zur unabhängigen Überprüfung) und die Anatomie eines Skills mit erforderlichen und optionalen Komponenten. Das Skill erklärt das progressive Offenlegungsdesign mit einer dreistufigen Ladehierarchie (Metadaten, SKILL.md, gebündelte Ressourcen), um den Kontext effizient zu verwalten, und gibt detaillierte Richtlinien zur Vermeidung überflüssiger Dateien und zur Strukturierung von Referenzen. Der Erstellungsprozess umfasst sechs Schritte: Verständnis anhand konkreter Beispiele, Planung der wiederverwendbaren Inhalte (Skripte, Referenzen, Assets), Initialisierung, Bearbeitung, Validierung und Iteration. Es unterstützt die Plattformen Codex und Codex CLI und zielt darauf ab, sowohl Entwickler als auch KI-Agenten zu befähigen, wiederverwendbare, token-effiziente und deterministisch zuverlässige Skills zu erstellen.

Funktioniert mit✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/grahama1970/agent-skills/tree/main/skills/.system/skill-creator

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Skill Creator

Dieses Skill bietet eine Anleitung zur Erstellung effektiver Skills.

Über Skills

Skills sind modulare, in sich geschlossene Ordner, die die Fähigkeiten von Codex erweitern, indem sie spezialisiertes Wissen, Workflows und Werkzeuge bereitstellen. Stellen Sie sie sich als "Onboarding-Anleitungen" für bestimmte Domänen oder Aufgaben vor – sie verwandeln Codex von einem通用-KI-Agenten in einen spezialisierten Agenten, der mit prozeduralem Wissen ausgestattet ist, über das kein Modell vollständig verfügen kann.

Was Skills bieten

  1. Spezialisierte Workflows – Mehrschrittige Verfahren für bestimmte Domänen
  2. Tool-Integrationen – Anleitungen für die Arbeit mit bestimmten Dateiformaten oder APIs
  3. Domänenexpertise – Unternehmensspezifisches Wissen, Schemata, Geschäftslogik
  4. Gebündelte Ressourcen – Skripte, Referenzen und Assets für komplexe und wiederkehrende Aufgaben

Kernprinzipien

Prägnanz ist entscheidend

Das Kontextfenster ist ein Gemeinschaftsgut. Skills teilen sich das Kontextfenster mit allem, was Codex sonst noch benötigt: System-Prompt, Konversationsverlauf, Metadaten anderer Skills und die eigentliche Benutzeranfrage.

Standardannahme: Codex ist bereits sehr intelligent. Fügen Sie nur Kontext hinzu, den Codex nicht bereits hat. Hinterfragen Sie jede Information: "Braucht Codex diese Erklärung wirklich?" und "Rechtfertigt dieser Absatz seine Token-Kosten?"

Bevorzugen Sie prägnante Beispiele gegenüber ausführlichen Erklärungen.

Angemessene Freiheitsgrade festlegen

Passen Sie die Spezifität an die Fragilität und Variabilität der Aufgabe an:

Hohe Freiheit (textbasierte Anweisungen): Verwenden Sie, wenn mehrere Ansätze gültig sind, Entscheidungen vom Kontext abhängen oder Heuristiken den Ansatz leiten.

Mittlere Freiheit (Pseudocode oder Skripte mit Parametern): Verwenden Sie, wenn ein bevorzugtes Muster existiert, etwas Variation akzeptabel ist oder die Konfiguration das Verhalten beeinflusst.

Niedrige Freiheit (spezifische Skripte, wenige Parameter): Verwenden Sie, wenn Operationen fragil und fehleranfällig sind, Konsistenz entscheidend ist oder eine bestimmte Sequenz befolgt werden muss.

Stellen Sie sich Codex vor, der einen Pfad erkundet: Eine schmale Brücke mit Klippen benötigt spezifische Schutzleitplanken (niedrige Freiheit), während ein offenes Feld viele Routen (hohe Freiheit) erlaubt.

Validierungsintegrität schützen

Sie können Sub-Agenten während der Iteration verwenden, um zu validieren, ob ein Skill an realistischen Aufgaben funktioniert oder ob ein vermutetes Problem tatsächlich besteht. Dies ist am nützlichsten, wenn Sie nach einer Überarbeitung eine unabhängige Überprüfung des Verhaltens, der Ausgaben oder der Fehlermodi des Skills wünschen. Tun Sie dies nur, wenn es möglich ist, neue Sub-Agenten zu starten.

Wenn Sie Sub-Agenten zur Validierung verwenden, behandeln Sie dies als Evaluierungsoberfläche. Ziel ist es zu erfahren, ob der Skill generalisiert, nicht ob ein anderer Agent die Antwort aus durchgesickertem Kontext rekonstruieren kann.

Bevorzugen Sie rohe Artefakte wie Beispiel-Prompts, Ausgaben, Diffs, Logs oder Traces. Geben Sie den minimalen aufgabenlokalen Kontext, der zur Durchführung der Validierung erforderlich ist. Vermeiden Sie es, die beabsichtigte Antwort, den vermuteten Fehler, die beabsichtigte Korrektur oder Ihre vorherigen Schlussfolgerungen zu übermitteln, es sei denn, die Validierung erfordert diese explizit.

Anatomie eines Skills

Jeder Skill besteht aus einer erforderlichen SKILL.md-Datei und optionalen gebündelten Ressourcen:

skill-name/
├── SKILL.md (erforderlich)
│   ├── YAML-Frontmatter-Metadaten (erforderlich)
│   │   ├── name: (erforderlich)
│   │   └── description: (erforderlich)
│   └── Markdown-Anweisungen (erforderlich)
├── agents/ (empfohlen)
│   └── openai.yaml – UI-Metadaten für Skill-Listen und Chips
└── Gebündelte Ressourcen (optional)
    ├── scripts/          – Ausführbarer Code (Python/Bash/etc.)
    ├── references/       – Dokumentation, die bei Bedarf in den Kontext geladen wird
    └── assets/           – In der Ausgabe verwendete Dateien (Vorlagen, Icons, Schriftarten, etc.)

SKILL.md (erforderlich)

Jede SKILL.md besteht aus:

  • Frontmatter (YAML): Enthält die Felder name und description. Dies sind die einzigen Felder, die Codex liest, um zu bestimmen, wann der Skill verwendet wird. Daher ist es sehr wichtig, klar und umfassend zu beschreiben, was der Skill ist und wann er verwendet werden sollte.
  • Body (Markdown): Anweisungen und Anleitungen zur Verwendung des Skills. Wird NACH dem Auslösen des Skills geladen (falls überhaupt).

Agenten-Metadaten (empfohlen)

  • UI-Metadaten für Skill-Listen und Chips
  • Lesen Sie references/openai_yaml.md, bevor Sie Werte generieren, und befolgen Sie dessen Beschreibungen und Einschränkungen
  • Erstellen Sie menschenlesbare display_name, short_description und default_prompt, indem Sie den Skill lesen
  • Generieren Sie deterministisch, indem Sie die Werte als --interface key=value an scripts/generate_openai_yaml.py oder scripts/init_skill.py übergeben
  • Bei Aktualisierungen: Überprüfen Sie, ob agents/openai.yaml noch mit SKILL.md übereinstimmt; bei Veraltung neu generieren
  • Fügen Sie andere optionale Schnittstellenfelder (Icons, Markenfarbe) nur hinzu, wenn sie explizit angegeben wurden
  • Siehe references/openai_yaml.md für Felddefinitionen und Beispiele

Gebündelte Ressourcen (optional)

Skripte (scripts/)

Ausführbarer Code (Python/Bash/etc.) für Aufgaben, die deterministische Zuverlässigkeit erfordern oder wiederholt neu geschrieben werden.

  • Wann einbinden: Wenn derselbe Code wiederholt neu geschrieben wird oder deterministische Zuverlässigkeit erforderlich ist
  • Beispiel: scripts/rotate_pdf.py für PDF-Drehaufgaben
  • Vorteile: Token-effizient, deterministisch, kann ohne Laden in den Kontext ausgeführt werden
  • Hinweis: Skripte müssen möglicherweise dennoch von Codex gelesen werden, um Patches oder umgebungsspezifische Anpassungen vorzunehmen
Referenzen (references/)

Dokumentation und Referenzmaterial, das bei Bedarf in den Kontext geladen wird, um Codex' Prozess und Denken zu informieren.

  • Wann einbinden: Für Dokumentation, auf die Codex während der Arbeit verweisen soll
  • Beispiele: references/finance.md für Finanzschemata, references/mnda.md für die unternehmenseigene NDA-Vorlage, references/policies.md für Unternehmensrichtlinien, references/api_docs.md für API-Spezifikationen
  • Anwendungsfälle: Datenbankschemata, API-Dokumentation, Domänenwissen, Unternehmensrichtlinien, detaillierte Workflow-Anleitungen
  • Vorteile: Hält SKILL.md schlank, wird nur geladen, wenn Codex es für nötig hält
  • Best Practice: Wenn Dateien groß sind (>10.000 Wörter), fügen Sie grep-Suchmuster in SKILL.md ein
  • Duplikation vermeiden: Informationen sollten entweder in SKILL.md oder in Referenzdateien leben, nicht in beiden. Bevorzugen Sie Referenzdateien für detaillierte Informationen, es sei denn, sie sind wirklich zentral für den Skill – dies hält SKILL.md schlank, während Informationen auffindbar bleiben, ohne das Kontextfenster zu belasten. Behalten Sie nur wesentliche prozedurale Anweisungen und Workflow-Anleitungen in SKILL.md; verschieben Sie detailliertes Referenzmaterial, Schemata und Beispiele in Referenzdateien.
Assets (assets/)

Dateien, die nicht in den Kontext geladen, sondern in der von Codex produzierten Ausgabe verwendet werden sollen.

  • Wann einbinden: Wenn der Skill Dateien benötigt, die in der endgültigen Ausgabe verwendet werden
  • Beispiele: assets/logo.png für Marken-Assets, assets/slides.pptx für PowerPoint-Vorlagen, assets/frontend-template/ für HTML/React-Boilerplate, assets/font.ttf für Typografie
  • Anwendungsfälle: Vorlagen, Bilder, Icons, Boilerplate-Code, Schriftarten, Beispieldokumente, die kopiert oder geändert werden
  • Vorteile: Trennt Ausgaberessourcen von der Dokumentation, ermöglicht Codex die Verwendung von Dateien, ohne sie in den Kontext zu laden

Was nicht in einen Skill aufgenommen werden sollte

Ein Skill sollte nur essentielle Dateien enthalten, die seine Funktionalität direkt unterstützen. Erstellen Sie KEINE überflüssigen Dokumentationen oder Hilfsdateien, einschließlich:

  • README.md
  • INSTALLATION_GUIDE.md
  • QUICK_REFERENCE.md
  • CHANGELOG.md
  • usw.

Der Skill sollte nur die Informationen enthalten, die ein KI-Agent benötigt, um die anstehende Aufgabe zu erledigen. Er sollte keinen zusätzlichen Kontext über den Erstellungsprozess, Einrichtungs- und Testverfahren oder benutzerorientierte Dokumentation enthalten. Das Erstellen zusätzlicher Dokumentationsdateien erzeugt nur Unordnung und Verwirrung.

Progressives Offenlegungsdesign-Prinzip

Skills verwenden ein dreistufiges Ladesystem zur effizienten Kontextverwaltung:

  1. Metadaten (Name + Beschreibung) – Immer im Kontext (~100 Wörter)
  2. SKILL.md-Textkörper – Wenn der Skill auslöst (<5k Wörter)
  3. Gebündelte Ressourcen – Nach Bedarf von Codex (unbegrenzt, da Skripte ausgeführt werden können, ohne in das Kontextfenster gelesen zu werden)

Muster für progressive Offenlegung

Halten Sie den SKILL.md-Textkörper auf das Wesentliche beschränkt und unter 500 Zeilen, um Kontextaufblähung zu minimieren. Teilen Sie Inhalte in separate Dateien auf, wenn Sie sich dieser Grenze nähern. Wenn Sie Inhalte in andere Dateien auslagern, ist es sehr wichtig, von SKILL.md darauf zu verweisen und klar zu beschreiben, wann sie gelesen werden sollen, um sicherzustellen, dass der Leser des Skills weiß, dass sie existieren und wann sie verwendet werden.

Schlüsselprinzip: Wenn ein Skill mehrere Variationen, Frameworks oder Optionen unterstützt, behalten Sie nur den Kernworkflow und die Auswahlanleitung in SKILL.md. Verschieben Sie variantspezifische Details (Muster, Beispiele, Konfiguration) in separate Referenzdateien.

Muster 1: Hochrangige Anleitung mit Referenzen

# PDF-Verarbeitung

## Schnellstart

Text mit pdfplumber extrahieren:
[Codebeispiel]

## Erweiterte Funktionen

- **Formularausfüllen**: Siehe [FORMS.md](FORMS.md) für die vollständige Anleitung
- **API-Referenz**: Siehe [REFERENCE.md](REFERENCE.md) für alle Methoden
- **Beispiele**: Siehe [EXAMPLES.md](EXAMPLES.md) für häufige Muster

Codex lädt FORMS.md, REFERENCE.md oder EXAMPLES.md nur bei Bedarf.

Muster 2: Domänenspezifische Organisation

Bei Skills mit mehreren Domänen organisieren Sie den Inhalt nach Domäne, um das Laden irrelevanten Kontexts zu vermeiden:

bigquery-skill/
├── SKILL.md (Übersicht und Navigation)
└── reference/
    ├── finance.md (Umsatz, Abrechnungsmetriken)
    ├── sales.md (Chancen, Pipeline)
    ├── product.md (API-Nutzung, Funktionen)
    └── marketing.md (Kampagnen, Attribution)

Wenn ein Benutzer nach Verkaufsmetriken fragt, liest Codex nur sales.md.

Ebenso für Skills, die mehrere Frameworks oder Varianten unterstützen, organisieren Sie nach Variante:

cloud-deploy/
├── SKILL.md (Workflow + Anbieterauswahl)
└── references/
    ├── aws.md (AWS-Bereitstellungsmuster)
    ├── gcp.md (GCP-Bereitstellungsmuster)
    └── azure.md (Azure-Bereitstellungsmuster)

Wenn der Benutzer AWS wählt, liest Codex nur aws.md.

Muster 3: Bedingte Details

Zeigen Sie grundlegende Inhalte, verlinken Sie zu erweiterten Inhalten:

# DOCX-Verarbeitung

## Dokumente erstellen

Verwenden Sie docx-js für neue Dokumente. Siehe [DOCX-JS.md](DOCX-JS.md).

## Dokumente bearbeiten

Für einfache Bearbeitungen ändern Sie das XML direkt.

**Für Nachverfolgung von Änderungen**: Siehe [REDLINING.md](REDLINING.md)
**Für OOXML-Details**: Siehe [OOXML.md](OOXML.md)

Codex liest REDLINING.md oder OOXML.md nur, wenn der Benutzer diese Funktionen benötigt.

Wichtige Richtlinien:

  • Vermeiden Sie tief verschachtelte Referenzen – Halten Sie Referenzen eine Ebene tief von SKILL.md entfernt. Alle Referenzdateien sollten direkt von SKILL.md aus verlinken.
  • Strukturieren Sie längere Referenzdateien – Fügen Sie bei Dateien mit mehr als 100 Zeilen oben ein Inhaltsverzeichnis ein, damit Codex den Gesamtumfang beim Vorschaulesen sehen kann.

Skill-Erstellungsprozess

Die Erstellung eines Skills umfasst diese Schritte:

  1. Den Skill anhand konkreter Beispiele verstehen
  2. Wiederverwendbare Skill-Inhalte planen (Skripte, Referenzen, Assets)
  3. Den Skill initialisieren (init_skill.py ausführen)
  4. Den Skill bearbeiten (Ressourcen implementieren und SKILL.md schreiben)
  5. Den Skill validieren (quick_validate.py ausführen)
  6. Basierend auf tatsächlicher Nutzung iterieren und komplexe Skills vorwärts testen.

Befolgen Sie diese Schritte der Reihe nach; überspringen Sie einen Schritt nur, wenn es einen klaren Grund gibt, dass er nicht anwendbar ist.

Skill-Benennung

  • Verwenden Sie nur Kleinbuchstaben, Ziffern und Bindestriche; normalisieren Sie vom Benutzer bereitgestellte Titel zu Bindestrich-Schreibweise (z.B. "Plan Mode" -> plan-mode).
  • Generieren Sie bei der Namensgebung einen Namen unter 64 Zeichen (Buchstaben, Ziffern, Bindestriche).
  • Bevorzugen Sie kurze, verbgeführte Phrasen, die die Aktion beschreiben.
  • Namespace nach Tool, wenn es die Klarheit oder das Auslösen verbessert (z.B. gh-address-comments, linear-address-issue).
  • Benennen Sie den Skill-Ordner genau nach dem Skill-Namen.

Schritt 1: Den Skill mit konkreten Beispielen verstehen

Überspringen Sie diesen Schritt nur, wenn die Nutzungsmuster des Skills bereits klar verstanden sind. Er bleibt auch bei der Arbeit mit einem bestehenden Skill wertvoll.

Um einen effektiven Skill zu erstellen, verstehen Sie klar konkrete Beispiele, wie der Skill verwendet wird. Dieses Verständnis kann entweder aus direkten Benutzerbeispielen oder generierten Beispielen stammen, die durch Benutzerfeedback validiert werden.

Beim Erstellen eines Bildeditor-Skills umfassen relevante Fragen beispielsweise:

  • "Welche Funktionalität sollte der Bildeditor-Skill unterstützen? Bearbeiten, Drehen, etwas anderes?"
  • "Können Sie einige Beispiele nennen, wie dieser Skill verwendet würde?"
  • "Ich kann mir vorstellen, dass Benutzer nach Dingen wie 'Entferne die roten Augen aus diesem Bild' oder 'Drehe dieses Bild' fragen. Gibt es andere Arten, wie Sie sich die Verwendung dieses Skills vorstellen?"
  • "Was müsste ein Benutzer sagen, damit dieser Skill ausgelöst wird?"
  • "Wo soll ich diesen Skill erstellen? Wenn Sie keine Präferenz haben, werde ich ihn in $CODEX_HOME/skills (oder ~/.codex/skills, wenn CODEX_HOME nicht gesetzt ist) platzieren, damit Codex ihn automatisch erkennen kann."

Um Benutzer nicht zu überfordern, vermeiden Sie es, zu viele Fragen in einer einzigen Nachricht zu stellen. Beginnen Sie mit den wichtigsten Fragen und fragen Sie bei Bedarf nach, um eine bessere Effektivität zu erzielen.

Schließen Sie diesen Schritt ab, wenn Sie eine klare Vorstellung von der Funktionalität haben, die der Skill unterstützen soll.

Schritt 2: Planen der wiederverwendbaren Skill-Inhalte

Um konkrete Beispiele in einen effektiven Skill umzuwandeln, analysieren Sie jedes Beispiel, indem Sie:

  1. Überlegen, wie das Beispiel von Grund auf ausgeführt wird
  2. Identifizieren, welche Skripte, Referenzen und Assets hilfreich wären, wenn diese Workflows wiederholt ausgeführt werden

Beispiel: Beim Erstellen eines pdf-editor-Skills für Anfragen wie "Hilf mir, dieses PDF zu drehen", zeigt die Analyse:

  1. Das Drehen eines PDFs erfordert jedes Mal das Neuschreiben desselben Codes
  2. Ein scripts/rotate_pdf.py-Skript wäre hilfreich, um es im Skill zu speichern

Beispiel: Beim Entwerfen eines frontend-webapp-builder-Skills für Anfragen wie "Erstelle mir eine Todo-App" oder "Erstelle mir ein Dashboard zur Schrittverfolgung", zeigt die Analyse:

  1. Das Schreiben einer Frontend-WebApp erfordert jedes Mal dasselbe HTML/React-Boilerplate
  2. Eine assets/hello-world/-Vorlage mit den Boilerplate-HTML/React-Projektdateien wäre hilfreich, um es im Skill zu speichern

Beispiel: Beim Erstellen eines big-query-Skills für Anfragen wie "Wie viele Benutzer haben sich diese Woche angemeldet?" oder "Zeige mir die monatlich wiederkehrenden Einnahmen nach Region", zeigt die Analyse:

  1. Das Abfragen derselben BigQuery-Tabellen erfordert jedes Mal das Finden der richtigen Tabellennamen und Schemata
  2. Eine references/finance.md-Datei mit Tabellenschemata und typischen Abfragemustern wäre hilfreich, um sie in Referenzen zu speichern

Beispiel: Beim Erstellen eines slide-deck-builder-Skills für Anfragen wie "Erstelle eine Produkteinführungspräsentation für das neue SaaS-Produkt", zeigt die Analyse:

  1. Das Erstellen einer Präsentation von Grund auf erfordert jedes Mal das erneute Erstellen derselben Folienmaster und Formatierung
  2. Eine assets/presentation-template/-Vorlage mit Folienmaster und Formatierung wäre hilfreich, um sie in Assets zu speichern

Am Ende von Schritt 2 sollten Sie eine klare Liste der benötigten Skripte, Referenzen und Assets haben.

Schritt 3: Skill initialisieren (init_skill.py ausführen)

Initialisieren Sie den Skill, indem Sie scripts/init_skill.py ausführen mit:

python scripts/init_skill.py <skill-name> [--path <parent-directory>]

Standardmäßig wird der Skill in $CODEX_HOME/skills (oder ~/.codex/skills, wenn CODEX_HOME nicht gesetzt ist) erstellt.

Dies erstellt die Ordnerstruktur und die erforderliche SKILL.md-Datei mit Frontmatter-Metadaten.

Verwendung von --interface zur Generierung von Agenten-Metadaten:

Wenn der Skill Agenten-Konfiguration benötigt, übergeben Sie --interface-Argumente:

python scripts/init_skill.py pdf-editor \
  --interface display_name="PDF-Editor" \
  --interface short_description="Rotiert, extrahiert und bearbeitet PDF-Dokumente" \
  --interface default_prompt="Hilf mir, dieses PDF zu bearbeiten"

Siehe references/openai_yaml.md für alle verfügbaren Felder.

Verwendung von --with-resources zum Erstellen von Ressourcenordnern:

Fügen Sie --with-resources hinzu, um scripts/, references/ und assets/-Ordner zu erstellen:

python scripts/init_skill.py pdf-editor --with-resources

Initialisierung für bestehende Skills:

Wenn Sie einen bestehenden Skill in einer anderen Umgebung initialisieren müssen:

  1. Klonen Sie den Skill aus seinem Quell-Repository
  2. Führen Sie scripts/init_skill.py mit dem Namen des bestehenden Skills aus, um Metadaten und Konfiguration zu generieren

Überspringen Sie diesen Schritt, wenn:

  • Sie den Skill bereits initialisiert haben, aber nur die Ressourcen optimieren
  • Der Skill nur SKILL.md benötigt (keine gebündelten Ressourcen) und die SKILL.md bereits existiert

Schritt 4: Bearbeiten des Skills

Schreiben Sie die SKILL.md und implementieren Sie die geplanten Ressourcen. Befolgen Sie diese Richtlinien:

SKILL.md-Richtlinien

  • Prägnant schreiben: Jeder Satz sollte verdient sein. Codex benötigt keine langen Erklärungen zu Konzepten, die es bereits versteht.
  • Anweisungen statt Erklärungen: Konzentrieren Sie sich darauf, WAS zu tun ist, nicht nur zu erklären, WARUM.
  • Explizite Beispiele einfügen: Fügen Sie konkrete Code- oder Workflow-Beispiele ein, die befolgt werden können.
  • Grenzen setzen: Beschreiben Sie, wann der Skill verwendet werden sollte und wann nicht.
  • Suchmuster einfügen: Wenn Referenzdateien groß sind, fügen Sie grep-Muster hinzu, damit Codex schnell relevante Informationen finden kann.

Beispiel-SKILL.md-Struktur

---
Name: pdf-editor
Description: Bietet PDF-Bearbeitungsfunktionen einschließlich Drehen, Extrahieren von Text und Zusammenführen von Dokumenten.
---

# PDF-Editor-Skill

## Verwendung

Dieser Skill wird verwendet, wenn ein Benutzer PDF-Dokumente bearbeiten muss. Er sollte ausgelöst werden, wenn Anfragen PDF-Bearbeitung betreffen.

## Workflows

### PDF drehen

Verwenden Sie `scripts/rotate_pdf.py` zum Drehen von PDF-Seiten:

```bash
python scripts/rotate_pdf.py input.pdf output.pdf --angle 90

Text extrahieren

Verwenden Sie pdfplumber, um Text aus PDFs zu extrahieren.

PDFs zusammenführen

Verwenden Sie scripts/merge_pdfs.py, um mehrere PDFs zu kombinieren.

Referenzen

  • API-Referenz: Siehe REFERENCE.md für detaillierte Methoden und Parameter
  • Beispiele: Siehe EXAMPLES.md für häufige Anwendungsfälle

Wann NICHT zu verwenden

  • Verwenden Sie diesen Skill nicht für die Erstellung neuer PDFs von Grund auf; verwenden Sie stattdessen den reportlab- oder fpdf-Skill.

#### Ressourcen implementieren

Erstellen Sie die geplanten Skripte, Referenzen und Assets.

**Skript-Anforderungen:**

- Fügen Sie einen Shebang (z.B. `#!/usr/bin/env python3`) hinzu
- Fügen Sie eine kurze Docstring-Beschreibung hinzu
- Akzeptieren Sie Argumente über sys.argv oder argparse
- Bearbeiten Sie Fehlerfälle
- Dokumentieren Sie Parameter in SKILL.md

**Referenz-Anforderungen:**

- Jede Referenzdatei sollte bei 100 Zeilen ein Inhaltsverzeichnis haben
- Referenzen von SKILL.md aus verlinken
- Enthalten Sie explizite Abschnitte, die zum Abfragen nützlich sind

### Schritt 5: Skill validieren (quick_validate.py ausführen)

Führen Sie die Validierung durch:

```bash
python scripts/quick_validate.py <skill-path>

Dies überprüft:

  1. Strukturgültigkeit: SKILL.md mit Frontmatter vorhanden, Ordnerstruktur korrekt
  2. Metadaten-Gültigkeit: Name und Beschreibung im Frontmatter vorhanden und gültig
  3. Ressourcen-Integrität: Alle referenzierten Dateien existieren
  4. Skript-Validierung: Skripte sind ausführbar und haben keine Syntaxfehler (wenn möglich)

Beheben Sie alle gemeldeten Probleme.

Schritt 6: Iterieren

Testen Sie den Skill mit echten Anfragen. Sammeln Sie Feedback von Benutzern und verfeinern Sie den Skill basierend auf:

  1. Fehlender Funktionalität: Gibt es häufige Anfragen, die der Skill nicht abdeckt?
  2. Ungenauigkeiten: Sind die Anweisungen falsch oder irreführend?
  3. Token-Effizienz: Kann der Skill prägnanter sein?
  4. Auslösegenauigkeit: Wird der Skill ausgelöst, wenn er sollte (und nicht, wenn er nicht sollte)?

Validieren Sie komplexe Skills durch Vorwärtstests, indem Sie einem Sub-Agenten Zugriff auf den Skill geben und in Ihrem Namen damit arbeiten lassen, um potenzielle Fehler oder Probleme zu identifizieren.

Abschluss

Die Erstellung effektiver Skills erfordert das Verständnis, dass Skills prägnant, fokussiert und genau abgestimmt auf die Bedürfnisse des Benutzers sein sollten. Befolgen Sie diese Richtlinien, um Skills zu erstellen, die Codex in einen spezialisierten Assistenten für Ihre spezifischen Aufgaben verwandeln.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

grahama1970/acceptance-contract

Turn a client brief, zip bundle, directory, or single requirements file into a typed acceptance-contract bundle with extracted requirements, acceptance checks, open questions, an immutable-goal draft, and a create-report-backed decision report. Use when users say acceptance contract, brief to requirements, freeze the goal, create immutable goal, amend immutable goal, build a Battle requirements bundle, or extract requirements from this bundle.

grahama1970/agent-ecosystem

Canonical map and shared contracts for the agent-governance ecosystem: the pi.receipt_envelope.v1 boundary envelope, the component graph, and the rules for which component owns which schema. Use when wiring a skill or extension into the shared receipt world, when asking how shame, triage-error, tau, ask, project-watchdog, ops-herdr, ponytail, and Memory fit together, or when validating an envelope.

grahama1970/agentic-evals

Agentic evaluation of skills using multi-trial fixtures, deterministic command assertions, trajectory checks, safety constraints, and evidence-backed readiness scoring. Use when users ask for agentic evals, multi-trial skill evaluation, skill trajectory validation, or readiness scoring for a skill workflow.

grahama1970/agent-inbox

File-based inter-agent messaging with headless dispatch. Check inbox, send bugs/requests to other projects, automatically spawn headless agents to fix bugs, and track progress via task-monitor.

grahama1970/agents-registry

Generate and query the centralized agent identity registry. Scans .pi/agents/*/AGENTS.md, parses frontmatter, outputs agents-registry.json and optionally syncs to /memory for semantic search.

grahama1970/agent-status

Artifact-driven status surfaces for long-running project-agent work. Maintains status.json, events.jsonl, proof manifests, and a stale-aware STATUS.html so humans can tell where the agent is, what passed, what is still unproven, and what decision or action is next — without dashboard theater.

grahama1970/align

Round-based context alignment before execution. Use when the human, project agent, WebGPT, scillm, ask, dogpile, memory, or project-knowledge may each hold different facts about a task; especially before ambiguous design, infographic, product workflow, high-stakes implementation, plan-iterate, project-infographic, or multi-review work.

grahama1970/analytics

Flexible data science analytics for any dataset. Auto-discovers schema, recommends charts, exports to create-figure. Works with JSONL, JSON, CSV from any source.

grahama1970/analyze-chatterbox-emotions

Evaluate generated Chatterbox voice files as voice-quality artifacts: affect match, arousal/valence proxies, pause placement, intelligibility inputs, clipping, loudness, and discontinuity flags. Use when reviewing Chatterbox emotional tags, pauses, Turbo/base affect delivery, Persona Dream utterance renders, or whether generated speech matches an intended product-facing affect.

grahama1970/analyze-elf

Reverse-engineer features from ELF binaries. Extracts CLI commands, state machines, protocols, Zod schemas, and data models. Automatically generates a /create-walkthrough prosecution brief with Mermaid diagrams. Uses /treesitter for AST analysis of bundled JS/TS source.

grahama1970/animation-vocabulary

Reverse-lookup glossary that turns a vague description of a web animation or motion effect into its exact term ("the bouncy thing when a popover opens" → Pop in; "the iOS rubber-band scroll" → Rubber-banding). Use when the user asks "what's it called when…", or describes a motion effect without knowing its name and wants the right word to prompt an AI or designer with. For naming an effect, not designing or building one.

grahama1970/anonymize-data

Anonymize supported CSV, JSON, UTF-8 text, and SQLite files using an explicit policy through the oai-trial project. Use for anonymize data, pseudonymize exports, redact policy literals, or discover and explicitly approve fuzzy name aliases. The skill is a thin CLI/Docker interface, not another engine.

grahama1970/anvil

Heavy-duty "No-Vibes" debugging and hardening orchestrator. Use this for complex, stubborn bugs where `review-code` has failed, or for "Red Teaming" (hardening) a codebase. Runs multiple agents in parallel (Thunderdome) using git worktree isolation.

grahama1970/apple-design

Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.

grahama1970/argue

Multi-persona structured debate orchestrator. Personas research via /dogpile, consult colleagues via /ask, and argue toward nuanced synthesis on complex questions.

grahama1970/arxiv

Search arXiv for papers and extract knowledge into memory. Use `search` to find papers, `learn` to extract knowledge.

grahama1970/ask

Use when the user asks to query project memory, ask an oracle, use supported browser-backed reviewers, run Tau roundtable/single-handler workflows, ask Pi-native subagents from within Pi, run persona/deep-review workflows, generate image prompts, check OS/project health through composed skills, or run an ask DAG. This skill is the executable /ask runtime; do not replace it with an informal subagent, plain web search, or hand-written review; inside Pi, explicit Pi-native subagent targets are routed through the pi-subagents tool as an Ask target type.

grahama1970/assess

Step back and critically reassess project state. Use when asked to "assess", "step back", "fresh eyes", "check alignment", "sanity check", "health check", "prune documentation", or "evaluate what's working". Offers documentation pruning and doc-code alignment analysis. Offer to run after major changes (don't auto-run).

grahama1970/assistant

Shared GPT + classifier inference gateway for persona monitor tasks. Routes validation and classification through a 4-tier cascade: heuristic → classifier → local GPT → scillm.

grahama1970/assistant-lab

Self-improvement workbench for /assistant. All the tools needed to diagnose, train, evaluate, and promote models in a continuous loop. The "warm pond" where /assistant evolves its own inference stack.

Verwandte Skills