Skill Payload CMS: installa la skill per agenti e crea una collezione

Le skill Payload CMS aiutano un agente di programmazione a lavorare su configurazione, collezioni, campi, hook, controllo degli accessi e API di Payload. Payload pubblica una skill per lo sviluppo di applicazioni con riferimenti di supporto per queste attività. Prima identifica la versione del progetto, poi usa la skill per apportare una piccola modifica verificabile.

Il risultato utile è un modello di contenuto con un comportamento adatto alla tua applicazione. Un file di collezione generato è solo una parte del risultato. Chi gestisce i contenuti ha bisogno dei campi e dei permessi corretti, il frontend deve eseguire le query nel modo previsto e i dati esistenti potrebbero richiedere una migrazione.

Installa la skill di sviluppo dell'autore

La pagina Thrive della skill Payload CMS riporta la fonte dell'autore verificata e la revisione a cui fa riferimento. Nel progetto, esegui:

npx usethrive add payload-cms --agent claude

Usa --agent codex per un progetto Codex. L'installer recupera la cartella completa della skill, compresi i documenti di riferimento. Installa istruzioni per l'agente: non installa Payload, non configura un database e non applica migrazioni.

La voce del catalogo fa riferimento a una revisione specifica del repository Payload. Il ramo main dell'autore può differire dalla versione della tua applicazione. Controlla package.json e il lockfile prima di copiare un esempio di API. Chiedi all'agente di identificare la versione principale installata e di verificare che la documentazione pertinente corrisponda.

Per un'applicazione esistente, leggi anche il file payload.config del progetto, le definizioni delle collezioni, l'adattatore del database e le convenzioni per hook e controllo degli accessi. Un esempio generico non deve sostituire queste scelte senza segnalarlo.

Assegna all'agente un compito circoscritto sul modello di contenuto

Supponiamo che tu voglia una collezione Posts con un titolo, un riassunto e un semplice stato di pubblicazione. Prima di scrivere i campi, definisci che cosa può fare chi gestisce i contenuti e che cosa possono leggere i visitatori anonimi. Ecco un esempio di requisiti:

Esempio fittizio di configurazione di una collezione e layout dell'editor: verifica campi ed esempi API sulla versione di Payload installata. Apri l'illustrazione a dimensione intera.

Questa tabella descrive un esempio, non il comportamento di un'applicazione completa. Se il progetto usa bozze e versioni di Payload, usa queste funzioni consapevolmente, senza creare un secondo campo di stato che le contraddica. Prima di scegliere il modello, stabilisci come il frontend interroga i contenuti in bozza e quelli pubblicati.

Parti da una sola collezione e da una procedura rappresentativa per chi gestisce i contenuti. Verifica se ogni campo appartiene a quella collezione o a un documento collegato. Per esempio, se il prodotto richiede informazioni condivise sugli autori, una scheda autore riutilizzabile può essere una relazione anziché una ripetizione di campi con il nome.

Consulta il riferimento adatto al problema

La skill di sviluppo Payload contiene riferimenti separati, così l'agente può cercare i dettagli pertinenti al compito. Per cambiare un campo servono le indicazioni su campi e collezioni. Per un problema di permessi servono quelle su controllo degli accessi e query. Per un hook che scrive un altro record servono quelle sugli hook e sul comportamento delle transazioni.

Chiedi il passaggio preciso della fonte che giustifica una scelta API rilevante. Serve più di una richiesta di seguire «tutte le buone pratiche», che non chiarisce il comportamento necessario.

Verifica il controllo degli accessi tramite l'API che usi

La documentazione di Payload sul controllo degli accessi spiega le restrizioni per operazione e per collezione, global o campo. Prova il punto di accesso effettivamente usato dall'applicazione. Nascondere un pulsante nel pannello di amministrazione non sostituisce un controllo dei permessi nell'API.

Per le operazioni della Local API che devono rispettare i permessi dell'utente, Payload documenta le opzioni user e overrideAccess: false. Una query può avere questa forma:

const visiblePosts = await payload.find({
  collection: 'posts',
  user: requestingUser,
  overrideAccess: false,
  limit: 10,
})

Questo è un frammento da inserire nell'applicazione, non un programma autonomo eseguibile. Presuppone un'istanza inizializzata di payload, una collezione dichiarata chiamata posts e un utente identificato dal flusso di autenticazione dell'applicazione. Verifica questi presupposti e la versione installata prima di applicarlo.

Prova con un utente autorizzato, uno non autorizzato e una richiesta anonima se l'operazione è pubblica. Per le scritture, verifica sia la risposta sia i dati effettivamente salvati. Una query riuscita da amministratore non dimostra che un visitatore non possa leggere le bozze.

Tratta hook e migrazioni come modifiche al comportamento

Un hook può modificare il documento originale o causare altre scritture. Descrivi quando deve essere eseguito, che cosa cambia e come si comporta quando viene chiamato più volte. Se la documentazione dell'autore richiede di passare il contesto della richiesta a un'altra operazione, conservalo affinché le operazioni collegate usino la transazione prevista.

In un esempio come la generazione di uno slug dal titolo, valuta se modificare il titolo debba cambiare un URL pubblico esistente. Un valore appena generato può sembrare corretto nell'editor e rompere i link in ingresso. Scegli il comportamento richiesto dal prodotto, poi verifica sia un record nuovo sia uno esistente.

Una modifica allo schema può richiedere anche una migrazione del database. Fai generare ed esaminare all'agente la migrazione pertinente seguendo la procedura documentata per il tuo adattatore. Provala su dati rappresentativi prima di modificare la produzione. Registra come vengono gestiti campi mancanti e valori esistenti, senza presumere che il controllo dei tipi verifichi anche i record salvati.

Prepara una breve verifica di accettazione per chi gestisce i contenuti

Apri la collezione nel pannello di amministrazione e completa la procedura prevista: crea, modifica, salva una bozza se supportata e pubblica con i permessi approvati. Controlla etichette e messaggi di validazione con chi li usa. Poi interroga i contenuti pubblici tramite il percorso API effettivo del frontend.

Registra i comandi verificati e i risultati. Se non erano disponibili un database o un account di prova, indica quale comportamento resta da verificare. Non definire sicura un'applicazione solo perché la configurazione compila.

Per una migrazione distribuita su più sessioni, la skill Planning with Files può tenere insieme mappature dei campi, decisioni e risultati dei test. Usa il piano per tenere traccia delle prove; per accertare il comportamento dell'applicazione, usa i test e le verifiche in esecuzione di Payload.

Fonti

• Skill di sviluppo Payload e riferimenti alla revisione indicata

• Controllo degli accessi di Payload

• Local API di Payload

• Hook di Payload