Codex Skills und Plugins: Team-Workflows wiederverwendbar machen

Dieselbe Code-Review-Checkliste wird in fünf Repositories kopiert. Bei jedem Pull Request folgen dieselben manuellen Hinweise: „zuerst die fehlgeschlagenen Tests ausführen“, „Berechtigungsgrenzen prüfen“, „Changelog nicht vergessen“. Das Problem ist nicht, dass der Prompt zu kurz ist. Der Ablauf ist noch nicht als wiederverwendbare Fähigkeit modelliert.

Codex Skills und Plugins lösen genau dieses Problem: Wiederholte Teamabläufe werden aus Ad-hoc-Prompts und einer immer längeren AGENTS.md herausgelöst und als wiederverwendbare Bausteine abgelegt. Ein Skill ist das Autorenformat für einen wiederverwendbaren Workflow. Ein Plugin ist eine installierbare Verteilungseinheit. Beides ersetzt Projektregeln nicht, sondern ergänzt sie: Dauerhafte Regeln bleiben in AGENTS.md; mehrstufige Abläufe, Beispiele, Skripte und lange Referenzen wandern in Skills; für Teamverteilung wird daraus ein Plugin.

Eine einfache Entscheidungstabelle reicht aus, um zwischen Skill, Plugin, MCP, AGENTS.md und Subagent zu wählen. Danach können Sie mit einem minimalen Skill-Verzeichnis beginnen und bis zur Zerlegung eines role-specific plugin, zur Teamverteilung und zur Prüfung der Berechtigungsgrenzen weitergehen.

1. Kopierte Teamabläufe: Der Prompt ist nicht das Problem

Code-Review, Release-Checks, Testabläufe und Dokumentationsupdates haben in Teams oft ein festes Format. Vielleicht fügen Sie bei jedem PR-Review einen Prompt in Codex ein: „Prüfe, ob das Changelog fehlt, ob die Testabdeckung gesunken ist und ob API docs aktualisiert werden müssen.“ Die Probleme zeigen sich schnell:

• Pflege liegt an zu vielen Orten: Wenn sich die Checkliste ändert, müssen fünf .github/PULL_REQUEST_TEMPLATE.md Dateien oder getrennte Prompt-Dateien angepasst werden.
• Die Ausführung schwankt: Codex muss den Ablauf jedes Mal neu verstehen und vergisst leicht wichtige Schritte wie „fehlgeschlagene Tests zuerst ausführen“.
• Rollenstandards vermischen sich: Frontend, QA, Security und Dokumentation landen in einem Prompt, sodass Codex schwerer erkennt, welcher Maßstab gerade gilt.

Manche Teams schreiben all das in AGENTS.md. Das führt zum nächsten Problem: Die Projektregeldatei wird immer länger. Dauerhafte Build-Kommandos, Verzeichnisregeln und temporäre Prozessanweisungen vermischen sich. Damit wächst die Datei über ihre Rolle als dauerhafte Projektvorgabe hinaus.

Codex erlaubt eine klarere Schichtung: AGENTS.md für dauerhafte Regeln, Skills für wiederverwendbare Abläufe, Plugins für Verteilung. Entscheidend ist, was in welche Schicht gehört.

2. Skill, Plugin, MCP und AGENTS.md in einer Entscheidungstabelle

Ein Skill ist ein Autorenformat für wiederverwendbare Workflows, meist ein SKILL.md mit optionalen Skripten, Referenzen und Assets. Ein Plugin ist eine installierbare Verteilungseinheit in Codex, die Skills, App-Integrationen, MCP Server und Assets bündeln kann. MCP ist das Protokoll, um externe Tools und Kontext anzubinden, etwa Drittanbieter-Dokumentation, Browser, Figma oder GitHub. AGENTS.md ist für dauerhafte Projektvorgaben gedacht: Build-Kommandos, Verzeichnisregeln und Review-Erwartungen. Ein Subagent delegiert laute oder spezialisierte Aufgaben.

Wann welche Option passt

Inhaltstyp	Passende Option	Typischer Einsatz	Nicht geeignet für
Build-Kommandos, Testskript-Pfade, Verzeichnisregeln	AGENTS.md	„Alle neuen Komponenten liegen in src/components/“, „Tests laufen mit npm run test:unit“	Mehrstufige Abläufe, Beispiele, externe Tool-Aufrufe
Mehrstufige Workflows mit Beispielen, Skripten oder Referenzen	Skill	10-Schritt-Code-Review, 7-Punkte-Release-Check, API-docs-Generator	Eine einzelne Regel oder ein einzelnes Kommando
Teamverteilung und Paketierung von App/MCP-Konfiguration	Plugin	Frontend-Rollen-Plugin mit 4 Review-Skills und Figma connector	Abläufe, die nur in einem Repository iteriert werden und nicht geteilt werden müssen
Externe Tool-Aufrufe und Drittanbieter-Kontext	MCP	Figma-Spezifikationen abrufen, GitHub issues per API lesen	Reine Workflow-Definition ohne externe Daten
Delegation lauter oder spezialisierter Aufgaben	Subagent	Testdiagnose oder Loganalyse an einen spezialisierten Agent geben	Einfache Abläufe, die direkt im Hauptdialog erledigt werden können

Wann etwas aus AGENTS.md in ein Skill gehört

Diese Signale zeigen, dass der Ablauf nicht mehr gut in die Projektregeldatei passt und als Skill besser aufgehoben ist:

• Dieselbe Checkliste taucht in mehreren PRs auf und wird jedes Mal manuell eingefügt.
• Der Ablauf hat mehrere Schritte und braucht Beispiele, Skripte oder externe Referenzen.
• Der Ablauf hat einen klaren Trigger wie „vor dem Release“ oder „beim Pull Request Review“, statt eine dauerhafte Vorgabe zu sein.
• Unterschiedliche Rollen haben unterschiedliche Standards und sollten nicht alle in einer Datei stehen.
• Der Ablauf braucht Versionierung und Änderungsnotizen, statt jedes Mal direkt in Projektregeln geändert zu werden.

Wann ein Skill zum Plugin werden sollte

Ein Skill reicht aus, solange es in einem Repository oder persönlichen Workflow iteriert wird. Verpacken Sie es als Plugin, wenn Folgendes nötig wird:

• Teilen über Teams hinweg statt nur in einem persönlichen Verzeichnis oder einem einzelnen Repository.
• Bündelung von App-Integrationen wie Figma, GitHub oder CI/CD-Tools, oder MCP server configuration.
• Versionierung, Changelog und Upgrade-Mechanik statt kopierter Skill-Ordner.
• Verteilung über die Codex App Plugin Directory an workspace members.
• Ein stabiles Paket statt eines experimentellen Workflows, der sich täglich ändert.

Eine praktikable Reihenfolge lautet: Repository-Konventionen in AGENTS.md festhalten; ein passendes vorhandenes Plugin installieren; sonst ein Skill erstellen; bei Teamverteilung zum Plugin machen; MCP erst hinzufügen, wenn ein externes System nötig ist; Subagent nutzen, wenn die Aufgabe laut oder spezialisiert genug ist.

3. Ein minimales Skill in der Praxis: Start mit Code-Review

Minimaler Skill-Dateibaum

Ein Skill braucht mindestens diese Struktur:

.agents/skills/code-review/
├── SKILL.md
├── references/
│   └── security-checklist.md
└── scripts/
    └── run-failed-tests.sh

Der Verzeichnisname und das name Feld im Frontmatter von SKILL.md müssen übereinstimmen. Erlaubt sind lowercase alphanumeric und hyphen.

SKILL.md Beispiel: Code-Review-Skill

---
name: code-review
description: Use for pull request reviews in frontend projects. Checks changelog, test coverage, security boundary, and API docs. Do not use for backend-only changes or infrastructure PRs.
---

# Code Review Checklist

## Before Starting
1. Run failed tests first: `npm run test:failed`
2. Check if PR has clear description and scope

## Review Steps
1. Changelog: Does `CHANGELOG.md` need update?
2. Test Coverage: Did coverage decrease? Check report in `coverage/`
3. Security: Review changes in `src/auth/`, `src/api/`, and `src/middleware/`
4. API Docs: If API changed, update `docs/api.md`

## Security Boundary Checks
See `references/security-checklist.md` for detailed items.

## Failed Test Runner
Use `scripts/run-failed-tests.sh` to rerun previously failed tests.

Trigger-Design in description: before/after

Codex nutzt die description, um zu entscheiden, ob ein Skill implizit aufgerufen werden soll. Ist sie zu vage, wird das Skill zu oft oder gar nicht ausgelöst:

Before, leicht fehltriggernd	After, zuverlässiger
”Code review skill for frontend projects"	"Use for pull request reviews in frontend projects. Checks changelog, test coverage, security boundary, and API docs."
"Help review code"	"Use when reviewing PRs with frontend changes. Do not use for backend-only changes or infrastructure PRs."
"Review checklist"	"Trigger on: PR reviews, code audit requests. Exclude: backend changes, config-only updates.”

Schreiben Sie klare „Use when…“ und „Do not use when…“ Grenzen. Trigger-Begriffe wie pull request, review und frontend gehören nach vorn. Längere Skill-Beschreibungen können gekürzt werden, daher müssen die wichtigsten Signale früh stehen. Wenn ein Skill nur explizit aufgerufen werden soll, setzen Sie allow_implicit_invocation: false.

Speicherorte und Scope von Skills

Ort	Scope	Geeignet für	Hinweise
.agents/skills/ im Repository-Root	Aktuelles Repository	Review-, Test- und Release-Prozesse im Teamprojekt	In Git einchecken und im Team teilen
$HOME/.agents/skills/	Persönlich, projektübergreifend	Persönliche Stilregeln und häufige Kommandos	Wird nicht automatisch ins Repository synchronisiert
/etc/codex/skills/	Organisationsebene	Einheitliche Security- oder Compliance-Prüfungen	Erfordert admin permission
System bundled	Systemweit eingebaut	Codex-eigene Skills wie $skill-creator und $skill-installer	Nicht änderbar

Gleichnamige Skills werden nicht zusammengeführt. Die Priorität ist üblicherweise repo > user > admin > system. Falls sich dieses Verhalten ändert, sind die offiziellen Dokumente maßgeblich.

Progressive disclosure richtig entwerfen

Packen Sie nicht alles in das oberste SKILL.md. Codex arbeitet mit progressive disclosure in drei Schichten:

1. Metadata: Codex sieht zunächst nur name, description und den file path.
2. Instructions: Das vollständige SKILL.md wird erst geladen, wenn das Skill ausgewählt wurde.
3. Resources: references/, scripts/ und assets/ werden nur bei Bedarf geladen.

Als Richtwert sollte das Haupt-SKILL.md unter 500 Zeilen bleiben. Lange Referenzen gehören in eigene Dateien. Deterministische Checks wie Test-Runner oder Coverage-Prüfung gehören nach scripts/. Detail-Checklisten, Hintergrunddokumente und historische Beispiele gehören nach references/. Vorlagen und Beispiel-Screenshots passen nach assets/.

Expliziter und impliziter Aufruf

Explizit rufen Sie ein Skill mit $code-review oder über /skills auf. Beim impliziten Aufruf entscheidet Codex anhand der description, ob das Skill zur aktuellen Aufgabe passt. Um implizite Aufrufe zu deaktivieren, setzen Sie allow_implicit_invocation: false in agents/openai.yaml.

Implizite Aufrufe passen zu häufigen Workflows mit klaren Grenzen, zum Beispiel zu jedem PR Review. Explizite Aufrufe sind sicherer für seltene Aufgaben mit mehr menschlichem Urteil, etwa eine quartalsweise Security-Prüfung. Enthält ein Skill externe Skripte oder sensible Operationen, ist explizites Aufrufen meist besser.

4. Plugin-Paketierung und Teamverteilung: Vom lokalen Skill zur Team-Suite

Minimale Plugin-Struktur

Ein Plugin ist nicht nur ein umbenannter Skill-Ordner. Es ist ein installierbares Paket und braucht mindestens ein .codex-plugin/plugin.json manifest:

.agents/plugins/frontend-review/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── code-review/
│   │   └── SKILL.md
│   ├── accessibility-check/
│   │   └── SKILL.md
│   └── performance-lint/
│       └── SKILL.md
├── assets/
│   └── templates/
└── README.md

Pflichtfelder in plugin.json

{
  "name": "frontend-review",
  "version": "1.0.0",
  "description": "Frontend team code review and accessibility check skills",
  "skills": "./skills/",
  "assets": "./assets/",
  "author": "frontend-team",
  "repository": "https://github.com/org/frontend-review-plugin"
}

Optionale Felder sind apps für App-Integrationen wie .app.json für Figma, mcpServers für MCP server configuration wie .mcp.json und policy für Berechtigungen und Datenweitergabe. Workspace admin policy bleibt weiterhin maßgeblich.

Marketplace-Struktur für Team-Plugins

Ein Plugin marketplace ist eine JSON-Liste, die auf Plugin-Pfade zeigt:

.agents/plugins/marketplace.json

{
  "plugins": [
    {
      "source": "local",
      "path": "./frontend-review"
    },
    {
      "source": "github",
      "owner": "openai",
      "repo": "role-specific-plugins",
      "ref": "main",
      "path": "plugins/data-analytics"
    }
  ]
}

local eignet sich für interne Plugins, die noch nicht veröffentlicht sind. github verweist auf öffentliche Plugins oder auf Pakete, die teamübergreifend geteilt werden.

Kommando-Checkliste für Plugin-Verteilung

CLI-Kommandos können sich ändern. Nutzen Sie die offiziellen Dokumente als Referenz:

# Neues Plugin scaffolden
codex plugin create frontend-review

# Plugin zum marketplace hinzufügen
codex plugin marketplace add owner/repo --ref main --sparse

# Installierte Plugins auflisten
codex plugin marketplace list

# Plugin aktualisieren
codex plugin marketplace upgrade frontend-review

# Plugin entfernen
codex plugin marketplace remove frontend-review

In der Codex App kann die Plugin Directory Einträge wie Curated by OpenAI, Shared with you und Created by you anzeigen. Ein lokales Plugin kann mit workspace members oder groups geteilt werden. Workspace admins können plugin sharing deaktivieren oder managed requirements setzen.

Mit dem Workspace zu teilen heißt nicht, öffentlich zu veröffentlichen. Externe App-Verbindungen und MCP Server brauchen weiterhin Autorisierung, und approval settings gelten weiter.

Team-marketplace sinnvoll organisieren

Ein Repository-marketplace unter $REPO_ROOT/.agents/plugins/marketplace.json eignet sich für projektspezifische Plugins. Ein Organisations-marketplace unter $HOME/.agents/plugins/marketplace.json oder in einem GitHub organization repo eignet sich für teamweite Plugins. Die Version steht im Plugin-manifest im Feld version. Ein README führt den changelog. Upgrades werden vorab in einer Testumgebung geprüft. Sensible Plugins, etwa Security- oder Compliance-Prüfungen, gehören eher in den Organisations-marketplace, damit sie nicht beiläufig installiert werden.

Beginnen Sie mit einem local skill, iterieren Sie, und paketieren Sie erst bei stabiler Form als Plugin. Wer zuerst ein Plugin baut, macht spätere Änderungen oft schwerer.

5. Role-specific Plugin Design: Frontend, QA und Dokumentation als Rollen

Das OpenAI Repository role-specific-plugins enthält Vorlagen für Sales, Data Analytics, Product Design und Financial Markets. Entwicklungsteams müssen Sales- oder Finance-Abläufe nicht übernehmen. Nützlich ist aber das Zerlegungsmuster: Von einer Rolle ausgehen, 3 bis 5 kleine Skills ableiten und diese als Plugin bündeln.

Zerlegungsrahmen: Rolle → wiederkehrendes Ergebnis → Daten/Tools → kleine Skills → Sharing-Modell

Rolle	Wiederkehrendes Ergebnis	Daten-/Tool-Quelle	Abzuleitende Skills	Mögliche Apps/MCP	Abnahmekriterium
Frontend-Engineer	Komponentenprüfung, Performance-Check, Accessibility-Validierung	Figma-Designspezifikation, bestehende Storybook-Komponenten	component-audit, accessibility-check, performance-lint, design-system-sync	Figma connector, Storybook MCP	Jede neue Komponente durchläuft alle 4 Checks
QA-Engineer	Coverage-Report, E2E-Suite-Diagnose, Regressionscheckliste	CI/CD-Testergebnisse, historische Fehler	test-coverage-check, e2e-suite-runner, flaky-test-diagnosis, regression-suite-builder	CI/CD-Tools wie GitHub Actions/Jenkins	Fehlgeschlagene Tests zuerst, Coverage sinkt nicht
Technical Writer	API-docs Updates, Changelog-Erstellung, Migrationsleitfäden	API schema, Git commit history	api-doc-generator, changelog-builder, readme-audit, migration-guide-writer	GitHub API, Schema-Tools	API-Änderungen aktualisieren auch die Dokumentation
Security-Engineer	Berechtigungsgrenzen, Secret-Prüfung, Dependency Security Scan	Dependency manifests, Secret-Konfiguration	auth-boundary-check, secrets-scan, dependency-security	Snyk, Dependabot MCP	Security-Checkliste vor jedem Release abgeschlossen

Beispiel: Frontend-Rollen-Plugin zerlegen

frontend-engineer-plugin/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── component-audit/
│   │   ├── SKILL.md
│   │   └── references/
│   │       └── component-template.md
│   ├── accessibility-check/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── axe-audit.sh
│   ├── performance-lint/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── lighthouse-check.sh
│   └── design-system-sync/
│       ├── SKILL.md
│       └── references/
│           └── design-tokens.md
├── assets/
│   └── templates/
│       └── component-template.tsx
└── README.md

component-audit prüft, ob eine neue Komponente den Teamregeln folgt, etwa bei Namen, Verzeichnis und props types. accessibility-check führt ein axe-core script aus. performance-lint prüft zentrale Kennzahlen mit Lighthouse. design-system-sync vergleicht die Umsetzung mit der Figma-Spezifikation.

Beispiel: QA-Rollen-Plugin zerlegen

qa-engineer-plugin/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── test-coverage-check/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── coverage-threshold-check.sh
│   ├── e2e-suite-runner/
│   │   └── SKILL.md
│   ├── flaky-test-diagnosis/
│   │   ├── SKILL.md
│   │   └── references/
│   │       └── flaky-test-log-analysis.md
│   └── regression-suite-builder/
│       └── SKILL.md
├── .mcp.json
└── README.md

test-coverage-check erkennt, ob Coverage sinkt, und markiert nicht abgedeckte Dateien. e2e-suite-runner führt E2E-Tests nach Priorität aus. flaky-test-diagnosis analysiert historische Fehlerlogs, um instabile Tests zu finden. regression-suite-builder baut aus der Änderungsfläche eine Regressionscheckliste.

Checklist: connector placeholder ersetzen

Offizielle Vorlagen können in .app.json placeholder connector IDs enthalten. Diese müssen vor der Installation ersetzt werden:

{
  "app_id": "figma-placeholder"
}

Prüfen Sie alle placeholder IDs in .app.json und ersetzen Sie sie durch echte IDs, die in Ihrem Ziel-workspace verfügbar sind. Kopieren Sie keine connector IDs aus anderen workspaces. Sie können ungültig sein oder andere Berechtigungen haben. OAuth- oder bearer token in MCP server settings müssen zu Ihrer Umgebung passen, nicht zu einem Template-Beispiel. Danach sollte der Connector zuerst in einer Testumgebung geprüft werden.

Das offizielle README von role-specific-plugins beschreibt diese Plugins als Vorlagen, die vor der Nutzung angepasst werden sollen. Connector-backed plugins können App- oder Connector-IDs enthalten, die ersetzt werden müssen.

6. Sicherheit und Wartung: Ein Plugin ist kein Berechtigungspass

Berechtigungsgrenzen für Connector und MCP

Ein installiertes Plugin umgeht keine approval settings von Codex. Externe Apps und MCP Server brauchen weiterhin Autorisierung, und Datenweitergabe unterliegt weiterhin den jeweiligen Policies. Placeholder IDs in .app.json müssen ersetzt werden, aber Connector IDs aus fremden workspaces dürfen nicht kopiert werden. Externe Apps wie Figma oder GitHub benötigen separate Autorisierung. Ein Plugin bündelt Konfiguration, aber es autorisiert nicht selbst. MCP Server können in config.toml weiterhin über enabled und tool policy gesteuert werden. Approval mode gilt ebenfalls: Bei „suggest-only“ werden Skripte in einem Plugin nicht automatisch ausgeführt.

Behandeln Sie ein Plugin nicht als Berechtigungspass. Es verpackt Workflow, Konfiguration und Assets. Die Berechtigungsgrenze bleibt bestehen.

Quellenprüfung für Skripte

Der Ordner scripts/ in einem Skill oder Plugin kann ausführbare Dateien enthalten. Drittanbieter-Plugins und Community-marketplaces erfordern Prüfung: Sehen Sie sich alle ausführbaren Dateien unter scripts an, prüfen Sie die Quelle, führen Sie Skripte aus unverifizierten Repositories nicht direkt aus, testen Sie zuerst in einer Staging-Umgebung und pinnen Sie Versionen per tag oder commit hash statt immer main zu ziehen.

Dasselbe Prinzip, das für riskante Drittanbieter-Skills gilt, gilt auch für ausführbare Skripte und Drittanbieter-Plugins: Quelle prüfen, Rechte minimieren, Testumgebung nutzen.

Versionen und Changelog

Teamarbeit braucht Versionsverwaltung. Tragen Sie im plugin.json ein klares version Feld ein und erhöhen Sie es bei jeder Änderung. Im README gehört ein changelog, der neue, geänderte und entfernte Skills erklärt. Vor einem Upgrade testen Sie in einer Testumgebung, führen alle Skills aus, prüfen Skripte und bestätigen, dass Connectors noch verfügbar sind. In marketplace entries sollte ref auf einen tag oder commit zeigen, nicht dauerhaft auf den neuesten main.

Auswirkungen der Anzahl von Skills und Plugins

Die initiale Skill-Liste hat ein Kontextbudget. Die offizielle Dokumentation beschreibt, dass die initiale skills list ungefähr 2% des Kontexts belegt oder, bei unbekannter Kontextgröße, etwa 8.000 characters.

Praktisch heißt das: Eine zu lange Skill description kann abgeschnitten werden. Die wichtigsten Trigger-Wörter gehören nach vorn. Zu viele geladene Skills können es Codex außerdem schwerer machen, das passende Skill zu wählen. Häufig genutzte Skills mit klarer Grenze passen gut in ein repo- oder user-Verzeichnis. Seltene Skills gehören eher in ein Plugin, das Sie bei Bedarf installieren, statt alles dauerhaft aktiv zu halten.

Wenn Codex ein Skill oft falsch oder gar nicht auslöst, prüfen Sie zuerst die description. Mehr Skills sind selten die Lösung.

7. Vergleich mit verwandten Technologien

Vergleich mit Claude Code Skills

BetterLink hat den Skill-Mechanismus von Claude Code bereits behandelt. Das mentale Modell ist ähnlich, aber es sind unterschiedliche Produkte: Beide nutzen das offene Agent Skills Format und eine SKILL.md Datei. Beide verwenden name, description sowie optionale scripts/, references/ und assets/. Beide unterstützen progressive disclosure von metadata über instructions bis resources.

Die Unterschiede sind wichtig. Codex verwendet .agents/skills/, Claude Code verwendet .claude/skills/. Codex ruft Skills mit $skill-name oder /skills auf, Claude Code mit dem /skill command. Bei der Plugin-Verteilung hat Codex Plugin einen marketplace, CLI commands und workspace sharing. Claude Code hat derzeit keinen offiziellen Plugin marketplace. Auch die eingebauten Tools unterscheiden sich: Codex hat $skill-creator, $skill-installer und @plugin-creator; Claude Code hat andere integrierte Befehle.

Wenn Sie schon Claude Code Skills geschrieben haben, können Sie das Grundmodell übernehmen. Pfade und Aufrufsyntax sollten Sie nicht blind kopieren, sondern an die jeweilige offizielle Dokumentation anpassen.

Abgrenzung zu MCP

MCP, das Model Context Protocol, verbindet externe Tools und Kontext. Es ersetzt weder Skills noch Plugins. Ein Skill definiert den Workflow. MCP verbindet externe Tools wie Figma, GitHub oder CI/CD-Systeme. Ein Plugin kann MCP server configuration verpacken, aber der MCP Server selbst bleibt weiterhin in config.toml steuerbar.

Beispiel: Ein Frontend-Review-Skill definiert den Ablauf „prüfen, ob die Komponente zur Designspezifikation passt“. Ein Figma MCP Server liefert Zugriff auf die Design-Datei. Ein Frontend-Plugin verpackt Review-Skill und Figma-MCP-Konfiguration. Figma OAuth muss trotzdem separat autorisiert werden.

Hier geht es nur um die Abgrenzung. Ein eigener Codex MCP tools Praxisleitfaden kann die Umsetzung ausführlicher behandeln.

Fazit

Codex Skills und Plugins sind nützlich, weil sie wiederholte Teamabläufe aus kopierten Prompts und einer überladenen AGENTS.md herauslösen. Die Faustregel ist einfach: AGENTS.md für dauerhafte Regeln, Skill für mehrstufige Workflows, Plugin für Verpackung und Verteilung, MCP für externe Systeme. Schreiben Sie klare Triggerbedingungen in die description, validieren Sie zuerst ein local skill und verpacken Sie es erst dann als Plugin, wenn Verteilung wirklich nötig ist. Skripte, connector IDs und MCP-Konfigurationen aus Drittanbieter-Plugins müssen weiterhin geprüft werden.

Starten Sie mit einem minimalen Skill. Machen Sie den Code-Review- oder Testablauf Ihres Teams zu SKILL.md, führen Sie ihn ein paar Mal aus und prüfen Sie, ob das Trigger-Verhalten zuverlässig ist. Wenn Ihr Team Frontend-, QA-, Security- oder Dokumentationsrollen hat, nutzen Sie das Zerlegungsmuster aus OpenAI role-specific-plugins: 3 bis 5 kleine Skills pro Rolle, danach als Rollen-Plugin bündeln.

Weiterführende BetterLink-Beiträge:

• Vollständiger Codex-Einstieg
• AGENTS.md Projektregeln
• Codex Sicherheitsgrenzen und Berechtigungsverwaltung
• Codex MCP tools in der Praxis
• Claude Code Skill Vergleich
• MCP-Protokoll Grundlagen