Payload CMS Skills helfen einem Coding-Agenten bei Konfiguration, Collections, Feldern, Hooks, Zugriffskontrolle und APIs von Payload. Payload veröffentlicht dafür einen Skill zur Anwendungsentwicklung mit ergänzenden Referenzen. Stelle zuerst fest, welche Version dein Projekt verwendet. Nutze den Skill dann für eine kleine Änderung, die du prüfen kannst.
Das angestrebte Ergebnis ist ein Inhaltsmodell mit Verhalten, das zu deiner Anwendung passt. Eine erzeugte Collection-Datei ist nur ein Teil davon. Redakteure brauchen die richtigen Felder und Berechtigungen, das Frontend braucht das vorgesehene Abfrageverhalten, und bestehende Daten müssen möglicherweise migriert werden.
Den Entwicklungsskill des Herausgebers installieren
Die Thrive-Seite zum Payload CMS Skill nennt die geprüfte Originalquelle und ihre festgelegte Revision. Führe in deinem Projekt Folgendes aus:
npx usethrive add payload-cms --agent claudeVerwende --agent codex für ein Codex-Projekt. Der Installer lädt den vollständigen Skill-Ordner einschließlich seiner Referenzdokumente herunter. Damit installierst du Anleitungen für den Agenten, aber weder Payload noch eine Datenbankkonfiguration oder eine Migration.
Der Katalogeintrag ist an eine Revision des Payload-Repositorys gebunden. Der main-Branch des Herausgebers kann von der Version deiner Anwendung abweichen. Prüfe package.json und die Lockdatei, bevor du ein API-Beispiel kopierst. Lass den Agenten die installierte Hauptversion bestimmen und prüfen, ob die relevante Dokumentation dazu passt.
Lies bei einer bestehenden Anwendung auch die Datei payload.config des Projekts, die Collection-Definitionen, den Datenbankadapter sowie die Konventionen für Hooks und Zugriffskontrolle. Ein allgemeines Beispiel sollte diese Entscheidungen nicht unbemerkt ersetzen.
Die Aufgabe am Inhaltsmodell klar begrenzen
Angenommen, du möchtest eine Posts-Collection mit Titel, Zusammenfassung und einem einfachen Veröffentlichungsstatus. Lege vor dem Anlegen der Felder fest, was Redakteure tun und anonyme Besucher lesen dürfen. So könnte eine beispielhafte Vorgabe aussehen:
Beispielhafte Collection-Konfiguration und Editoransicht; prüfe Felder und API-Muster anhand deiner installierten Payload-Version. Illustration in voller Größe öffnen.
Anforderung | Gewünschtes Verhalten | Prüfung |
|---|---|---|
Titel | Pflichtfeld für Text | Ein leerer Titel wird abgelehnt |
Zusammenfassung | Optionaler Kurztext | Bestehende Beiträge ohne Zusammenfassung bleiben gültig |
Veröffentlichungsstatus | Festgelegte Wertemenge | Unbekannte Werte werden abgelehnt |
Öffentlicher Lesezugriff | Nur freigegebene öffentliche Beiträge | Anonyme Antworten enthalten keine Entwurfsdaten |
Bearbeitung | Nur berechtigte Redakteure | Unberechtigte Schreibzugriffe werden abgelehnt |
Diese Tabelle beschreibt ein Beispiel, nicht das Verhalten einer fertigen Anwendung. Wenn dein Projekt die Entwurfs- und Versionsfunktionen von Payload verwendet, nutze sie bewusst. Lege kein zweites Statusfeld an, das ihnen widerspricht. Kläre vor der Wahl des Modells, wie dein Frontend Entwürfe und veröffentlichte Inhalte abfragt.
Beginne mit einer Collection und einem repräsentativen Arbeitsablauf für Redakteure. Prüfe, ob jedes Feld in diese Collection oder in ein verknüpftes Dokument gehört. Ein wiederverwendbarer Autorendatensatz kann etwa eine Beziehung statt wiederholter Namensfelder sein, wenn das Produkt gemeinsam genutzte Autoreninformationen braucht.
Die passende Referenz zum Problem lesen
Der Entwicklungsskill von Payload enthält getrennte Referenzen, damit der Agent die für seine Aufgabe nötigen Details nachschlagen kann. Bei Feldänderungen braucht er Hinweise zu Feldern und Collections. Bei Berechtigungsproblemen braucht er Hinweise zu Zugriffskontrolle und Abfragen. Bei einem Hook, der einen weiteren Datensatz schreibt, braucht er Hinweise zu Hooks und Transaktionsverhalten.
Problem | Zu prüfender Referenzbereich |
|---|---|
Die Validierung eines Feldes verhält sich unerwartet | Felder und Collections |
Ein Nutzer sieht Dokumente, die er nicht sehen sollte | Zugriffskontrolle für Collections oder Felder |
Ein Local-API-Aufruf umgeht eine Einschränkung | Abfragen und Local-API-Optionen |
Ein Hook wiederholt sich oder verliert den Transaktionskontext | Hooks und Weitergabe des Requests |
Das Datenbankverhalten unterscheidet sich zwischen Umgebungen | Adapter und Migrationskonfiguration |
Frage nach der konkreten Quellpassage hinter einer folgenreichen API-Entscheidung. Das ist nützlicher als die Bitte, „alle Best Practices“ einzuhalten, denn damit benennst du das benötigte Verhalten nicht.
Die Zugriffskontrolle über die verwendete API prüfen
Die Dokumentation zur Zugriffskontrolle von Payload erklärt Einschränkungen nach Operation und nach Collection, Global oder Feld. Teste den tatsächlichen Einstiegspunkt deiner Anwendung. Eine ausgeblendete Schaltfläche im Admin-Panel ersetzt keine Berechtigungsprüfung in der API.
Für Local-API-Operationen, die die Berechtigungen eines Nutzers berücksichtigen sollen, dokumentiert Payload user und overrideAccess: false als Optionen. Eine Abfrage kann so aussehen:
const visiblePosts = await payload.find({
collection: 'posts',
user: requestingUser,
overrideAccess: false,
limit: 10,
})Das ist ein Integrationsausschnitt, kein eigenständig ausführbares Programm. Er setzt eine initialisierte payload Instanz, eine deklarierte posts Collection und einen Nutzer voraus, den der Authentifizierungsablauf deiner Anwendung ermittelt hat. Prüfe diese Voraussetzungen und die installierte Version, bevor du den Ausschnitt übernimmst.
Teste einen berechtigten Nutzer, einen unberechtigten Nutzer und bei öffentlichen Operationen auch eine anonyme Anfrage. Prüfe bei Schreibzugriffen sowohl die Antwort als auch die anschließend gespeicherten Daten. Eine erfolgreiche Abfrage durch einen Administrator beweist nicht, dass Besucher keine Entwürfe lesen können.
Hooks und Migrationen als Verhaltensänderungen behandeln
Ein Hook kann das ursprüngliche Dokument ändern oder weitere Schreibvorgänge auslösen. Beschreibe, wann er laufen soll, was er ändert und wie er sich bei wiederholten Aufrufen verhält. Wenn die Dokumentation des Herausgebers verlangt, den Request-Kontext an eine weitere Operation zu übergeben, behalte ihn bei. So nutzt die zusammengehörige Verarbeitung die vorgesehene Transaktion.
Überlege bei einem Beispiel wie der Erzeugung eines Slugs aus einem Titel, ob eine Titeländerung auch eine bestehende öffentliche URL ändern soll. Ein neu erzeugter Wert kann im Editor korrekt aussehen und trotzdem eingehende Links unbrauchbar machen. Wähle das Verhalten, das dein Produkt braucht, und prüfe anschließend einen neuen und einen bestehenden Datensatz.
Eine Schemaänderung kann auch eine Datenbankmigration erfordern. Lass den Agenten die relevante Migration nach dem dokumentierten Ablauf deines Adapters erzeugen und prüfen. Teste sie vor einer Produktionsänderung mit repräsentativen Daten. Halte fest, wie fehlende Felder und bestehende Werte behandelt werden. Eine Typprüfung deckt die gespeicherten Datensätze nicht automatisch ab.
Redakteuren eine kurze Abnahmeprüfung geben
Öffne die Collection im Admin-Panel und durchlaufe den vorgesehenen Ablauf: erstellen, bearbeiten, gegebenenfalls als Entwurf speichern und mit den freigegebenen Berechtigungen veröffentlichen. Prüfe Beschriftungen und Validierungsmeldungen mit den Menschen, die sie verwenden. Frage anschließend die öffentlichen Inhalte über den tatsächlichen API-Pfad des Frontends ab.
Protokolliere die geprüften Befehle und Ergebnisse. Wenn keine Datenbank oder kein Testkonto verfügbar war, benenne das weiterhin ungeprüfte Verhalten. Bezeichne eine Anwendung nicht als sicher, nur weil die Konfiguration kompiliert.
Bei einer Migration über mehrere Sitzungen hinweg hält der Planning with Files Skill Feldzuordnungen, Entscheidungen und Testergebnisse zusammen. Nutze den Plan, um Belege festzuhalten; nutze Tests und Laufzeitprüfungen von Payload, um das Verhalten der Anwendung nachzuweisen.
