agent-skills

Patch, extend, or explain DatoCMS front-end integration code in an existing web project (Next.js App Router, Nuxt, SvelteKit, Astro, plus React/Vue/Svelte component usage). Use for targeted, per-concern work — adding a draft mode endpoint, wiring Preview Links / Visual Editing flows, fixing Content Link overlays, tuning real-time preview subscriptions, setting up cache-tag invalidation/revalidation (Next.js revalidateTag or CDN purge by tags), adding robots/sitemap wiring, hooking up crawler-safe search. Also the go-to skill for framework component/hook wiring with react-datocms, vue-datocms, @datocms/svelte, @datocms/astro: Image/RSCImage/datocms-image, StructuredText, VideoPlayer (React/Vue/Svelte), SEO/meta helpers (renderMetaTags/toHead/Seo), QuerySubscription/QueryListener realtime, ContentLink components, Site Search (React/Vue). Prefer when modifying a live codebase one concern at a time, asking a framework-specific API question, or mixing several front-end concerns in the same patch.

Query the DatoCMS Content Delivery API (CDA) — the read-only GraphQL API — using @datocms/cda-client. Use when users ask for GraphQL content reads: fetching posts/pages/projects, filtering by date/text/fields, sorting/order, pagination/load-more, text pattern matching via regex filters, localization and fallback locales, modular content fragments, Structured Text (DAST) with blocks/inline records, responsive images (srcset/blur-up/imgix), SEO metadata (_seoMetaTags, favicons, global SEO), video/Mux fields, draft or preview reads, environment-targeted reads, cache tags via rawExecuteQuery, and Content Link metadata for visual editing. Also use for CDA query type generation with gql.tada or GraphQL Code Generator.

DatoCMS CLI (datocms) — command-line migrations, schema codegen, schema inspection, one-off CMA calls, typed TypeScript CMA scripts, env operations, deployment workflows, multi-project profile syncing. Use for datocms CLI commands/scripts: migrations:new, migrations:run; schema:generate; schema:inspect (dump models, blocks, fields, validators, appearance, fieldsets, nested blocks, referenced/embedding models); cma:call, cma:docs, cma:script (ad-hoc typed TS with ambient client/Schema globals); migration scaffolding for models/fields/blocks; CLI setup via datocms.config.json + profiles; OAuth (login/logout/whoami); projects:list; project link/unlink; env list/fork/promote/rename/destroy; maintenance-mode toggle; CI/CD migration pipelines; blueprint/client project sync; imports from WordPress or Contentful (assets + content); CLI plugin management (plugins:install/add/available/link/remove/update/reset/inspect).

Node.js/TypeScript scripts driving the DatoCMS Content Management API via @datocms/cma-client (-node/-browser). Code-first companion for content + automation work. Use for record/upload/project-automation code — short asks ("publish them", "fix those slugs", "delete all drafts", "bulk import this CSV") and checked-in scripts. Covers: (1) content ops — CRUD + publish records, bulk import/export, CSV pipelines, pagination, asset uploads (URL/file) with metadata, structured-text + block payload edits; (2) env + governance — fork/promote envs, webhooks, build triggers, project settings, maintenance mode, scheduled publish/unpublish, audit logs, usage analytics, subscription limits; (3) access + typed flows — roles, API tokens, upload tracks/tags, generated CMA types; (4) schema/UI mutation only when user opts out of migrations or embeds it in automation. Ordinary schema changes → `datocms-cli` migrations. Runs via `cma:call`/`cma:script` or checked-in `buildClient()` scripts.

Build, scaffold, maintain, or restyle DatoCMS plugins built with datocms-plugin-sdk and datocms-react-ui. Use when users ask to create a new DatoCMS plugin project, patch an existing plugin, add or adjust plugin hooks, field extensions, config screens, sidebars, pages, modals, asset sources, dropdown actions, lifecycle hooks, browser CMA flows, plugin permissions, package metadata, dark mode upgrades, or UI changes that should match the DatoCMS dashboard. Route standalone CMA scripts to datocms-cma and frontend website integrations to datocms-frontend-integrations.

Draft sanitized feedback emails to support@datocms.com about frustrating DatoCMS skills or MCP experiences. Use only when users explicitly ask to report, email, or summarize feedback about DatoCMS skills/MCP, or when the skills/MCP workflow has clearly reached a dead end after repeated loops, wrong routing, unresolved misunderstandings, or no credible next step. Do not use for ordinary first failures, retryable MCP/command/API errors, validation feedback, schema discovery misses, missing environment values, project/plugin bugs, or setup problems where another DatoCMS skill can still continue.

Run the trigger evaluation pipeline — classify, analyze, and optionally compare against a baseline. Only run when explicitly asked — evals are expensive.

Run repo validation to check skill metadata sync, eval fixture coverage, and repo invariants.

Single entry point for one-shot, end-to-end DatoCMS project setup — bundles prerequisites, chains recipes, takes a greenfield or partial project to working state in one pass. Five lanes: (1) frontend foundation (bootstrap Next.js/Nuxt/SvelteKit/Astro from scratch); (2) frontend features (draft mode, visual editing, web previews, content link, real-time updates, responsive images, SEO, robots/sitemaps, site search, revalidation/cache tags — applied with prerequisites); (3) migrations (CLI profiles, baseline migrations, shared histories, release workflow, sandbox reset loops, diff-based generation); (4) onboarding imports (WordPress, Contentful — content + assets); (5) platform automation (CMA scripting + project-level automation). Use when user wants a named outcome scaffolded in full, when related features must land together (e.g. "set up visual editing" → draft mode + content link + web previews), or for broad "set up X" needing routing to the smallest matching recipe bundle.

Decision frameworks for DatoCMS content modeling — schema shape, field choice, content reuse, taxonomies, content vs presentation, admin UI organization. Use for modeling *decisions*, not implementation: model vs block; single_block vs Modular Content vs Structured Text; references vs embedded blocks; taxonomy shape (flat/tree/faceted); refactoring page-shaped schemas to reusable content; fitting 300 KB / 500-block / 5-level record limits; model behaviour (singleton, draft mode, all_locales_required, sortable/tree/ordering_field, presentation_title_field, collection_appearance, inverse_relationships_enabled); field config (validator + appearance — enum + string_select, slug auto-fill, required_alt_title, structured_text allowlists, framed vs frameless single_block). Also schema review (reuse, editor ergonomics, omnichannel). *Creating* schema → `datocms-cli` or `datocms-cma`. Query/render → `datocms-cda` + `datocms-frontend-integrations`. Validators + cascade: `datocms-cma/references/schema.md`.