Automattic Skills

Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging).

Use when working with the WordPress Abilities API (wp_register_ability, wp_register_ability_category, /wp-json/wp-abilities/v1/*, @wordpress/abilities) including defining abilities, categories, meta, REST exposure, and permissions checks for clients.

Use when developing WordPress (Gutenberg) blocks: block.json metadata, register_block_type(_from_metadata), attributes/serialization, supports, dynamic rendering (render.php/render_callback), deprecations/migrations, viewScript vs viewScriptModule, and @wordpress/scripts/@wordpress/create-block build and test workflows.

Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching).

Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.

Use for WordPress Playground workflows: fast disposable WP instances in the browser or locally via @wp-playground/cli (server, run-blueprint, build-snapshot), auto-mounting plugins/themes, switching WP/PHP versions, blueprints, and debugging (Xdebug).

Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.

Use when you need a deterministic inspection of a WordPress repository (plugin/theme/block theme/WP core/Gutenberg/full site) including tooling/tests/version hints, and a structured JSON report to guide workflows and guardrails.

Use when working with WP-CLI (wp) for WordPress operations: safe search-replace, db export/import, plugin/theme/user/content management, cron, cache flushing, multisite, and scripting/automation with wp-cli.yml.

Use when editing or migrating Calypso Reader data-fetching code — `client/components/data/query-reader-*` components, `@automattic/data-stores` Reader hooks, or new Reader queries/mutations. Triggers on any work involving `api-core`, `api-queries`, `dispatchRequest`, `READER_*_REQUEST` actions, or Redux `isRequesting*` selectors in the Reader.

Provide advisory guidance for scanning Automattic/wp-calypso Dependabot alerts and Dependabot remediation PRs using the public dependency security alerts playbook.

Create a new screen in the Multi-site Dashboard with automatic route registration

Given a wp-calypso PR number, identify the failing E2E test(s) in that PR's CI run so they can be fixed. Use when asked to investigate or fix a failing E2E test on a specific PR.

Run a browser-based UI review of the WordPress.com Help Center across multiple surfaces, looking for visual and behavioral issues. Use when asked to test the Help Center UI.

Run comprehensive UI tests for the Image Studio feature. Covers Media Library entry points, Edit Mode, Generate Mode, Block Editor integration, navigation, and delete. Use when running the full UI smoke test or testing any Image Studio surface.

Use when reviewing PRs that touch the Reader's multi-protocol social surfaces (`client/reader/social/`, `client/reader/atmosphere/`, `client/reader/mastodon/`, `packages/api-core/src/reader-{atmosphere,mastodon}/`, `packages/api-queries/src/reader-{atmosphere,mastodon}.ts`). Captures the review rubric + the recurring smells from the CM-625 / CM-658 / CM-660 / CM-662 slice cycle.

Cherry-pick a merged pull request's commit(s) from `main` onto the current release branch and open a draft PR.

Check whether a Pocket Casts Android pull request qualifies for self-approval and, if it does, label it "[Review] Self Approved". Use this whenever the user asks if they can self-approve, self-review, or merge their own PR without a human reviewer, or asks to "self-approve this PR". Pass a PR number as an argument, or run it from a branch with an open PR. Pass "check" to report the verdict without labelling.

End-to-end implementation workflow: plan, implement, verify, commit, and open a draft PR. Use when asked to implement, fix, build, or work on something.

Address PR review comments by fixing code, replying to each comment, and re-requesting review. Use this skill when the user wants to handle, fix, resolve, or address PR feedback, review comments, or code review suggestions. Also use when the user says things like "fix the PR comments", "handle review feedback", "address the review", or "respond to PR feedback".

Cross-platform codebase exploration for Pocket Casts. Use when asked about Web, iOS, or Android implementation of a feature, or when comparing implementations across platforms.

Adds a feature flag and fences off code with it

> Expert guidance for Dynamic Type support for Pocket Casts iOS development with Swift, UIKit, and SwiftUI. Use this skill when the user asks about Dynamic Type, content size categories, accessibility text size, font scaling, or making text/UI elements respond to the user's preferred text size (e.g., using preferredContentSizeCategory, adjustsFontForContentSizeCategory, UIFontMetrics, or related APIs in SwiftUI and UIKit).

>- Open a GitHub pull request for the Sensei plugin the way this repo requires. Use this whenever the user wants to create, open, draft, or "put up" a PR, or says things like "open a PR", "create a pull request", "make a PR for this branch", or "PR this". It fills the repo's PULL_REQUEST_TEMPLATE.md from the actual diff against trunk, sets the changelog details so CI generates the entry, assigns the required milestone, and stops for approval before pushing. Prefer this skill over a bare `gh pr create` so the PR doesn't fail `pr-validation.yml` on a missing milestone or changelog, and so the body matches the template reviewers expect.

PHP coding standards and WordPress patterns for ActivityPub plugin. Use when writing PHP code, creating classes, implementing WordPress hooks, or structuring plugin files.

PHP coding standards and WordPress patterns for ActivityPub plugin. Use when writing PHP code, creating classes, implementing WordPress hooks, or structuring plugin files.

Development workflows for WordPress ActivityPub plugin including wp-env setup, testing commands, linting, and build processes. Use when setting up development environment, running tests, checking code quality, building assets, or working with wp-env.

Development workflows for WordPress ActivityPub plugin including wp-env setup, testing commands, linting, and build processes. Use when setting up development environment, running tests, checking code quality, building assets, or working with wp-env.

ActivityPub protocol specification and federation concepts. Use when working with ActivityPub activities, understanding federation mechanics, implementing protocol features, or debugging federation issues.

ActivityPub protocol specification and federation concepts. Use when working with ActivityPub activities, understanding federation mechanics, implementing protocol features, or debugging federation issues.

Use when auditing or updating .gitattributes export-ignore coverage so dev-only files (lint configs, CI, tests, docs, build tooling) don't ship in the WordPress.org plugin zip. Run before a release, after adding a new top-level file or config, or when a tool is renamed (e.g. .eslintrc.js → eslint.config.cjs).

Use when auditing or updating .gitattributes export-ignore coverage so dev-only files (lint configs, CI, tests, docs, build tooling) don't ship in the WordPress.org plugin zip. Run before a release, after adding a new top-level file or config, or when a tool is renamed (e.g. .eslintrc.js → eslint.config.cjs).

Third-party WordPress plugin integration patterns. Use when adding new integrations, debugging compatibility with other plugins, or working with existing integrations.

Third-party WordPress plugin integration patterns. Use when adding new integrations, debugging compatibility with other plugins, or working with existing integrations.

INVOKE THIS SKILL before creating any PR to ensure compliance with branch naming, changelog requirements, and reviewer assignment.

INVOKE THIS SKILL before creating any PR to ensure compliance with branch naming, changelog requirements, and reviewer assignment.

Version management and release processes using Jetpack Changelogger. Use when creating releases, managing changelogs, bumping versions, or preparing patch releases.

Version management and release processes using Jetpack Changelogger. Use when creating releases, managing changelogs, bumping versions, or preparing patch releases.

Build a new platform adapter to extract content from an unsupported platform (Blogger, Ghost, Tumblr, etc.)

Open a browser with visual annotation tools. The user clicks elements on their site and leaves feedback — the agent reads annotations and makes changes. Use this when the user wants to point at specific elements to fix, tweak, or redesign.

Write editable WordPress block markup for local Studio sites, including core/html limits, block-theme layout rules, full-width sections, validation, and skeleton-first page/CSS recipes.

Compose a single liberated page's WordPress block-editor markup from its rendered HTML and screenshot. Inputs are a sanitized HTML file, a desktop screenshot, the design-foundation tokens, the URL's archetype (page/post/product/etc.), and the source URL. Output is a string of valid block markup that round-trips through parse_blocks, uses theme tokens (no inlined hex colors), and contains only text drawn from the source HTML. Call per-page during the streaming watch loop after extraction has produced HTML+screenshot for that URL. Use when a freshly-imported page needs `post_content` upgraded from raw HTML into block-editor markup so the replica theme's tokens, gradients, and patterns actually render.

Templates and guidelines for creating new WordPress blocks from scratch — load this before generating block files

Guidelines for creating new WordPress block themes from scratch — load this before generating theme files

Build a coherent design-foundation JSON from a liberated site — semantic color/typography/spacing roles with evidence trails. Consumes the partial scaffold produced by liberate_design_foundation_scaffold plus aggregate HTML/CSS analysis and representative rendered HTML; produces a complete design-foundation matching the schema. Call after liberation, before theme generation.

Visual-QA loop run after replica theme install and content import. Captures replica screenshots, applies a hard responsiveness gate at 390px AND a hard per-section visual-parity gate (measured SectionParity records, verdict computed by buildRunReport), runs qualitative vision review of source/replica pairs, checks accessibility, and drives a per-section escalation ladder of fixes via editing-themes/editing-blocks/rebuild-section (R1 CSS → R2 spec-rebuild → R3 re-extract → R4a AI canonical-block rebuild → R4b deterministic styled-island floor) — escalating unresolved divergences to the operator rather than shipping them. Orchestration-internal — invoked by the replicate-with-blocks/liberate orchestrators, not directly by users.

Debug failed or low-quality extractions by analyzing logs, probing the source site, and identifying root causes

Guidelines for modifying existing WordPress blocks — load this before editing block files

Guidelines for modifying existing WordPress block themes — load this before editing theme files

Guidelines and examples for generating WordPress block patterns — load this when creating patterns for themes

Answer WordPress.com plan, pricing, upgrade, and feature-tier questions (plan names, what each tier unlocks — plugins, themes, custom code, SSH, hosting — and current prices) from authoritative live data. Load before answering ANY plan, pricing, or feature-gating question; never answer these from memory.

Import and rebuild a website from a closed platform (Wix, Squarespace, Webflow, Shopify, GoDaddy, Hostinger, HubSpot, Weebly) into a Studio WordPress site. Extracts pages/posts/products + media, then reconstructs the design as editable blocks + WooCommerce OR as a high-fidelity replica theme. Invoke when the user wants to migrate, import, liberate, or rebuild a site from one of these platforms.

Front door for the whole migration. FIRST routes on input type — a local directory of owned HTML/CSS/JS takes the local carry-to-block-theme path (dispatches liberate-local inline; no platform detection, no network extraction, no path checkpoint), while a URL takes the remote path: detect → discover, then ALWAYS stop and ask the operator (AskUserQuestion) which reconstruct path to take (blocks+products, or theme replication) BEFORE running extraction/capture, then dispatch the matching sub-skill. On the URL path the path question is a mandatory, non-skippable gate that fires right after discovery while the operator is still present — never auto-select, never defer it past extraction. Idempotent: re-running on an already-captured site skips straight to the path question (URL) or re-converts deterministically (local).

The OWNED LOCAL static-site path of /liberate — dispatched inline by `/liberate` when its input is a local directory (not a URL). Point it at a directory of hand-authored / Claude-generated HTML+CSS+JS and it stands up a fresh WordPress Studio site and converts the source into a native block theme + live editable pages, carrying the source's own CSS/JS for identical parity. The local-source analog of the URL path: no extraction (the source is already on disk), no platform detection — it provisions the Studio target itself (studio site create), processes the HTML/CSS/JS, then builds the theme and the site. One command drives everything. Hidden from autocomplete and runs only via the `/liberate` front door; not directly user-invokable.

Orchestrate whole-PAGE visual parity, with a replayable parity log so the work survives a reconstruct. PHASE 0 — if <outputDir>/parity-log.json exists, REPLAY its logged intents onto the current build first (apply + verify each by looking), so prior parity work is re-applied to whatever the latest reconstruction produced. PHASE 1 — one batch pass measuring EVERY band's built design vs the SOURCE screenshot across all axes, emitting a per-band verdict. PHASE 2 — iterate match-section on the divergent bands only, worst-first, LOGGING each fix as a semantic parity-log entry, until each matches. Never hand-roll per-section work without the batch assessment; never assert a match without cropping source+built and looking. Dispatched by replicate-with-blocks/design-qa; calls match-section per band; writes/reads parity-log.json.

Reach VISUAL parity for ONE section by guiding AI to apply the captured design data (colors, padding, margins, full-bleed, font sizes, line-heights, families, alignment) to that section's WordPress block markup, then VERIFYING by looking at the source section and the built section side-by-side and iterating until they are visually identical. Non-deterministic on purpose — deterministic emission gets the structure right but misses visual parity; this skill closes the gap with an AI eyes-on loop. The per-section EXECUTOR called by `match-page` (which runs the batch Phase-1 assessment first, then dispatches this per divergent section). Do not drive whole-page parity by hand-rolling per-section work — run `match-page` so the batch assessment happens first. Dispatched per section (subagent) by match-page/replicate-with-blocks/design-qa. Not user-invocable directly.

Alias for `/liberate`. Migrate a website or an owned local directory into WordPress — point it at a URL (a live site you don't control) or at a local folder of HTML/CSS/JS you own, and it runs the full liberate pipeline (route on input → detect/discover/extract/capture + reconstruct for URLs; provision Studio + carry-to-block-theme for local dirs). Use `/migrate <url-or-dir>` exactly like `/liberate <url-or-dir>`.

Analyze an OWNED local static site's JavaScript data grids or repeated static-HTML content cards and emit a data-model.json that turns that data into real WordPress posts/taxonomy + native query loops while keeping the styling/animation/modal JS. Produces the model that liberate-local's convert step consumes. Use before liberate_convert_local_site when the source renders its content from JS data (catalogs, listings, galleries) or repeated post-preview cards in static HTML.

Run a frontend performance audit on a WordPress site and get actionable optimization recommendations.

Choose recommended plugins and plugin-provided blocks for features core WordPress blocks do not cover - ecommerce (WooCommerce), forms and newsletters (Jetpack), online courses and quizzes (Sensei LMS), polls, surveys and ratings (Crowdsignal), spam protection (Akismet) - while keeping generated content editable and avoiding raw HTML fallbacks. Any request to sell products or build a shop, store, or storefront requires WooCommerce with products.

Compare extracted WXR content against the original source site page by page. Find missing text, headings, images, and links. Fix by patching the WXR or re-extracting individual pages. Produces a health score and structured report. Use when asked to "qa", "check extraction", "compare content", or "verify extraction quality".

Run an on-page SEO audit on a WordPress site and get actionable recommendations to improve search visibility.

R4a of the design-qa escalation ladder — rebuild ONE divergent section into canonical, editable WordPress core blocks from its source HTML, screenshots, spec, and design tokens, when R1–R3 (CSS / spec-rebuild / re-extract) could not reach visual parity. Dispatched as a subagent by design-qa; not user-invocable. Output ships ONLY if it re-scores `match` and survives canonicalization with no content loss — otherwise the loop falls to the R4b styled-island floor.

Parity-first carry-and-scope theme reconstruction — dispatched by `/liberate` after capture. Instead of projecting the source onto editable WordPress blocks (the `replicate-with-blocks` path), it CARRIES the source page near-verbatim and SCOPES the source's own CSS under a per-site wrapper, producing a high-fidelity but NON-block-editable theme. It owns only the reconstruct→theme stage (capture already happened in `/liberate`); writes `output-carry.wxr` + a `<site>-carry` theme and installs into a Studio site named after the source. Use when the user picks "theme replication" at the `/liberate` checkpoint, or asks to "carry the HTML", "scope the source CSS", or maximize visual parity vs. blocks.

Spec-driven, whole-site block-theme reconstruction for a liberated site. Invokes design-foundations → creating-themes → clustering → spec extraction → generating-patterns (fan-out, per cluster) → assemble → validate → install → design-qa to produce a responsive, editable WordPress block theme that matches the source site's layout, content structure, and visual design. Call after `liberate` (extraction) and before content import, or re-run standalone to re-theme an already-extracted site. Use when the user says "rebuild this site," "replicate the design," "make a theme that matches," "recreate the layout," or asks for a WordPress version of a liberated site.

Gather the site name and layout preference before building a WordPress site. Run this before creating any new site.

Use the Studio CLI to manage local WordPress sites, authentication, and preview sites. Invoke this skill when you need to run Studio CLI commands, manage sites, or troubleshoot site issues.

Analyze and optimize a WordPress site's category taxonomy. Exports all posts, uses AI to suggest an improved category structure — merging duplicates, retiring dead categories, creating missing ones, writing descriptions, and re-categorizing posts. Run this when the user wants to clean up or improve their categories.

Guidelines for checking JavaScript files for syntax errors

Guidelines for running PHP linting to catch syntax errors

Guidelines for running wp-now to validate WordPress plugins and themes at runtime

Plan and execute high-quality visual direction for site creation, redesign, layout, typography, color, motion, and visual polish.

Verify and polish a built or redesigned site by diagnosing rendered-DOM issues against intent and fixing them in a planned, batched screenshot-and-fix loop.

Manage a remote WordPress.com site with wpcom_request, including API namespace selection, endpoint discovery, content/template/theme/plugin operations, response-size limits, and visual verification.

Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.

Use when building or debugging WordPress Interactivity API features (data-wp-* directives, @wordpress/interactivity store/state/actions, block viewScriptModule integration, wp_interactivity_*()) including performance, hydration, and directive behavior.

Use when configuring, running, or fixing PHPStan static analysis in WordPress projects (plugins/themes/sites): phpstan.neon setup, baselines, WordPress-specific typing, and handling third-party plugin classes.

Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.

Use when running E2E tests, setting up the E2E environment, debugging E2E test failures, or verifying code changes work from a user's perspective. Triggers include "run E2E tests", "verify changes", "Playwright", "test setup", "E2E failures".

Run linting, formatting, and type checking on changed files. Use when asked to "lint", "fix linting", "run linter", "check formatting", or "check types".

Set up Claude Code for this project. Use when the user invokes /setup-claude, asks to "set up claude", or "create the skills symlink".

Update agent context files for this project. Use when the user invokes /update-agent-context, asks to "update agent docs", "update CLAUDE.md", "update AGENTS.md", "add to agent_docs", "record a correction", or mentions updating context for a specific topic.

Generate PR description using repository's PR template and current branch changes, copy to clipboard

Bold aesthetic direction guidance for web design. Use when making creative decisions about typography, color, motion, spatial composition, and overall visual style. Helps avoid generic "AI slop" aesthetics.

Extract comprehensive site specifications from simple descriptions. Use when analyzing a user's theme request to determine site type, audience, tone, layout requirements, and typography.

Extract comprehensive site specifications from simple descriptions. Use when analyzing a user's theme request to determine site type, audience, tone, layout requirements, and typography.

WordPress Full Site Editing (FSE) theme architecture. Use when generating theme.json, block templates, template parts, patterns, and functions.php for WordPress block themes.

Update agent context files for this project. Use when the user invokes /update-agent-context, asks to "update agent docs", "update CLAUDE.md", "update AGENTS.md", "add to agent_docs", "record a correction", or mentions updating context for a specific topic.

Set up Claude Code for this project. Use when the user invokes /setup-claude, asks to "set up claude", or "create the skills symlink".

Run linting, formatting, and type checking on changed files. Use when asked to "lint", "fix linting", "run linter", "check formatting", or "check types".