Las skills de Payload CMS ayudan a un agente de programación a trabajar con la configuración, las colecciones, los campos, los hooks, el control de acceso y las API de Payload. Payload publica una skill de desarrollo de aplicaciones con referencias de apoyo para esas tareas. Empieza por identificar la versión de tu proyecto y utiliza después la skill para realizar un cambio pequeño que puedas verificar.
El resultado útil es un modelo de contenido y un comportamiento adecuados para tu aplicación. Un archivo de colección generado solo es una parte de ese resultado. Los editores necesitan los campos y los permisos correctos, tu frontend necesita el comportamiento de consulta previsto y los datos existentes pueden requerir una migración.
Instala la skill de desarrollo del editor
La página de la skill Payload CMS en Thrive recoge la fuente del editor revisada y su revisión fijada. En tu proyecto, ejecuta:
npx usethrive add payload-cms --agent claudeUsa --agent codex para un proyecto de Codex. El instalador recupera la carpeta completa de la skill, incluidos sus documentos de referencia. Esto instala pautas para el agente; no instala Payload, configura una base de datos ni aplica una migración.
La entrada del catálogo está fijada a una revisión del repositorio de Payload. La rama main del editor puede diferir de la versión de tu aplicación. Comprueba package.json y el archivo de bloqueo antes de copiar un ejemplo de API. Pide al agente que identifique la versión principal instalada y compruebe que la documentación correspondiente coincide con ella.
Para una aplicación existente, lee también el archivo payload.config del proyecto, las definiciones de colecciones, el adaptador de base de datos y las convenciones sobre hooks y control de acceso. Un ejemplo genérico no debe sustituir esas decisiones sin indicarlo.
Asigna al agente una tarea de modelado de contenido acotada
Supongamos que quieres una colección Posts con un título, un resumen y un estado de publicación sencillo. Define qué pueden hacer los editores y qué pueden leer los visitantes anónimos antes de escribir los campos. Este es un ejemplo de contrato:
Configuración de colección y disposición del editor a modo de ejemplo; contrasta los campos y los patrones de API con tu versión de Payload instalada. Abre la ilustración a tamaño completo.
Requisito | Comportamiento previsto | Comprobación |
|---|---|---|
Título | Texto obligatorio | Se rechaza un título vacío |
Resumen | Texto breve opcional | Las publicaciones existentes sin este campo siguen siendo válidas |
Estado de publicación | Un conjunto declarado de valores | Se rechazan los valores desconocidos |
Lectura pública | Solo publicaciones públicas aprobadas | Las respuestas anónimas no contienen datos de borradores |
Edición | Solo editores autorizados | Se deniegan las escrituras no autorizadas |
Esta tabla describe un ejemplo, no el comportamiento de una aplicación terminada. Si tu proyecto usa los borradores y las versiones de Payload, utiliza esas funciones de forma deliberada en lugar de crear un segundo campo de estado que entre en conflicto con ellas. Determina cómo consulta tu frontend el contenido en borrador y el publicado antes de elegir el modelo.
Empieza con una colección y un flujo de edición representativo. Revisa si cada campo pertenece a esa colección o a un documento relacionado. Por ejemplo, un registro de autor reutilizable puede ser una relación, en lugar de campos de nombre repetidos, si el producto necesita información compartida sobre autores.
Consulta la referencia adecuada para el problema
La skill de desarrollo de Payload contiene referencias separadas para que el agente consulte los detalles pertinentes para la tarea. Un cambio de campo requiere pautas sobre campos y colecciones. Un problema de permisos requiere pautas sobre control de acceso y consultas. Un hook que escribe otro registro requiere información sobre hooks y el comportamiento de las transacciones.
Problema | Área de referencia que consultar |
|---|---|
Un campo se valida de forma inesperada | Campos y colecciones |
Un usuario puede ver documentos que no le corresponden | Control de acceso a colecciones o campos |
Una llamada a la Local API elude una restricción | Consultas y opciones de la Local API |
Un hook se repite o pierde el contexto de la transacción | Hooks y propagación de la petición |
El comportamiento de la base de datos cambia entre entornos | Adaptadores y configuración de migraciones |
Pide el pasaje concreto de la fuente que respalda una elección de API con consecuencias relevantes. Es más útil que pedir al agente que siga «todas las buenas prácticas», sin identificar el comportamiento que necesitas.
Verifica el control de acceso mediante la API que utilizas
La documentación de control de acceso de Payload explica las restricciones por operación y por colección, configuración global o campo. Prueba el punto de entrada que usa tu aplicación. Ocultar un botón en el panel de administración no sustituye una comprobación de permisos en la API.
Para las operaciones de la Local API que deben respetar los permisos del usuario, Payload documenta las opciones user y overrideAccess: false opciones. Una consulta puede tener esta forma:
const visiblePosts = await payload.find({
collection: 'posts',
user: requestingUser,
overrideAccess: false,
limit: 10,
})Esto es un fragmento de integración, no un programa independiente ejecutable. Presupone una instancia payload inicializada, una colección posts declarada y un usuario identificado mediante el flujo de autenticación de tu aplicación. Comprueba esos supuestos y la versión instalada antes de aplicarlo.
Prueba un usuario autorizado, uno no autorizado y una petición anónima si la operación es pública. Para las escrituras, confirma tanto la respuesta como los datos finalmente guardados. Una consulta exitosa de un administrador no demuestra que un visitante no pueda leer borradores.
Trata los hooks y las migraciones como cambios de comportamiento
Un hook puede modificar el documento original o provocar otras escrituras. Describe cuándo debe ejecutarse, qué cambia y cómo se comporta si se llama repetidamente. Cuando la documentación del editor exige pasar el contexto de la petición a otra operación, consérvalo para que el trabajo relacionado utilice la transacción prevista.
En un ejemplo como generar un slug a partir de un título, considera si editar el título debe cambiar una URL pública existente. Un valor recién generado puede parecer correcto en el editor y romper enlaces entrantes. Elige el comportamiento que necesita tu producto y comprueba después un registro nuevo y uno existente.
Un cambio de esquema también puede requerir una migración de base de datos. Pide al agente que genere y revise la migración correspondiente siguiendo el procedimiento documentado de tu adaptador. Pruébala con datos representativos antes de realizar un cambio en producción. Registra cómo se gestionan los campos ausentes y los valores existentes en lugar de asumir que la comprobación de tipos cubre los registros almacenados.
Ofrece a los editores una pequeña prueba de aceptación
Abre la colección en el panel de administración y completa el flujo previsto: crear, editar, guardar un borrador si se admite y publicar con los permisos aprobados. Comprueba las etiquetas y los mensajes de validación con quienes los utilizan. Después, consulta el contenido público mediante la ruta de API que usa el frontend.
Registra los comandos y resultados comprobados. Si no había una base de datos o una cuenta de prueba disponibles, indica qué comportamiento sigue sin verificarse. No describas una aplicación como segura porque su configuración compile.
Para una migración que ocupe varias sesiones, la skill Planning with Files puede mantener juntas las correspondencias de campos, las decisiones y los resultados de pruebas. Usa el plan para seguir las evidencias; usa las pruebas y las comprobaciones en ejecución de Payload para determinar el comportamiento de la aplicación.
