Communitygithub.com

grahama1970/plugin-creator

Erstellen und Anlegen von Plugin-Verzeichnissen für Codex mit einer erforderlichen `.codex-plugin/plugin.json`, optionalen Plugin-Ordnern/Dateien, gültigen Standardmanifesten und persönlichen Marktplatzeinträgen standardmäßig. Verwenden, wenn Codex ein neues persönliches Plugin erstellen, eine optionale Plugin-Struktur hinzufügen, Marktplatzeinträge für die Plugin-Reihenfolge und Verfügbarkeitsmetadaten generieren oder aktualisieren oder ein bestehendes lokales Plugin während der Entwicklung mit dem CLI-gesteuerten Cachebuster- und Neuinstallationsablauf aktualisieren muss.

Was ist plugin-creator?

Plugin Creator ist ein Skill für Codex zum Erstellen und Verwalten von Plugins. Er erstellt automatisch Plugin-Verzeichnisse mit der erforderlichen `.codex-plugin/plugin.json`, optionalen Ordnern (Skills, Hooks, Skripts, Assets, MCP-Konfigurationen, Apps) und persönlichen Marktplatzeinträgen. Der Skill normalisiert Plugin-Namen (z. B. "Mein Plugin" → "mein-plugin"), validiert die Manifeste und unterstützt Cachebuster-Updates für laufende Entwicklung. Der Skill ist plattformunabhängig und stellt sicher, dass alle generierten Plugins die Schemaanforderungen von Codex erfüllen. Der Marktplatzablauf unterstützt sowohl persönliche (Standard in `~/.agents/plugins/marketplace.json`) als auch Team/Repo-Marktplätze mit expliziter Installation. Er behandelt Richtlinienfelder wie `installation`, `authentication` und `category` und bietet Deeplinks zum Anzeigen und Teilen des Plugins in der Codex-App.

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

In Ihrer bevorzugten KI fragen

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

Dokumentation

Plugin Creator

Kurzanleitung

  1. Führen Sie das Gerüstskript aus:
# Plugin-Namen werden in Kleinbuchstaben mit Bindestrichen normalisiert und müssen <= 64 Zeichen lang sein.
# Der generierte Ordner- und plugin.json-Name ist immer identisch.
# Vom Skill-Stammverzeichnis aus ausführen (dem Verzeichnis, das diese `SKILL.md` enthält).
# Standardmäßig wird in `~/plugins/<plugin-name>` erstellt.
python3 scripts/create_basic_plugin.py <plugin-name>
  1. Bearbeiten Sie <plugin-pfad>/.codex-plugin/plugin.json, wenn die Anfrage spezifische Metadaten liefert. Das Gerüst beginnt mit gültigen Standardwerten und darf keine [TODO: ...]-Platzhalter enthalten.

  2. Generieren oder aktualisieren Sie den persönlichen Marktplatzeintrag, wenn das Plugin in der Codex-UI-Reihenfolge erscheinen soll:

# Persönliche Marktplatzeinträge werden standardmäßig in `~/.agents/plugins/marketplace.json` abgelegt.
python3 scripts/create_basic_plugin.py mein-plugin --with-marketplace

Geben Sie --marketplace-name <name> nur an, wenn der Standard-Marktplatzname personal bereits belegt oder installiert ist und Sie eine andere neue Marktplatzdatei anlegen müssen:

python3 scripts/create_basic_plugin.py mein-plugin \
  --with-marketplace \
  --marketplace-name team-lokal

Verwenden Sie einen Repo/Team-Marktplatz nur, wenn der Benutzer ausdrücklich nach diesem Ziel fragt:

python3 scripts/create_basic_plugin.py mein-plugin \
  --path <repo-root>/plugins \
  --marketplace-path <repo-root>/.agents/plugins/marketplace.json \
  --with-marketplace

Wenn der Benutzer einen Marktplatzpfad angibt, stellen Sie sicher, dass dieser Marktplatz tatsächlich installiert ist, bevor Sie dem Benutzer sagen, er solle von dort neu installieren. Die Standard-Marktplatzdatei unter ~/.agents/plugins/marketplace.json wird implizit erkannt, andere Marktplatzpfade jedoch nicht. Unter Windows verwenden Sie den entsprechenden Pfad im Benutzerprofil.

  1. Generieren/Anpassen optionaler Begleiterordner nach Bedarf:
python3 scripts/create_basic_plugin.py mein-plugin \
  --path <übergeordnetes-plugin-verzeichnis> \
  --marketplace-path <marktplatz-json-pfad> \
  --with-skills --with-hooks --with-scripts --with-assets --with-mcp --with-apps --with-marketplace

<übergeordnetes-plugin-verzeichnis> ist das Verzeichnis, in dem der Plugin-Ordner <plugin-name> erstellt wird (z. B. ~/plugins).

  1. Führen Sie vor der Rückgabe eines generierten Plugins Folgendes aus:
python3 scripts/validate_plugin.py <plugin-pfad>

Für Aktualisierungen eines bestehenden lokalen Plugins während der Entwicklung behalten Sie den Gerüstablauf bei und verwenden Sie die Referenz anstatt Marktplatzdateien von Hand zu bearbeiten:

python3 scripts/update_plugin_cachebuster.py <plugin-pfad>

Bevorzugen Sie den standardmäßigen Cachebuster des Hilfsprogramms, es sei denn, der Benutzer fragt ausdrücklich nach einer bestimmten Überschreibung. Siehe references/installing-and-updating.md für den erwarteten Cachebuster- und Neuinstallationsablauf beim Iterieren über ein bestehendes lokales Plugin.

Was dieser Skill erstellt

  • Standardmäßige marktplatzgestützte Gerüste verwenden die persönliche Marktplatzdatei unter ~/.agents/plugins/marketplace.json, wobei Plugins normalerweise in ~/plugins/<plugin-name>/ gespeichert werden.
  • Erstellt Plugin-Stammverzeichnis unter /<übergeordnetes-plugin-verzeichnis>/<plugin-name>/.
  • Erstellt immer /<übergeordnetes-plugin-verzeichnis>/<plugin-name>/.codex-plugin/plugin.json.
  • Befüllt das Manifest mit der validierten Schemaform, die der Aufnahmepfad akzeptiert.
  • Erstellt oder aktualisiert ~/.agents/plugins/marketplace.json, wenn --with-marketplace gesetzt ist.
    • Wenn die Marktplatzdatei noch nicht existiert, initialisieren Sie ein persönliches Marktplatzstammverzeichnis, bevor Sie den ersten Plugin-Eintrag hinzufügen.
  • <plugin-name> wird mit den Namenskonventionen von skill-creator normalisiert:
    • Mein Plugin → mein-plugin
    • Mein--Plugin → mein-plugin
    • Unterstriche, Leerzeichen und Satzzeichen werden in - umgewandelt
    • Ergebnis ist in Kleinbuchstaben, durch Bindestriche getrennt, mit zusammengezogenen aufeinanderfolgenden Bindestrichen
  • Unterstützt optionale Erstellung von:
    • skills/
    • hooks/
    • scripts/
    • assets/
    • .mcp.json
    • .app.json

Marktplatzablauf

  • Die Erstellung persönlicher Marktplätze erfolgt standardmäßig unter ~/.agents/plugins/marketplace.json. Hier bedeutet "persönlicher Marktplatz" den Marktplatz, dessen Datei sich an diesem Pfad befindet.
  • Die Erstellung von Repo/Team-Marktplätzen erfolgt nur über beide --path und --marketplace-path opt-in, wenn der Benutzer dies ausdrücklich wünscht.
  • --marketplace-name ist ein Ausnahmepfad. Verwenden Sie es nur, wenn der Standard-Marktplatzname personal bereits belegt ist und Sie eine andere neue Marktplatzdatei initialisieren müssen.
  • Verwenden Sie --marketplace-name nicht, um eine bestehende Marktplatzdatei umzubenennen. Wenn die Datei bereits existiert, muss ihr oberster name bereits übereinstimmen.
  • Wenn der Benutzer einen anderen Marktplatzpfad angibt, behandeln Sie diesen Marktplatz so, dass er eine explizite Installation via codex plugin marketplace add benötigt.
  • Bevorzugen Sie scripts/read_marketplace_name.py, wenn Sie den Marktplatznamen aus einer beliebigen marketplace.json-Datei benötigen. Ohne Argument liest es den Standard-Personalmarktplatz; mit einem expliziten Pfad funktioniert es auch für Repo/Team-Marktplätze.
  • In beiden Pfaden bleibt der generierte Quellpfad ./plugins/<plugin-name>.
  • Die Metadaten des Marktplatzstammverzeichnisses unterstützen den obersten name plus optional interface.displayName.
  • Behandeln Sie die Plugin-Reihenfolge in plugins[] als Render-Reihenfolge in Codex. Fügen Sie neue Einträge an, es sei denn, ein Benutzer bittet ausdrücklich um eine Neuordnung der Liste.
  • displayName gehört innerhalb des Marktplatz-interface-Objekts, nicht in einzelne plugins[]-Einträge.
  • Jeder generierte Marktplatzeintrag muss alle der folgenden Felder enthalten:
    • policy.installation
    • policy.authentication
    • category
  • Standardmäßige neue Einträge:
    • policy.installation: "AVAILABLE"
    • policy.authentication: "ON_INSTALL"
  • Überschreiben Sie die Standardwerte nur, wenn der Benutzer ausdrücklich einen anderen zulässigen Wert angibt.
  • Zulässige Werte für policy.installation:
    • NOT_AVAILABLE
    • AVAILABLE
    • INSTALLED_BY_DEFAULT
  • Zulässige Werte für policy.authentication:
    • ON_INSTALL
    • ON_USE
  • Behandeln Sie policy.products als eine Überschreibung. Lassen Sie es weg, es sei denn, der Benutzer fordert ausdrücklich eine Produktsteuerung an.
  • Die Form des generierten Plugin-Eintrags ist:
{
  "name": "plugin-name",
  "source": {
    "source": "local",
    "path": "./plugins/plugin-name"
  },
  "policy": {
    "installation": "AVAILABLE",
    "authentication": "ON_INSTALL"
  },
  "category": "Productivity"
}
  • Verwenden Sie --force nur, wenn Sie absichtlich einen vorhandenen Marktplatzeintrag für denselben Plugin-Namen ersetzen.

  • Wenn die Zielmarktplatzdatei noch nicht existiert, erstellen Sie sie mit einem obersten "name", einem "interface"-Objekt, das "displayName" enthält, und einem plugins-Array, und fügen Sie dann den neuen Eintrag hinzu.

  • Für eine brandneue Marktplatzdatei sollte das Stammobjekt wie folgt aussehen:

{
  "name": "personal",
  "interface": {
    "displayName": "Persönlich"
  },
  "plugins": [
    {
      "name": "plugin-name",
      "source": {
        "source": "local",
        "path": "./plugins/plugin-name"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}

Erforderliches Verhalten

  • Der äußere Ordnernamen und der "name" in plugin.json sind immer der gleiche normalisierte Plugin-Name.
  • Entfernen Sie nicht die erforderliche Struktur; behalten Sie .codex-plugin/plugin.json bei.
  • Hinterlassen Sie keine [TODO: ...]-Platzhalter in Plugin-Manifesten.
  • Lassen Sie apps und mcpServers aus plugin.json heraus, es sei denn, ihre Begleitdateien werden tatsächlich erstellt.
  • Lassen Sie nicht unterstützte Plugin-Manifestfelder weg, die die Validierung ablehnt, einschließlich hooks.
  • Wenn Sie Dateien innerhalb eines bestehenden Plugin-Pfads erstellen, verwenden Sie --force nur, wenn das Überschreiben beabsichtigt ist.
  • Bewahren Sie jegliches vorhandenes interface.displayName des Marktplatzes.
  • Schreiben Sie beim Generieren von Marktplatzeinträgen immer policy.installation, policy.authentication und category, auch wenn ihre Werte Standardwerte sind.
  • Fügen Sie policy.products nur hinzu, wenn der Benutzer ausdrücklich nach dieser Überschreibung fragt.
  • Halten Sie den source.path des Marktplatzes relativ zum ausgewählten Marktplatzstammverzeichnis als ./plugins/<plugin-name>.
  • Verwenden Sie --marketplace-name nur, wenn Sie eine neue Marktplatzdatei erstellen, deren Name nicht personal sein soll, weil dieser Name bereits belegt oder anderweitig installiert ist.
  • Wenn Codex eine Genehmigung zum Schreiben der Marktplatzdatei benötigt, holen Sie diese Genehmigung ein, bevor Sie fortfahren. Wenn der Benutzer es vorzieht, das Schreiben selbst auszuführen, geben Sie den genauen Gerüstbefehl an und fahren Sie dann mit der Validierung oder nachfolgenden Plugin-Bearbeitungen fort, anstatt den Arbeitsablauf vage zu halten.
  • Bearbeiten Sie für Aktualisierungen eines bestehenden lokalen Plugins während der Entwicklung nicht von Hand die Marktplatzkonfiguration oder marketplace.json. Verwenden Sie den in references/installing-and-updating.md und scripts/update_plugin_cachebuster.py dokumentierten Aktualisierungsablauf.
  • Weisen Sie den Benutzer nicht an, codex plugin marketplace add für den standardmäßigen persönlichen Marktplatzablauf auszuführen. Dieser Befehl ist für explizite, nicht standardmäßige Marktplatzkonfigurationen gedacht, nicht für den standardmäßigen Pfad ~/.agents/plugins/marketplace.json.
  • Wenn der Benutzer einen nicht standardmäßigen --marketplace-path angegeben hat, stellen Sie sicher, dass dieser Marktplatz installiert ist, bevor Sie Neuinstallationsanweisungen geben. Verwenden Sie codex plugin marketplace add <pfad-zum-marktplatz-stammverzeichnis>, wenn dieser explizite Marktplatz noch nicht konfiguriert wurde.
  • Wenn der Arbeitsablauf ein marktplatzgestütztes Plugin erstellt oder aktualisiert hat, beenden Sie die abschließende benutzerseitige Antwort mit einer kurzen Codex-App-Übergabe. Sagen Sie Um dies in der Codex-App anzuzeigen: und schreiben Sie View <normalisierter Plugin-Name> und Share <normalisierter Plugin-Name> als Markdown-Links, nicht als rohe URLs oder Code-Spans.
  • Der View-Deeplink verwendet codex://plugins/<normalisierter Plugin-Name>?marketplacePath=<absoluter marketplace.json-pfad>. Der Share-Deeplink verwendet dieselbe URL mit &mode=share.
  • Ersetzen Sie die Platzhalter durch den tatsächlichen normalisierten Plugin-Namen und den absoluten marketplace.json-Pfad aus dem Gerüst des Plugins. URL-kodieren Sie das Pfadsegment und den Abfragewert bei Bedarf.
  • Fügen Sie diesen Deeplinks keine Abfrageparameter pluginName oder hostId hinzu. Codex leitet beide ab, nachdem der Benutzer auf den Link geklickt hat.
  • Geben Sie die Links View <normalisierter Plugin-Name> oder Share <normalisierter Plugin-Name> nicht aus, wenn kein Marktplatzeintrag erstellt oder aktualisiert wurde.

Referenz zum genauen Spezifikationsbeispiel

Für das genaue kanonische Beispiel-JSON sowohl für Plugin-Manifeste als auch für Marktplatzeinträge verwenden Sie:

  • references/plugin-json-spec.md
  • references/installing-and-updating.md für Hinweise zur Aktualisierung/Neuinstallation beim Iterieren über ein bestehendes lokales Plugin, plus das Aufnahmeverhalten für neue Threads nach der Neuinstallation

Validierung

Nach der Bearbeitung von SKILL.md führen Sie Folgendes aus:

python3 ../skill-creator/scripts/quick_validate.py .

Vor der Rückgabe eines generierten Plugins führen Sie Folgendes aus:

python3 scripts/validate_plugin.py <plugin-pfad>

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