# 10 beste Agent Skills für Codex zur Verbesserung Ihres Workflows
> Entdecken Sie die besten Codex-Skills für die Planung von Projekten, das Debuggen fehlgeschlagener CI-Pipelines, das Testen von Anwendungen, das Implementieren von Designs, das Bereitstellen von Webprojekten und die Optimierung alltäglicher Entwicklungsworkflows.
- Canonical: https://nanoskill.ai/de/blog/best-agent-skills-for-codex
- Markdown: https://nanoskill.ai/de/blog/best-agent-skills-for-codex.md
- Author: Jeff Page
- Published: 2026-06-26T09:09:24.794Z
- Updated: 2026-07-25T04:38:34.299Z
- Language: de
## Einführung
Codex kann bereits Code schreiben, unbekannte Repositories erklären, Fehler beheben und Entwicklern helfen, schneller voranzukommen. Doch für die meisten Teams liegt der eigentliche Engpass nicht in der Generierung einiger weniger Codezeilen.
Es ist alles um den Code herum.
Die Planung einer Funktion vor der Implementierung. Das Verstehen eines fehlgeschlagenen CI-Laufs. Das Beantworten von Pull-Request-Kommentaren. Das Testen eines Benutzerflusses in einem echten Browser. Das Bereinigen eines Datensatzes. Das Schreiben von Dokumentation. Die Vorbereitung eines Projekts für die Bereitstellung. Dies sind die sich wiederholenden Workflows, die jede Woche still und leise Stunden verbrauchen. Hier kommen Agent Skills ins Spiel.
Agent Skills geben Codex eine wiederholbare Möglichkeit, eine bestimmte Art von Aufgabe zu bewältigen. Anstatt dieselben Anforderungen in jedem Prompt neu zu erklären, können Sie Codex mit strukturierten Anweisungen, unterstützenden Ressourcen und aufgabenspezifischen Workflows ausstatten. Das Ergebnis ist nicht nur eine schnellere Ausgabe, sondern auch konsistentere Arbeit in den Bereichen Planung, Entwicklung, Testen, Überprüfung und Bereitstellung.
Mit den richtigen Skills wird Codex mehr als ein Coding-Assistent. Es kann eher wie ein fokussierter Teamkollege arbeiten, der weiß, wie Ihr Team Funktionen plant, Qualität prüft, Daten analysiert und Projekte ausliefert.
In diesem Leitfaden werfen wir einen Blick auf die besten Agent Skills für Codex im Jahr 2026, darunter Skills für Produktplanung, GitHub-Workflows, Browser-Tests, Datenanalyse, Sicherheitsüberprüfungen, Design-to-Code, Bereitstellung und Dokumentation. Das Ziel ist es nicht, jeden auffindbaren Skill zu installieren. Es geht darum, diejenigen zu identifizieren, die die häufigsten Reibungspunkte aus Ihrem Workflow entfernen.
## **Auf einen Blick: Die besten Agent Skills für Codex**
Hier ein kurzer Überblick über die besten Agent Skills für Codex und die Workflows, für die sie am nützlichsten sind.
### Schnellvergleich: Die besten Agent Skills für Codex
| Skill | Am besten geeignet für | Was es Codex ermöglicht | Was Sie benötigen |
| --- | --- | --- | --- |
| Define Goal | Klare Erfolgskriterien | Wandelt vage Anfragen in messbare Ziele, Umfangsgrenzen und Überprüfungsschritte um | Eine Aufgabe mit unklaren Anforderungen oder mehreren möglichen Ergebnissen |
| gh-fix-ci | Beheben fehlgeschlagener CI-Prüfungen | Untersucht GitHub Actions-Fehler, überprüft Logs und schlägt einen fokussierten Reparaturplan vor | GitHub CLI-Zugriff und ein Repository, das GitHub Actions verwendet |
| gh-address-comments | PR-Review-Feedback | Sammelt Review-Kommentare, fasst angeforderte Änderungen zusammen und hilft, ausgewähltes Feedback zu adressieren | Ein offener GitHub-Pull-Request und GitHub CLI-Zugriff |
| Playwright | Browser-Tests und UI-Debugging | Öffnet einen echten Browser, testet Benutzerflüsse, füllt Formulare aus, klickt auf Schaltflächen und erstellt Screenshots | Ein Webprojekt plus eine funktionierende Node.js- und npm-Umgebung |
| Security Best Practices | Standardmäßig sicheres Programmieren | Überprüft Code auf häufige Sicherheitsrisiken und empfiehlt sicherere Implementierungsmuster | Eine unterstützte Codebasis, z. B. Python, JavaScript/TypeScript oder Go |
| Figma Implement Design | Figma-zu-Code-Workflows | Wandelt Figma-Layouts, Komponenten und Design-Tokens in Anleitungen für die Frontend-Implementierung um | Figma MCP-Zugriff und eine Figma-Datei, ein Frame oder ein ausgewählter Knoten |
| Jupyter Notebook | Datenanalyse und Experimente | Erstellt und strukturiert Notebooks für Forschung, Analyse, Tutorials und reproduzierbare Workflows | Ein Datensatz, ein Experiment oder ein Analyse-Workflow |
| CLI Creator | Wiederverwendbare interne Tools | Erstellt langlebige Befehlszeilen-Tools für wiederkehrende Aufgaben, APIs und interne Automatisierung | Ein wiederholter Workflow, der es wert ist, in ein gemeinsames Tool umgewandelt zu werden |
| Vercel Deploy | Bereitstellung von Vorschau-Bereitstellungen | Veröffentlicht ein Webprojekt und generiert eine teilbare Vorschau-URL zum Testen und Feedback | Ein bereitstellbares Webprojekt und Vercel-Zugriff |
| OpenAI Docs | Arbeiten mit OpenAI-Produkten | Verwendet die offizielle OpenAI-Dokumentation für APIs, Modelle, SDKs, Migrationen und Codex-Workflows | Eine OpenAI-bezogene Entwicklungsaufgabe |
### Schnellauswahl nach Anwendungsfall
- **Beginnen Sie hier, wenn Ihre Anforderungen vage sind:**Ziel definieren
- **Beginnen Sie hier, wenn GitHub-Workflows Sie ausbremsen:**gh-ci-beheben oder gh-kommentare-bearbeiten
- **Beginnen Sie hier, wenn Sie Webprodukte entwickeln:**Playwright und Vercel-Bereitstellung
- **Beginnen Sie hier, wenn Sie eng mit Designern zusammenarbeiten:**Figma-Designumsetzung
- **Beginnen Sie hier, wenn Sie Forschungs- oder Geschäftsdaten analysieren:**Jupyter-Notebook
- **Beginnen Sie hier, wenn Ihr Team dieselbe manuelle Aufgabe wiederholt:**CLI-Ersteller
- **Beginnen Sie hier, wenn Sie KI-Funktionen mit OpenAI entwickeln:**OpenAI-Dokumentation
- **Beginnen Sie hier, wenn Sie sicherere Entwicklungsgewohnheiten anstreben:**Bewährte Sicherheitspraktiken
Die beste Wahl hängt davon ab, wo Ihr Workflow am meisten verlangsamt wird. Wenn Sie ein neues Produkt entwickeln, beginnen Sie mit Planungs-, Test- und Bereitstellungsfähigkeiten. Wenn Sie täglich mit GitHub arbeiten, priorisieren Sie CI-, Pull-Request- und Sicherheits-Workflows. Wenn Ihre Arbeit Forschungs- oder Wachstumsdaten umfasst, können Datenanalyse- und Dokumentationsfähigkeiten mehr Wert liefern.
## **Beste Codex-Agent-Fähigkeiten: Detaillierte Bewertungen**
### **Unsere Bewertungskriterien**
Wir haben diese Codex-Fähigkeiten anhand von fünf praktischen Faktoren bewertet:
- **Workflow-Auswirkung:**Beseitigt die Fähigkeit einen bedeutsamen Engpass in der realen Entwicklungsarbeit?
- **Einrichtungsaufwand:**Wie viel Konfiguration, Authentifizierung oder externe Werkzeuge erfordert sie?
- **Kontrolle und Sicherheit:**Hält die Fähigkeit die Benutzer in der Kontrolle, bevor Code- oder Bereitstellungsänderungen vorgenommen werden?
- **Klarheit des Umfangs:**Ist klar, wann die Fähigkeit eingesetzt werden sollte und wann nicht?
- **Wiederverwendbarkeit:**Kann der Workflow in mehreren Projekten, Repositories oder Teams helfen?
Dies sind redaktionelle Bewertungen, die auf dem dokumentierten Workflow, den Voraussetzungen und den beabsichtigten Anwendungsfällen jeder Fähigkeit basieren. Sie sind keine Benchmark-Ergebnisse oder Garantien für die Ausgabequalität.
### **Ziel definieren: Am besten für klare Erfolgskriterien**
](https://file.nanoskill.ai/define-goal.png)
**Was es bewirkt:**
Ziel definieren hilft Codex, breite Anfragen in eine konkrete Definition des Erfolgs umzuwandeln, bevor die Implementierung beginnt. Anstatt eine Anfrage wie „Verbessern Sie den Onboarding-Ablauf“ als einfache Codierungsaufgabe zu behandeln, ermutigt es den Benutzer und den Agenten zu klären, was geändert werden muss, was außerhalb des Rahmens liegt, wie das Ergebnis getestet wird und welche Bedingungen anzeigen, dass die Arbeit abgeschlossen ist.
**Warum es heraussticht:**
Eine überraschende Anzahl von Entwicklungsaufgaben scheitert, weil das Ziel nie klar definiert wurde. Der Code mag funktionieren, aber er löst möglicherweise das falsche Problem, übersieht einen wichtigen Grenzfall oder führt zu einer weiteren Überarbeitungsrunde. Ziel definieren gibt Codex einen stärkeren Ausgangspunkt, indem es die Konversation von vager Aktivität zu messbaren Ergebnissen lenkt.
Es ist besonders nützlich, wenn eine Aufgabe mehrere Beteiligte, unklare Produktanforderungen, Leistungsziele, Migrationsarbeiten oder Fehlerberichte umfasst, die in testbare Abnahmekriterien übersetzt werden müssen. Indem die Ziellinie definiert wird, bevor die Programmierung beginnt, können Teams unnötiges Hin und Her reduzieren und Codex klarere Leitplanken für die bevorstehende Arbeit geben.
**Beispielaufgabe:**
„Verbessern Sie den Onboarding-Ablauf für neue Benutzer. Definieren Sie ein messbares Ziel, klären Sie die angestrebte Benutzeraktion, identifizieren Sie, was im und außerhalb des Rahmens liegt, schlagen Sie Abnahmekriterien vor und erklären Sie, wie das endgültige Ergebnis überprüft werden sollte, bevor die Implementierung beginnt.“
**Am besten für:**
Produktteams, Entwickler und technische Leiter, die mit mehrdeutigen Feature-Anfragen, Fehlerbehebungen, Migrationsaufgaben oder qualitätskritischer Arbeit umgehen.
### **gh-ci-beheben: Am besten zum Beheben fehlgeschlagener CI-Checks**
](https://file.nanoskill.ai/gh-fix-ci-skill.png)
**Was es bewirkt:**
gh-ci-beheben hilft Codex, fehlgeschlagene GitHub Actions-Checks bei einem Pull-Request zu untersuchen. Es kann den Workflow-Status prüfen, Fehlerprotokolle durchsehen, die wahrscheinlichste Ursache des Problems identifizieren und einen fokussierten Reparaturplan vorschlagen, bevor Änderungen vorgenommen werden.
**Warum es heraussticht:**
CI-Fehler sind eine der häufigsten Reibungsquellen in der modernen Softwareentwicklung. Ein Entwickler muss möglicherweise zwischen GitHub-Protokollen, lokalen Testausgaben, Abhängigkeitsdateien, Pull-Request-Änderungen und Workflow-Konfiguration hin- und herspringen, nur um zu verstehen, warum ein Build fehlgeschlagen ist. gh-ci-beheben gibt Codex eine strukturierte Möglichkeit, diesen Kontext zu sammeln und das Problem einzugrenzen.
Die Fähigkeit ist besonders wertvoll, weil sie Diagnose von Implementierung trennt. Anstatt sofort umfassende Änderungen vorzunehmen, kann Codex zunächst erklären, was fehlgeschlagen ist, warum es wahrscheinlich fehlgeschlagen ist und was als Nächstes überprüft werden sollte. Dies macht den Arbeitsablauf transparenter und gibt Entwicklern einen schnelleren Weg von einem roten CI-Status zu einer verifizierten Korrektur
**Beispielaufgabe:**
„Untersuchen Sie die fehlgeschlagenen GitHub Actions-Prüfungen für diesen Pull Request. Fassen Sie die wahrscheinliche Ursache zusammen, identifizieren Sie die betroffenen Dateien oder Workflow-Schritte und schlagen Sie den kleinstmöglichen sicheren Reparaturplan vor, bevor Sie Code-Änderungen vornehmen.“
**Am besten geeignet für:**
Teams, die GitHub Actions für Tests, Builds, Linting, Typüberprüfungen und Pull Request-Validierung verwenden.
### **gh-address-comments: Am besten für PR-Review-Feedback**
](https://file.nanoskill.ai/gh-address-comments-skill.png)
**Was es tut:**
gh-address-comments hilft Codex, Feedback aus Pull Request-Reviews zu sammeln und zu organisieren. Es kann Review-Threads identifizieren, zusammenfassen, was jeder Kommentar erfordert, verwandte Anfragen gruppieren und Benutzern helfen, zu entscheiden, welche Kommentare zu Code-Änderungen führen sollten.
**Warum es heraussticht:**
Code-Review ist selten wegen eines einzigen Kommentars schwierig. Es wird zeitaufwendig, wenn das Feedback über mehrere Reviewer, Dateien, Threads und Folgediskussionen verstreut ist. Entwickler müssen oft manuell Kommentare erneut lesen, entscheiden, welche Maßnahmen erfordern, die Absicht hinter jeder Anfrage verstehen und den Überblick behalten, was bereits behandelt wurde.
Diese Fähigkeit verwandelt diesen fragmentierten Prozess in einen besser handhabbaren Arbeitsablauf. Anstatt jeden Review-Kommentar als gleich dringend zu behandeln, kann Codex helfen, das Feedback zusammenzufassen, die umsetzbaren Punkte hervorzuheben und den Überarbeitungsprozess bewusster zu gestalten. Es ist besonders nützlich für größere Pull Requests, schnelllebige Teams und Entwickler, die den Kontextwechsel reduzieren möchten, während sie dennoch sorgfältig auf Reviewer-Feedback reagieren
**Beispielaufgabe:**
„Überprüfen Sie alle ungelösten Kommentare zum aktuellen Pull Request. Gruppieren Sie verwandtes Feedback, fassen Sie zusammen, was jeder Reviewer verlangt, identifizieren Sie, welche Kommentare Code-Änderungen erfordern, und bitten Sie mich, die Punkte zu bestätigen, die Sie bearbeiten sollen, bevor Sie den Branch bearbeiten.“
**Am besten geeignet für:**
Entwickler, die in kollaborativen GitHub-Repositories mit häufigen Pull Requests und Feedback von mehreren Reviewern arbeiten.
### **Playwright: Am besten für Browser-Tests und UI-Debugging**
](https://file.nanoskill.ai/playwright-skill)
**Was es tut:**
Playwright gibt Codex die Fähigkeit, über das Terminal mit einem echten Browser zu interagieren. Es kann Seiten öffnen, durch Benutzerabläufe navigieren, Formulare ausfüllen, Schaltflächen klicken, den Seitenzustand inspizieren, Screenshots machen und helfen, Probleme mit der Benutzeroberfläche zu reproduzieren, die allein durch Code schwer zu verstehen sind.
**Warum es heraussticht:**
Eine Funktion kann Unit-Tests bestehen und dennoch in der tatsächlichen Produkterfahrung fehlschlagen. Ein Formular kann falsch übermittelt werden, ein Modal schließt möglicherweise nicht, eine Schaltfläche kann auf kleineren Bildschirmen versteckt sein, oder eine Seite funktioniert nur nach einer bestimmten Klicksequenz nicht mehr. Dies sind die Arten von Problemen, die offensichtlich werden, wenn jemand mit dem Produkt so interagiert, wie es ein Benutzer tun würde.
Playwright hilft Codex, über das Repository-Level-Denken hinauszugehen und sichtbares Verhalten in einer echten Browserumgebung zu validieren. Das macht es wertvoll für das Debuggen von UI-Regressionen, das Überprüfen von Onboarding-Abläufen, die Validierung von Zahlungs- oder Anmeldevorgängen und die Bestätigung, dass eine Funktion aus der Benutzerperspektive funktioniert und nicht nur im Code.
**Beispielaufgabe:**
„Führen Sie die lokale Anwendung aus und testen Sie den Anmeldeablauf in einem echten Browser. Erstellen Sie ein Testkonto, füllen Sie die erforderlichen Felder aus, überprüfen Sie, ob der Bestätigungsbildschirm erscheint, und machen Sie einen Screenshot und einen Trace, falls ein Schritt fehlschlägt.“
**Am besten geeignet für:**
Frontend-Entwickler, SaaS-Teams, QA-Workflows und alle, die browserbasierte Produkte entwickeln.
### **Security Best Practices: Am besten für „Secure by Default“-Codierung**
](https://file.nanoskill.ai/security-best-practices)
**Was es tut:**
Security Best Practices hilft Codex, Code auf häufige Sicherheitsrisiken zu überprüfen und sicherere Implementierungsmuster zu empfehlen. Es kann den Agenten dazu anleiten, sorgfältiger über Eingabevalidierung, Umgang mit Geheimnissen, Authentifizierung, Berechtigungen, unsichere Standardeinstellungen und häufige Schwachstellen auf Anwendungsebene nachzudenken.
**Warum es heraussticht:**
Sicherheitsprobleme beginnen oft mit normal aussehenden Entwicklungsentscheidungen: eine fehlende Autorisierungsprüfung, eine offengelegte Umgebungsvariable, schwache Eingabevalidierung, eine zu weit gefasste Berechtigungsregel oder unsichere Handhabung von Benutzerdaten. Diese Probleme werden leicht übersehen, wenn ein Team sich darauf konzentriert, Funktionen schnell auszuliefern.
Diese Fähigkeit hilft, Sicherheitsdenken früher in den Entwicklungsprozess einzubringen. Anstatt Sicherheit als Checkliste für die Endphase zu behandeln, kann Codex sicherere Implementierungsmuster verwenden, während der Code geschrieben oder überprüft wird. Sie ist besonders nützlich für kleine Teams, die keinen dedizierten Sicherheitsingenieur haben, der jeden Pull-Request überprüft, aber dennoch stärkere Gewohnheiten im Bereich der standardmäßig sicheren Entwicklung benötigen.
**Beispielaufgabe:**
„Überprüfe den Authentifizierungs- und Benutzerprofil-Aktualisierungsablauf in dieser Anwendung auf häufige Sicherheitsrisiken. Überprüfe Eingabevalidierung, Autorisierung, Geheimnisbehandlung, Sitzungsverwaltung und unsichere Standardeinstellungen. Empfehle standardmäßig sichere Änderungen mit Codebeispielen.“
**Am besten geeignet für:**
Startups, Fullstack-Entwickler, API-Entwickler und Teams, die an kundenorientierten Anwendungen arbeiten.
### **Figma-Implementierungsdesign: Am besten für Figma-zu-Code-Workflows**
](https://file.nanoskill.ai/figma-implement-design)
**Was es macht:**
Figma Implement Design hilft Codex, Figma-Komponenten, Bildschirme, Layouts, Design-Tokens und visuelle Referenzen in produktionsreifen Frontend-Code zu übersetzen. Es gibt dem Agenten strukturierten Designkontext, sodass Implementierungsentscheidungen auf dem tatsächlichen Design basieren und nicht auf grober visueller Interpretation.
**Warum es herausragt:**
Die Designübergabe ist eine der größten Reibungsquellen zwischen Produktdesign und Frontend-Entwicklung. Entwickler müssen Abstände, Typografie, responsives Verhalten, Ikonografie, Komponenten, Zustände und bestehende Designsystem-Konventionen verstehen. Ohne klaren Kontext kann die Implementierung vom beabsichtigten Design abweichen oder inkonsistente UI-Muster einführen.
Diese Fähigkeit macht die Übergabe systematischer. Sie ermutigt Codex, vorhandene Komponenten und Design-Tokens nach Möglichkeit wiederzuverwenden, visuelle Muster genauer zu befolgen und die endgültige Ausgabe am ursprünglichen Design zu validieren. Für Teams, die täglich in Figma arbeiten, kann dies den Weg von der Designgenehmigung zu einer ausgefeilteren, konsistenteren Implementierung verkürzen.
**Beispielaufgabe:**
„Verwende den ausgewählten Figma-Frame, um diese Dashboard-Seite im bestehenden Frontend-Projekt zu implementieren. Verwende nach Möglichkeit die aktuelle Komponentenbibliothek und die Design-Tokens wieder, gleiche das Layout und die Typografie genau ab, unterstütze responsives Verhalten und vergleiche die endgültige Seite mit dem Figma-Design.“
**Am besten geeignet für:**
Produktteams, Frontend-Entwickler und Designer, die mit Figma-basierten Designsystemen arbeiten.
### **Jupyter Notebook: Am besten für Datenanalyse und Experimente**
](https://file.nanoskill.ai/jupyter-notebook)
**Was es macht:**
Jupyter Notebook hilft Codex, Notebooks für Datenanalyse, Experimente, Tutorials und reproduzierbare Forschungsworkflows zu erstellen, zu bearbeiten, zu organisieren und umzustrukturieren. Es kann eine klarere Notebook-Struktur mit lesbaren Markdown-Erklärungen, logischen Codezellen und durchdachteren Analyseschritten unterstützen.
**Warum es herausragt:**
Ein Notebook ist nicht allein deshalb nützlich, weil es ausgeführt wird. Ein gutes Notebook sollte auch für andere leicht verständlich, reproduzierbar und erweiterbar sein. In der Praxis werden viele Notebooks schwer nachvollziehbar, weil Code, Notizen, temporäre Experimente und Ergebnisse ohne klare Struktur vermischt werden.
Diese Fähigkeit hilft Codex, Notebooks zu erstellen, die mehr sind als Wegwerf-Notizblöcke. Sie kann sauberere explorative Analysen, verständlichere Experimente und bessere tutorialartige Notebooks für Lehre oder Austausch unterstützen. Das macht sie wertvoll für Forscher, Analysten, Wachstumsteams und alle, die Datenarbeit in ein wiederverwendbares Artefakt verwandeln müssen, anstatt in ein einmaliges Skript.
**Beispielaufgabe:**
„Erstelle ein sauberes Jupyter-Notebook, das diesen CSV-Datensatz analysiert. Füge Datenbereinigung, deskriptive Statistiken, Visualisierungen, wichtigste Erkenntnisse und Markdown-Erklärungen für jeden Schritt hinzu. Strukturiere das Notebook so, dass ein anderer Forscher es von oben bis unten ausführen kann.“
**Am besten geeignet für:**
Forscher, Analysten, Pädagogen, Praktiker des maschinellen Lernens und Teams, die mit Experimenten oder strukturierten Datensätzen arbeiten.
### **CLI Creator: Am besten für wiederverwendbare interne Tools**
](https://file.nanoskill.ai/cli-creator)
**Was es macht:**
CLI Creator hilft Codex, langlebige Befehlszeilenwerkzeuge für wiederkehrende Arbeitsabläufe zu erstellen. Diese Werkzeuge können API-Interaktionen, lokale Automatisierungen, interne Operationen, Datenabfragen, Verwaltungsaufgaben und wiederholbare Aktionen unterstützen, die sonst manuelle Browserarbeit oder einmalige Skripte erfordern würden.
**Warum es sich auszeichnet:**
Viele Teams führen wiederholt die gleichen Aufgaben aus: Protokolle überprüfen, Daten exportieren, Dateien hochladen, interne Systeme abfragen, Informationen synchronisieren oder sichere operative Aktionen auslösen. Anfangs werden diese Aufgaben oft durch Ad-hoc-Skripte oder eine Reihe undokumentierter manueller Schritte erledigt. Im Laufe der Zeit führt das zu Reibungsverlusten, Inkonsistenz und unnötiger Abhängigkeit von einzelnen Teammitgliedern.
CLI Creator hilft, wiederholte Arbeit in ein saubereres internes Produkt zu verwandeln. Anstatt jede Woche das gleiche Problem zu lösen, können Teams eine wiederverwendbare Befehlszeilenschnittstelle mit klareren Befehlen, vorhersehbarer Ausgabe, sicherer Authentifizierungsbehandlung und einer Dokumentation erstellen, der andere folgen können. Es ist eine der stärksten Fähigkeiten, um Codex von einem einmaligen Assistenten in einen Werkzeugbau-Partner zu verwandeln.
**Beispielaufgabe:**
„Erstelle ein wiederverwendbares CLI-Tool, das Kundendatensätze über unsere interne API per E-Mail-Adresse abruft. Enthalte klare Befehle, Hilfetext, JSON-Ausgabe, Authentifizierung über Umgebungsvariablen, Fehlerbehandlung und einen`--Trockenlauf`Modus für jede Schreiboperation.”
**Am besten für:**
Entwicklungsteams, Plattformteams, Betriebsteams und Entwickler mit wiederkehrenden internen Arbeitsabläufen.
### **Vercel Deploy: Am besten für die Bereitstellung von Vorschau-Deployments**
](https://file.nanoskill.ai/vercel-deploy-skill)
**Was es macht:**
Vercel Deploy hilft Codex, ein Webprojekt auf Vercel zu veröffentlichen und eine teilbare Vorschau-Bereitstellung zu generieren. Dies gibt Benutzern eine Live-URL, die geöffnet, überprüft, getestet und geteilt werden kann, bevor ein Projekt für die Produktion freigegeben wird.
**Warum es sich auszeichnet:**
Ein Projekt wird leichter zu bewerten, sobald die Leute in einem Browser damit interagieren können. Lokale Entwicklung ist nützlich zum Bauen, aber Vorschau-Bereitstellungen sind das, was Teammitgliedern, Kunden, Designern, Stakeholdern und frühen Benutzern erlaubt, das Ergebnis im Kontext zu sehen.
Diese Fähigkeit verkürzt die Distanz zwischen „der Code funktioniert auf meinem Rechner“ und „jemand anderes kann es testen“. Das macht sie besonders nützlich für Portfolios, Landingpages, Prototypen, interne Dashboards, MVPs und frühe SaaS-Experimente. Es unterstützt außerdem einen sichereren Veröffentlichungsrhythmus, indem es sich auf Vorschau-Bereitstellungen konzentriert, bei denen Teams Feedback sammeln und Probleme erkennen können, bevor sie zu einem vollständigen Produktionsstart übergehen
**Beispielaufgabe:**
„Stelle das aktuelle Webprojekt als Vorschau-Bereitstellung auf Vercel bereit. Überprüfe, ob der Build erfolgreich ist, gib die Vorschau-URL zurück und erstelle oder ändere keine Produktionsbereitstellung.“
**Am besten für:**
Indie-Hacker, Studenten, Startup-Teams, Produktentwickler und alle, die schnell teilbare Vorschau-Links benötigen.
### **OpenAI Docs: Am besten für die Entwicklung mit OpenAI-Produkten**
](https://file.nanoskill.ai/openai-docs)
**Was es macht:**
OpenAI Docs hilft Codex, die offizielle OpenAI-Dokumentation zu verwenden, wenn mit OpenAI-APIs, -Modellen, -SDKs, -Migrationen, -Agenten und Codex-bezogenen Arbeitsabläufen gearbeitet wird. Es fördert Implementierungsentscheidungen, die auf aktueller Erstanbieter-Dokumentation basieren, anstatt auf veralteten Tutorials oder inoffiziellen Beispielen.
**Warum es sich auszeichnet:**
Die KI-Entwicklung verändert sich schnell. Modellfähigkeiten, API-Parameter, SDK-Muster, Migrationsanleitungen und Produktempfehlungen können sich schneller weiterentwickeln, als viele Drittanbieter-Tutorials aktualisiert werden. Das birgt ein echtes Risiko für Entwickler, die Beispiele aus alten Blogbeiträgen oder Community-Snippets kopieren, ohne zu prüfen, ob die Informationen noch aktuell sind.
Diese Fähigkeit bietet Codex eine zuverlässigere Wissensquelle bei der Arbeit mit OpenAI-Produkten. Sie ist besonders nützlich für Implementierungsfragen, die auf aktueller Dokumentation basieren, etwa bei der Auswahl des richtigen API-Musters, dem Verständnis unterstützter Funktionen, dem Umgang mit Migrationsänderungen oder der Beachtung der neuesten Anleitungen für Codex- und Agent-Workflows.
**Beispielaufgabe:**
„Empfehle nur unter Verwendung der offiziellen OpenAI-Dokumentation den besten aktuellen Implementierungsansatz, um dieser Anwendung eine dokumentbasierte Frage-Antwort-Funktion hinzuzufügen. Vergleiche die relevanten API-Optionen, liste die erforderlichen Einrichtungsschritte, erkläre die wichtigsten Parameter und stelle ein minimales TypeScript-Beispiel bereit.“
**Am besten geeignet für:**
Entwickler, die mit OpenAI-APIs, OpenAI-Modellen, Agents, Codex oder KI-gestützten Produktfunktionen entwickeln.
## **Beispiele für Codex-Skill-Workflows**
Agent-Fähigkeiten lassen sich leichter bewerten, wenn man sieht, wie sie eine reale Aufgabe verändern. Anstatt nur Funktionen aufzulisten, zeigt das folgende Beispiel, was passiert, wenn Codex eine vage Produktanfrage erhält und eine strukturierte Fähigkeit nutzt, um ein klareres, überprüfbareres Ergebnis zu erzielen.
### **Workflow 1: „Onboarding verbessern“ in ein messbares Produktziel verwandeln**
**Szenario:**
Ein SaaS-Team stellt fest, dass viele neue Benutzer ein Konto erstellen, aber abbrechen, bevor sie die Workspace-Einrichtung abschließen. Die ursprüngliche Anfrage ist einfach: „Onboarding-Ablauf verbessern.“ Allerdings definiert die Anfrage keine Zielmetrik, keine Frist, keinen Umfang und keine klare Möglichkeit, den Erfolg der Arbeit nachzuweisen.
**Verwendete Fähigkeit:**
Ziel definieren
**Verwendeter Prompt:**
„Den Onboarding-Ablauf für neue Benutzer verbessern. Definiere ein messbares Ziel, verdeutliche die angestrebte Benutzeraktion, lege fest, was im Umfang enthalten und was ausgeschlossen ist, schlage Akzeptanzkriterien vor und erkläre, wie das endgültige Ergebnis überprüft werden soll, bevor mit der Implementierung begonnen wird.“
Anstatt sofort UI-Änderungen vorzuschlagen oder Code zu schreiben, formulierte Codex die Anfrage zunächst als Produktziel um. Es legte ein 30-Tage-Ziel fest, bestimmte Basis-Metriken, setzte messbare Erfolgskriterien und identifizierte die erforderlichen Nachweise, um zu überprüfen, ob die Arbeit die Onboarding-Erfahrung tatsächlich verbessert hat.
](https://file.nanoskill.ai/define-goal-sample1)
Die ursprüngliche Anfrage enthielt keine messbare Definition von Erfolg. Nach Anwendung von „Ziel definieren“ konvertierte Codex sie in ein konkretes Ergebnis: die Onboarding-Abschlussquote von 42 % auf mindestens 55 % zu steigern und gleichzeitig die durchschnittliche Abschlusszeit von 6 Minuten 30 Sekunden auf 5 Minuten oder weniger zu reduzieren.
Dies ist der zentrale Wert der Fähigkeit. Sie überführt die Aufgabe von „etwas verbessern“ in ein Ziel, das nach der Veröffentlichung getestet, gemessen und überprüft werden kann.
Codex fügte außerdem vier Elemente hinzu, die bei vage definierten Anfragen oft fehlen:
- **Klare Erfolgskriterien:**was das Team erreichen muss, damit die Arbeit als erfolgreich angesehen werden kann.
- **Definierter Umfang:**welcher Teil der Onboarding-Erfahrung zuerst verbessert werden soll.
- **Nachweise zur Überprüfung:**die nach der Veröffentlichung erforderlichen Analysen, um das Ergebnis zu bestätigen.
- **Stop-and-ask-Bedingungen:**die Situationen, in denen Codex um Klärung bitten sollte, anstatt Annahmen zu treffen.
](https://file.nanoskill.ai/define-goal-sample2)
Ein wichtiger Teil dieses Workflows ist, dass Codex das Ziel nicht als abgeschlossen markierte. Es erkannte korrekt, dass das Ziel blockiert blieb, bis zwei Dinge geschahen: Der überarbeitete Onboarding-Ablauf wurde veröffentlicht, und die Post-Release-Analysen bestätigten die Zielmetriken unter Verwendung derselben Basis-Ereignisdefinitionen.
Diese Unterscheidung ist wichtig. Die Fähigkeit kann das Ziel definieren, den Validierungsplan vorbereiten und unterstützende Artefakte erstellen, aber sie sollte ohne reale Evidenz keinen Erfolg behaupten.
**Warum dieser Workflow wichtig ist:**
„Ziel definieren“ ist am nützlichsten, wenn eine Aufgabe mit einer mehrdeutigen Anfrage, mehreren Stakeholdern oder unklaren Erfolgskriterien beginnt. Es gibt Codex einen disziplinierten Ausgangspunkt und hilft Teams dabei, sich vor Beginn der Implementierung darauf zu einigen, was „erledigt“ tatsächlich bedeutet.
### **Workflow 2: Von einem fehlgeschlagenen CI-Check zu einem fokussierten Reparaturplan**
**Szenario:**
Ein Pull-Request schlägt bei der automatisierten Testprüfung nach einer kleinen Codeänderung fehl. Der Entwickler sieht, dass der CI-Status rot ist, muss aber noch feststellen, was tatsächlich fehlgeschlagen ist, ob das Problem vom Code oder vom Test stammt und was die kleinste sichere Korrektur sein sollte.
In diesem Beispiel erwartet der fehlgeschlagene Test, dass eine Funktion add(2, 2) den Wert 5 zurückgibt, während das tatsächliche Ergebnis`4`ist. Die wichtige Frage ist nicht einfach, wie die Prüfung bestanden werden kann. Es geht darum, ob die Implementierung falsch ist, die Testerwartung falsch ist oder der Fehler auf ein umfassenderes Problem hinweist.
**Verwendeter Skill:**
gh-fix-ci
**Beispiel-Prompt:**
„Überprüfe die fehlgeschlagenen GitHub Actions-Checks für den Pull-Request im aktuellen Branch. Fasse den Fehlerkontext zusammen, identifiziere die wahrscheinliche Grundursache und schlage den kleinstmöglichen sicheren Reparaturplan vor. Bearbeite keinen Code und führe keine Workflows erneut aus, bis ich den Plan ausdrücklich genehmige.“
Anstatt Code sofort zu ändern, strukturiert gh-fix-ci die Aufgabe als kontrollierten Diagnose-Workflow. Codex überprüft zuerst den fehlgeschlagenen Check und seinen verfügbaren Kontext, identifiziert die wahrscheinliche Fehlerursache und schlägt einen minimalen Reparaturplan vor. Erst nachdem der Benutzer den Plan bestätigt hat, sollte Codex die Änderung vornehmen, den entsprechenden Test ausführen und überprüfen, ob der Pull-Request-Check auf Grün wechselt.
](https://file.nanoskill.ai/gh-fix-ci-sample)
_Abbildung 3. Veranschaulichender Workflow basierend auf dem gh-fix-ci-Skill: Codex geht von einem fehlgeschlagenen GitHub Actions-Check zu einem fokussierten, überprüfbaren Reparaturplan über._
In diesem Beispiel ist das Fehlersignal klar. Codex würde diesen Fehlerkontext nutzen, um zwischen einer falschen Implementierung und einem falschen Test zu unterscheiden. Hier ist die add-Funktion, die 4 zurückgibt, korrekt. Die Grundursache ist die Testerwartung, die fälschlicherweise ein Ergebnis von 5 erwartet.
Der resultierende Reparaturplan ist bewusst minimal:
1. Ändere den erwarteten Wert im Test von 5 auf 4.
2. Führe den entsprechenden Test lokal aus.
3. Pushe die genehmigte Änderung und überprüfe den Pull-Request-Status erneut.
Der wichtigste Schritt ist die**Genehmigungshürde**. gh-fix-ci ist nicht dafür konzipiert, jeden fehlgeschlagenen Check als Erlaubnis zu betrachten, Code automatisch zu bearbeiten. Es trennt die Diagnose von der Implementierung: Codex erläutert das wahrscheinliche Problem, präsentiert einen fokussierten Reparaturplan und wartet auf die ausdrückliche Genehmigung des Benutzers, bevor es den Branch modifiziert.
Nach der Genehmigung ist der erwartete Endzustand einfach: Der korrigierte Test besteht lokal und der Pull-Request-Check wird grün.
Dieser Workflow ist nützlich, weil er die CI-Reparatur transparenter und weniger reaktiv macht. Anstatt Codex zu bitten, „den Fehler zu beheben“ und auf das Beste zu hoffen, können Entwickler die Fehleranalyse überprüfen, den vorgeschlagenen Änderungsumfang bestätigen und eine klare Aufzeichnung darüber führen, wie das Problem gelöst wurde.
**Warum dieser Workflow wichtig ist:**
gh-fix-ci ist besonders wertvoll für Teams, die GitHub Actions als Teil ihres Pull-Request-Workflows verwenden. Es hilft Codex, einen fehlgeschlagenen Check in eine strukturierte Abfolge von Diagnose, Genehmigung, Implementierung und Verifizierung zu verwandeln – und nicht in einen Black-Box-Versuch, den CI-Status zu bestehen.
### **Workflow 3: Testen und Verifizieren eines defekten Anmeldeablaufs in einem Browser**
**Szenario:**
Eine Anmeldeseite kann beim Code-Review korrekt aussehen und dennoch im entscheidenden Moment versagen: wenn ein echter Benutzer versucht, den Ablauf abzuschließen. Ein Formular kann Eingaben annehmen, eine Schaltfläche kann anklickbar erscheinen, und das Frontend zeigt möglicherweise keinen offensichtlichen Fehler an – dennoch erscheint der erwartete Bestätigungsstatus nach dem Absenden möglicherweise nie.
In diesem veranschaulichenden Szenario öffnet ein Benutzer eine Anmeldeseite für einen Arbeitsbereich, gibt einen vollständigen Namen, eine geschäftliche E-Mail und einen Arbeitsbereichsnamen ein und klickt dann auf**Arbeitsbereich erstellen**. Das erwartete Ergebnis ist eine sichtbare Bestätigungsmeldung:**„Arbeitsbereich erstellt.“**Stattdessen scheint der Ablauf abgesendet zu werden, zeigt aber keinen Bestätigungsstatus an.
**Verwendeter Workflow:**
Playwright-gestütztes Browser-Testing
**Beispiel-Prompt:**
„Öffne den Anmeldeablauf für den Arbeitsbereich in einem Browser, fülle das Formular mit gültigen Daten aus, klicke auf 'Arbeitsbereich erstellen' und überprüfe, dass eine sichtbare Bestätigungsmeldung erscheint. Wenn der Ablauf fehlschlägt, erfasse die relevanten Browser-Beweise, identifiziere die wahrscheinliche Ursache und schlage die kleinste sichere Korrektur vor, bevor du Code bearbeitest.“
Im Gegensatz zu einer reinen Code-Überprüfung testet das Browser-Testing, was ein Benutzer tatsächlich erlebt. Der Workflow beginnt damit, den Pfad vom Seitenaufbau bis zur Formularübermittlung nachzustellen, und vergleicht dann das sichtbare Ergebnis mit dem erwarteten benutzerseitigen Ergebnis.
](https://file.nanoskill.ai/playwright-sample)
_Abbildung 4. Veranschaulichender Playwright-gestützter Workflow: Codex geht von einem fehlerhaften Anmeldeablauf zu Browser-Evidenz, Genehmigung und einem verifizierten Benutzerfluss-Ergebnis über._
Der anfängliche Fehler ist keine vage „Etwas ist schiefgelaufen“-Meldung. Der Browser-Test hat eine klare, benutzerseitige Erwartung: Nachdem der Benutzer gültige Anmeldedaten übermittelt hat, sollte die Seite die Bestätigungsmeldung anzeigen „**„Arbeitsbereich erstellt.“**
Stattdessen ist das beobachtete Ergebnis, dass nach der Übermittlung kein Bestätigungszustand erscheint. Das gibt Codex eine spezifische Fehlerbedingung zur Untersuchung, anstatt einer allgemeinen Anweisung, die „Anmeldeseite zu reparieren“.
Dieser Unterschied ist wichtig. Das Problem ist nicht unbedingt, dass die Formularfelder kaputt sind oder dass die Benutzerdaten ungültig sind. Stattdessen deutet der Workflow darauf hin, dass die Anwendung gültige Eingaben akzeptiert, aber nach der Übermittlung keinen Erfolgszustand darstellt.
Von dort aus kann Codex die Untersuchung in eine kontrollierte Abfolge strukturieren: den Browserzustand inspizieren, die Fehlerevidenz überprüfen, das wahrscheinlich fehlende UI-Verhalten identifizieren und einen minimalen Reparaturplan vorschlagen. In diesem Fall ist die vorgeschlagene Lösung bewusst eng gefasst: eine sichtbare „**„Arbeitsbereich erstellt“**Bestätigungszustand nach gültiger Formularübermittlung darzustellen, während das bestehende Seitenlayout und das Validierungsverhalten unverändert bleiben.
](https://file.nanoskill.ai/playwright-sample2)
_Abbildung 5. Der sechsstufige Browser-Testing-Workflow: Den Ablauf öffnen, das Problem reproduzieren, Browser-Evidenz inspizieren, eine Lösung vorschlagen, Genehmigung einholen und den erwarteten Endzustand überprüfen._
Der entscheidende Schritt ist die Genehmigungsschranke. Browser-Testing sollte nicht automatisch zu unkontrolliertem Code-Editing werden. Codex kann den Fehler identifizieren und die kleinste Änderung empfehlen, sollte aber auf die Benutzergenehmigung warten, bevor die Implementierung geändert wird.
Nachdem die genehmigte Korrektur angewendet wurde, ist der erwartete Endzustand klar: Der Anmeldeablauf zeigt die Bestätigungsmeldung an, und der Browser-Test gibt ein bestandenes Ergebnis zurück. Dies schafft eine zuverlässigere Entwicklungsschleife, als einfach einen Agenten aufzufordern, die „Anmeldeseite zu reparieren“, ohne Beweise dafür, was fehlgeschlagen ist, oder Bestätigung, dass der Benutzerfluss jetzt funktioniert.
Dieses Beispiel ist ein veranschaulichender Workflow, der auf Playwright-artigem Browser-Testing basiert. Es repräsentiert keine Produktionsanwendung oder einen abgeschlossenen Live-Testlauf.
**Warum dieser Workflow wichtig ist:**
Playwright-gestützte Workflows sind besonders wertvoll für Frontend-Teams, SaaS-Produkte und jedes Projekt, bei dem die sichtbare Benutzererfahrung genauso wichtig ist wie der Code selbst. Sie helfen Codex, echte Interaktionen zu validieren – wie Klicks, Formularübermittlungen, Navigation und Bestätigungszustände – anstatt sich nur auf statische Code-Inspektion zu verlassen. Das Ergebnis ist ein Workflow, der Implementierungsentscheidungen mit dem verbindet, was Benutzer tatsächlich im Browser sehen und tun.
## **Häufig gestellte Fragen zu Codex-Fähigkeiten**
### **Was sind Codex-Fähigkeiten?**
Codex-Fähigkeiten sind wiederverwendbare Workflows, die Codex helfen, eine bestimmte Art von Aufgabe konsistenter zu bewältigen. Eine Fähigkeit kann Anweisungen, optionale Skripte, Referenzmaterialien und Assets enthalten, die Codex durch einen wiederholbaren Prozess führen.
Zum Beispiel kann eine Fähigkeit Codex helfen, fehlgeschlagene CI-Prüfungen zu untersuchen, während eine andere helfen kann, eine vage Produktanfrage in ein messbares Ziel umzuwandeln. Anstatt in jeder neuen Konversation denselben langen Prompt zu wiederholen, können Sie eine Fähigkeit verwenden, um den Workflow, das bevorzugte Ausgabeformat und wichtige Regeln beizubehalten.
### **Wie installiere ich eine Codex-Fähigkeit?**
Öffnen Sie für kuratierte Fähigkeiten Codex und verwenden Sie den integrierten Installer.
Zum Beispiel können Sie eingeben:
**$fähigkeiten-installierer gh-beheben-ci**
Codex kann dann die ausgewählte Fähigkeit in Ihr lokales Setup installieren. Wenn die Fähigkeit nicht sofort nach der Installation erscheint, starten Sie Codex neu und versuchen Sie, sie erneut aufzurufen.
Sie können den Installer auch bitten, Ihnen bei der Entdeckung relevanter Fähigkeiten zu helfen. Zum Beispiel:
**$fähigkeiten-installierer**
**Empfehlen Sie Fähigkeiten für Browser-Testing und GitHub-Workflows.**
Nach der Installation können Sie einen Skill explizit aufrufen, indem Sie seinen Namen mit einem Dollarzeichen eingeben, wie z. B.**$gh-fix-ci**oder**$define-goal**.
### **Kann ich meinen eigenen Codex Skill erstellen?**
Ja. Tatsächlich sind benutzerdefinierte Skills oft wertvoller als eine große Sammlung generischer Skills.
Ein nützlicher benutzerdefinierter Skill beginnt normalerweise mit einem Workflow, den Sie bereits wiederholen. Das kann eine Release-Checkliste, ein Code-Review-Format, eine Browser-QA-Routine, ein Dokumentationsprozess oder eine interne Berichtsaufgabe sein.
Codex enthält einen Skill-Creator-Workflow, der helfen kann, einen nützlichen Thread, ein Dokument, ein Skript, eine Checkliste oder eine Beispielausgabe in einen wiederverwendbaren Skill umzuwandeln. Ein benutzerdefinierter Skill beginnt normalerweise mit einer erforderlichen`SKILL.md`-Datei und kann optionale Referenzen, Skripte oder Vorlagen enthalten.
Die beste Zeit, um einen Skill zu erstellen, ist, nachdem Sie eine Aufgabe einmal abgeschlossen haben und genau wissen, wie ein gutes Ergebnis aussehen sollte.
### **Was ist der Unterschied zwischen einem Codex Skill und AGENTS.md?**
Eine`AGENTS.md`-Datei enthält persistente Projektanweisungen. Sie teilt Codex mit, wie es sich verhalten soll, wenn es in einem bestimmten Repository oder Ordner arbeitet.
Zum Beispiel könnte eine`AGENTS.md`-Datei sagen:
- Führen Sie die Testsuite aus, bevor Sie einen Pull-Request eröffnen.
- Fügen Sie keine neuen Abhängigkeiten ohne Genehmigung hinzu.
- Folgen Sie der bestehenden Komponentenbibliothek.
- Dokumentieren Sie öffentliche API-Änderungen.
Ein Skill ist anders. Es ist ein wiederverwendbarer Workflow für eine bestimmte Art von Aufgabe.
Zum Beispiel:
- Verwenden Sie gh-fix-ci, wenn eine GitHub Actions-Prüfung fehlschlägt.
- Verwenden Sie einen Browser-Testing-Skill, wenn Sie einen Anmeldeablauf validieren.
- Verwenden Sie einen Dokumentations-Skill, wenn Sie Release-Notes vorbereiten.
Eine einfache Möglichkeit, sich den Unterschied zu merken, ist:
### **AGENTS.md definiert die ständigen Regeln. Skills definieren wiederholbare Aufgaben.**
### **Welchen Codex Skill sollten Anfänger zuerst ausprobieren?**
Beginnen Sie mit dem Skill, der das am häufigsten wiederholte Problem in Ihrem aktuellen Workflow löst.
Wenn Ihre Aufgaben häufig mit unklaren Anforderungen beginnen, beginnen Sie mit**Ziel definieren**. Es hilft, allgemeine Anfragen in messbare Ergebnisse, Umfangsgrenzen und Überprüfungskriterien umzuwandeln.
Wenn Sie viel Zeit mit GitHub Pull-Requests verbringen, versuchen Sie**gh-fix-ci**oder**gh-address-comments**.
Wenn Sie Webprodukte entwickeln, sind Browser-Testing-Workflows wie**Playwright**sind nützlich, weil sie helfen zu validieren, was Benutzer tatsächlich sehen und tun.
Wenn Sie mit OpenAI-APIs oder -Modellen arbeiten,**OpenAI Docs**kann Codex helfen, sich auf aktuelle Erstanbieter-Dokumentation anstatt auf veraltete Beispiele zu stützen.
Der beste erste Skill ist normalerweise nicht der fortschrittlichste. Es ist der, der eine wiederholte Reibungsquelle aus Ihrer Arbeit entfernt.
### **Sind Codex Skills sicher zu installieren?**
Skills sollten wie jedes andere wiederverwendbare Automatisierungs- oder Entwicklerwerkzeug behandelt werden: Installieren Sie sie aus vertrauenswürdigen Quellen, prüfen Sie, wofür sie entwickelt wurden, und verstehen Sie, welchen Zugriff sie benötigen.
Bevor Sie einen Skill in einem echten Projekt verwenden, prüfen Sie, ob er Folgendes kann:
- Befehle in Ihrer lokalen Umgebung ausführen
- Auf externe Tools oder verbundene Dienste zugreifen
- Dateien ändern
- Commits oder Pull-Requests erstellen
- Deployments auslösen
- Projektdokumentation oder geheimnisbezogene Konfiguration lesen
Für risikoarmes Experimentieren beginnen Sie in einem separaten Demo-Ordner oder Test-Repository. Wenn ein Skill eine bedeutende Änderung vorschlägt, überprüfen Sie den Plan, bevor Sie Dateibearbeitungen, Codeänderungen, Commits oder Deployments genehmigen.