Skills Payload CMS : installer le skill et créer une collection

Les skills Payload CMS aident un agent de développement à travailler sur la configuration, les collections, les champs, les hooks, le contrôle d’accès et les API de Payload. Payload publie un skill de développement d’applications et des références pour ces tâches. Commencez par identifier la version de votre projet, puis utilisez le skill pour effectuer une petite modification vérifiable.

Le résultat attendu est un modèle de contenu et un comportement adaptés à votre application. Un fichier de collection généré n’en est qu’une partie. Les éditeurs ont besoin des bons champs et des bonnes permissions, le frontend doit obtenir les résultats de requête prévus, et les données existantes peuvent nécessiter une migration.

Installer le skill de développement de l’éditeur

La page du skill Thrive Payload CMS indique la source de l’éditeur examinée et sa révision épinglée. Dans votre projet, exécutez :

npx usethrive add payload-cms --agent claude

Utilisez --agent codex pour un projet Codex. Le programme d’installation récupère le dossier complet du skill, y compris ses documents de référence. Il installe des instructions pour l’agent ; il n’installe pas Payload, ne configure pas de base de données et n’applique pas de migration.

L’entrée du catalogue est épinglée à une révision du dépôt Payload. La branche main de l’éditeur peut différer de la version de votre application. Vérifiez package.json et le fichier de verrouillage avant de copier un exemple d’API. Demandez à l’agent d’identifier la version majeure installée et de vérifier que la documentation utilisée lui correspond.

Pour une application existante, lisez aussi le fichier payload.config du projet, les définitions des collections, l’adaptateur de base de données et les conventions relatives aux hooks et au contrôle d’accès. Un exemple générique ne doit pas remplacer silencieusement ces choix.

Définir une tâche de modélisation au périmètre précis

Supposons que vous souhaitiez une collection Posts avec un titre, un résumé et un état de publication simple. Définissez ce que les éditeurs peuvent faire et ce que les visiteurs anonymes peuvent lire avant d’écrire les champs. Voici un exemple de contrat :

Exemple de configuration de collection et de disposition de l’éditeur ; vérifiez les champs et les exemples d’API par rapport à votre version de Payload. Ouvrir l’illustration en pleine taille.

Ce tableau décrit un exemple, pas le comportement d’une application terminée. Si votre projet utilise les brouillons et les versions de Payload, utilisez ces fonctions de manière réfléchie plutôt que de créer un second champ d’état qui les contredit. Déterminez comment le frontend interroge les brouillons et les contenus publiés avant de choisir le modèle.

Commencez par une collection et un parcours d’édition représentatif. Vérifiez si chaque champ appartient à cette collection ou à un document lié. Une fiche d’auteur réutilisable, par exemple, peut prendre la forme d’une relation plutôt que de champs de nom répétés si le produit a besoin d’informations communes sur les auteurs.

Consulter la référence adaptée au problème

Le skill de développement Payload contient des références séparées pour que l’agent consulte les détails utiles à la tâche. Modifier un champ demande les recommandations sur les champs et les collections. Un problème de permissions demande celles sur le contrôle d’accès et les requêtes. Un hook qui écrit un autre enregistrement demande celles sur les hooks et le comportement des transactions.

Demandez le passage source précis qui justifie un choix d’API susceptible d’avoir des conséquences. C’est plus utile que de demander à l’agent de suivre « toutes les bonnes pratiques », sans préciser le comportement attendu.

Vérifier le contrôle d’accès via l’API utilisée

La documentation Payload sur le contrôle d’accès explique les restrictions par opération et par collection, global ou champ. Testez le point d’entrée réellement utilisé par votre application. Masquer un bouton dans le panneau d’administration ne remplace pas une vérification des permissions dans l’API.

Pour les opérations Local API qui doivent respecter les permissions d’un utilisateur, Payload documente les options user et overrideAccess: false. Une requête peut prendre cette forme :

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

Ce fragment d’intégration n’est pas un programme autonome exécutable. Il suppose une instance payload initialisée, une collection posts déclarée et un utilisateur identifié par le processus d’authentification de votre application. Vérifiez ces conditions et la version installée avant de l’appliquer.

Testez un utilisateur autorisé, un utilisateur non autorisé et une requête anonyme si l’opération est publique. Pour les écritures, vérifiez la réponse et les données effectivement enregistrées. Une requête réussie avec un compte administrateur ne prouve pas qu’un visiteur ne peut pas lire les brouillons.

Traiter les hooks et migrations comme des changements de comportement

Un hook peut modifier le document d’origine ou déclencher d’autres écritures. Décrivez quand il doit s’exécuter, ce qu’il change et son comportement lors d’appels répétés. Si la documentation de l’éditeur exige de transmettre le contexte de requête à une autre opération, conservez ce contexte pour que les opérations liées utilisent la transaction prévue.

Pour un exemple tel que la génération d’un slug à partir d’un titre, déterminez si modifier le titre doit changer une URL publique existante. Une valeur nouvellement générée peut sembler correcte dans l’éditeur tout en cassant les liens entrants. Choisissez le comportement adapté au produit, puis vérifiez un nouvel enregistrement et un enregistrement existant.

Une modification du schéma peut aussi nécessiter une migration de base de données. Faites générer et examiner la migration concernée par l’agent selon la procédure documentée de votre adaptateur. Testez-la sur des données représentatives avant toute modification en production. Consignez le traitement des champs manquants et des valeurs existantes, sans supposer qu’une vérification des types couvre les enregistrements stockés.

Prévoir un court contrôle de recette pour les éditeurs

Ouvrez la collection dans le panneau d’administration et suivez le parcours prévu : créer, modifier, enregistrer un brouillon si cette fonction existe, puis publier avec les permissions approuvées. Vérifiez les libellés et les messages de validation avec les personnes qui les utilisent. Interrogez ensuite le contenu public via le véritable point d’accès API du frontend.

Consignez les commandes exécutées et leurs résultats. Si aucune base de données ni aucun compte de test n’était disponible, précisez quels comportements restent à vérifier. Ne qualifiez pas une application de sûre parce que sa configuration compile.

Pour une migration sur plusieurs sessions, le skill Planning with Files peut regrouper les correspondances de champs, les décisions et les résultats de test. Utilisez le plan pour suivre les éléments probants, et les tests Payload et contrôles à l’exécution pour établir le comportement de l’application.

Sources

• Skill de développement Payload épinglé et références

• Contrôle d’accès Payload

• Local API Payload

• Hooks Payload