Payload CMS application development (collections, fields, hooks, access control, Local/REST/GraphQL queries, adapters, plugins). Vendored from payloadcms/skills. Use when editing payload.config.ts, Payload collections, admin, or debugging validation, security, relationships, transactions, or hooks in this repo.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Payload CMS application development (collections, fields, hooks, access control, Local/REST/GraphQL queries, adapters, plugins). Vendored from payloadcms/skills. Use when editing payload.config.ts, Payload collections, admin, or debugging validation, security, relationships, transactions, or hooks in this repo.
Payload is a Next.js native CMS with TypeScript-first architecture, providing admin panel, database management, REST/GraphQL APIs, authentication, and file storage.
Triggers
Use this skill when work touches Payload CMS application behavior in this repo,
including:
apps/admin/payload.config.ts, Payload collections, globals, fields, hooks,
access control, admin routes, Local API usage, REST/GraphQL access, adapters,
or plugins.
Web Studio or CMS work under apps/admin/app/(payload)/**,
apps/admin/src/cms/**, apps/admin/src/cms-ui/**, and related tests or
docs.
The task is only Supabase schema, RLS, Auth, Storage, or Edge Functions work;
use the Supabase skills and nested Supabase instructions instead.
The task is only Next.js route-handler or shared API boundary work without
Payload-specific behavior; use
docs/guides/architecture/data-access-boundary.md and backend rules first.
The task is migrating content models from another CMS into Payload; use
docs/ai/skills/payloadcms-cms-migration/SKILL.md.
Precedence:OpenSpec and docs/ai/rules/backend.md control durable
behavior and security. Supabase schema, RLS, and Auth follow
docs/ai/skills/supabase/SKILL.md and supabase/AGENTS.md. Prefer the
repo's installed Payload version and vendor/payload-upstream/ when upstream
examples differ from local APIs.
Workflow
Read This repository and apply the precedence rules before using generic
upstream examples.
Open the local Payload entry points, starting with
apps/admin/payload.config.ts and the relevant files under
apps/admin/src/cms/** or apps/admin/src/cms-ui/**.
Use the matching topic reference under reference/ for the specific Payload
pattern: collections, fields, hooks, access, queries, adapters, endpoints, or
plugins.
Prefer repo conventions over generic examples for auth, storage, migrations,
import maps, and generated types.
Run focused verification for changed Payload behavior.
// ✅ Valid: single string
payload.logger.error("Something went wrong");
// ✅ Valid: object with msg and err
payload.logger.error({ msg: "Failed to process", err: error });
// ❌ Invalid: don't pass error as second argument
payload.logger.error("Failed to process", error);
// ❌ Invalid: use `err` not `error`, use `msg` not `message`
payload.logger.error({ message: "Failed", error: error });
Security Pitfalls
1. Local API Access Control (CRITICAL)
By default, Local API operations bypass ALL access control, even when passing a user.
// ❌ SECURITY BUG: Passes user but ignores their permissionsawait payload.find({
collection: "posts",
user: someUser, // Access control is BYPASSED!
});
// ✅ SECURE: Actually enforces the user's permissionsawait payload.find({
collection: "posts",
user: someUser,
overrideAccess: false, // REQUIRED for access control
});
When to use each:
overrideAccess: true (default) - Server-side operations you trust (cron jobs, system tasks)
overrideAccess: false - When operating on behalf of a user (API routes, webhooks)
