wp-skills

Claude Code skills for WordPress developers.

A collection of Claude Code skills that bring reusable, stack-aware expertise
into your development sessions — sizing tickets, triaging plugins, reviewing
diffs, and more — without re-explaining context every time.

Scope note: When these skills mention "React", they mean React in a WordPress context — block editor / Gutenberg, Interactivity API, admin UIs, or headless WP (Next.js, Faust, etc.). Generic standalone-React projects are not the target.

Companion to wp-agents (subagents
with persistent memory). Skills here focus on lightweight, on-demand workflows
that don't require agent memory.

Skills

wp-effort-estimation

Structured development-effort estimates for WordPress tasks (and React work inside the WP context — Gutenberg, Interactivity API, headless). Outputs
complexity tier, hours/days midpoint, confidence range, subtask breakdown,
assumptions, and risks — ready for Jira, Linear, or a client proposal.

Triggers on: "how long", "estimate", "size this", "story points",
"t-shirt size", "is this a day?", "scope this", "break this down".

→ Install wp-effort-estimation

wp-migration-playbook

Opinionated, production-tested playbook for WordPress content migrations — WP→WP and other-system→WP. Covers inventory + disposition, custom migration plugin architecture (Tier 1–3 + idempotent gating), content type and taxonomy migration, user migration, the hard parts of media migration (ID preservation, intersect-before-delete, REST-based recovery, manifest-based registration), redirects (host-level, Yoast storage shape), operational gotchas, and recovery patterns.

Triggers on: "WP migration", "WordPress migration", "content migration", "migrate to WordPress", "Laravel to WordPress", "Drupal to WordPress", "import posts", "migrate attachments", "media migration", "redirect map", "migration runbook".

→ Install wp-migration-playbook

wp-plugin-code-audit

Verification-first code audit for WordPress plugins. Six-phase workflow (discover → tool scan → manual read → verify → reproduce (optional) → report) covering security, performance, WordPress coding standards, WordPress.org Plugin Directory guidelines, and cross-plugin integration. Produces a dated AUDIT-<yyyy-mm-dd>.md (written to a location you choose, defaulting to a non-public one like .claude/) with severity-sorted findings (Critical / High / Medium / Low / Info), fix recommendations, a verified-false appendix, a collected list of [DECISION] questions only the plugin's owner can answer, and a final GO / NO-GO / GO WITH FIXES verdict. Works against a local plugin directory, a single file, or a remote source (wp.org slug, GitHub URL).

Triggers on: "audit this plugin", "review the plugin", "is this plugin secure", "code audit", "security review", "is this plugin safe to install", "check this plugin for vulnerabilities", "performance review of this plugin".

→ Install wp-plugin-code-audit

wp-theme-code-audit

Theme counterpart of wp-plugin-code-audit: a verification-first audit for WordPress themes (block, classic, hybrid, child). Same six phases, severity rubric, [DECISION] findings and verdict rules, plus theme-specific checks: kses and capability filters widened below unfiltered_html, REST meta without a real auth_callback, contributor publishing bypasses, render-by-ID, block render files and Interactivity API context, patterns, Global Styles CSS, DOM XSS, third-party and bundled scripts, theme review standards, front-end performance, and child-theme overrides diffed against the parent. Produces a dated THEME-AUDIT-<yyyy-mm-dd>.md with a GO / NO-GO / GO WITH FIXES verdict. Requires wp-plugin-code-audit.

Triggers on: "audit this theme", "review the theme", "is this theme secure", "theme security review", "is this theme safe to install", "review this block theme", "review this child theme".

→ Install wp-theme-code-audit

wp-project-security-audit

Verification-first security and vulnerability audit of a whole WordPress project (a wp-content repo, a full site root, or a Bedrock-style layout). Seven-phase workflow (inventory → automated sweeps → component depth → verify → correlate → production check (optional, owner-run) → report): a component inventory with active status per site, dependency advisories with a ships-to-production column, known vulnerabilities at the production version (free and premium slugs), wp.org staleness and slug-hijack risk, vendor compromise, secrets and git history, deploy, CI and webroot exposure, and cross-component correlations. Dispatches custom plugins to wp-plugin-code-audit and custom themes to wp-theme-code-audit, runs the sweeps as parallel subagents, and produces a dated PROJECT-SECURITY-AUDIT-<yyyy-mm-dd>.md sectioned by area with a GO / NO-GO / GO WITH FIXES verdict for production as deployed. Ships read-only inventory, dependency-audit, vulnerability-lookup and production-check scripts. Requires wp-plugin-code-audit and wp-theme-code-audit.

Triggers on: "audit this project", "audit the whole site", "is this site safe", "check every plugin and theme for vulnerabilities", "vulnerability sweep", "is production compromised", "supply chain check for our plugins".

→ Install wp-project-security-audit

wp-plugin-audit-remediation

The phase after the audit. Maintains a REMEDIATION-<yyyy-mm-dd>.md companion log (per-finding status, what changed, how it was verified, what's still owed by the owner), keeps a frozen copy of the audited version so the report's file:line citations stay readable while the code changes, and proves that renames / phpcbf runs / mechanical refactors changed no behaviour via a PHP token-stream diff (which also catches an auto-fixer flipping == to ===). Companion to wp-plugin-code-audit — run the audit first.

Triggers on: "start a remediation log", "mark this finding fixed", "where are we on the audit findings", "is this rename behaviour-neutral", "did phpcbf change behaviour", "freeze the audited version".

→ Install wp-plugin-audit-remediation

wp-mnemon

Deep architectural analysis of WordPress plugins — what the plugin does, how it works, what triggers what, and how data flows through the system. 13-phase workflow produces structured documentation (overview, architecture, hooks, data, extending). Works against a local path or a GitHub URL (public or private). Paired with the wp-mnemon subagent in wp-agents for persistent agent memory; usable standalone for one-shot analysis.

Triggers on: "analyze this plugin", "understand how this plugin works", "map the plugin's hooks", "what does this plugin do", "trace the bootstrap flow", "document this plugin".

→ Install wp-mnemon

wp-pr-review

Context-aware review of a GitHub pull request or GitLab merge request on a WordPress project. Reads the PR, the task it delivers (ticket, acceptance criteria, brief, PRD or plan, thread decisions), and the project's rules; checks out the head and base in separate worktrees; maps every touched plugin and theme with wp-mnemon; then reviews the full diff for scope, correctness, security, performance, build and deploy config, and conventions. Every claim is validated (caused by this PR, stated intent, external facts, runtime state) and re-checked by an independent verifier before it lands in a review doc with a summary comment, per-line comments, and suggestion blocks for quick fixes. Posts to GitHub or GitLab only after you approve the exact text. Requires wp-mnemon.

Triggers on: "review this PR", "code review PR #12", "review this merge request", "review this PR against the ticket", "draft review comments for this PR".

→ Install wp-pr-review

wp-design-to-block-theme

Turn any rendered web design — a deployed preview, a local dev server, or static HTML files — into a WordPress block theme (FSE). No automatic converter exists, so the skill splits the work into the mechanical parts it automates (per-breakpoint Playwright capture of the rendered pages, theme.json tokens derived from what the pages paint, a design-vs-rebuild parity gate, and an editor-vs-front-end parity gate) and the judgment parts it guides: a content-model pass that asks where each piece of content lives (site identity, post fields, taxonomies, meta, settings, custom blocks), then rebuilding each route and section as templates, patterns, content, and Interactivity API blocks that render in the block editor as they do on the site, with each dynamic block's editor preview (JS mirror or ServerSideRender) left to the user. Also runs an editor parity pass on an existing block theme. Covers current block-theme practice (theme.json v3, fluid type, style variations for dark mode, block bindings, root-padding-aware alignments) and the Interactivity API. Ships five scripts (capture.mjs, capture-editor.mjs, cascade-order.mjs, css-tokens.mjs, compare.mjs), is the shared core for the source skills below, and composes with wp-block-themes / wp-patterns / wp-block-development / wp-interactivity-api.

Triggers on: "design to block theme", "HTML to WordPress theme", "convert this mockup to a block theme", "turn this static site into an FSE theme", "extract theme.json from this page", "the editor doesn't match the front end", "editor parity".

→ Install wp-design-to-block-theme

wp-v0-to-block-theme

Translate a v0 (Vercel) design — React/Next + Tailwind + shadcn/ui — into a WordPress block theme (FSE). Adds the v0 inputs, Tailwind v3/v4 token mapping to theme.json (tokens.mjs, with shadcn var() resolution and OKLCH → hex), and a shadcn/ui → core blocks map on top of the wp-design-to-block-theme workflow. Requires wp-design-to-block-theme.

Triggers on: "v0 to WordPress", "v0 to block theme", "convert this v0 design", "Vercel design to WP theme", "Tailwind to theme.json", a v0.dev / *.vercel.app URL paired with a WordPress theme request.

→ Install wp-v0-to-block-theme

wp-claude-design-to-block-theme

Turn a Claude design — a Claude Design canvas or an HTML artifact — into a WordPress block theme (FSE). Unbundles a downloaded canvas into one standalone page per artboard (unbundle.mjs), maps artboards to routes from canvas.json, and reads hover colors, links, data-props tweaks and DCLogic behaviors from the canvas source, then rebuilds with the wp-design-to-block-theme workflow. Requires wp-design-to-block-theme.

Triggers on: "Claude design to WordPress", "turn this canvas into a block theme", "convert this artifact to a WordPress theme", a claude.ai/artifact URL or a downloaded canvas .html paired with a WordPress theme request.

→ Install wp-claude-design-to-block-theme

Install via Claude Code plugin marketplace (recommended)

wp-skills is a Claude Code plugin marketplace. Add it once, then install plugins individually:

/plugin marketplace add s3rgiosan/wp-skills
/plugin install wp-plugin-code-audit@s3rgiosan-wp-skills
/plugin install wp-mnemon@s3rgiosan-wp-skills

Or wire it directly via settings.json:

{
  "extraKnownMarketplaces": {
    "s3rgiosan-wp-skills": {
      "source": { "source": "github", "repo": "s3rgiosan/wp-skills" }
    }
  },
  "enabledPlugins": {
    "wp-plugin-code-audit@s3rgiosan-wp-skills": true,
    "wp-mnemon@s3rgiosan-wp-skills": true
  }
}

Plugins live in the same Claude Code session as your own .claude/ configs — no conflict with prior install.sh installs.

Keep it updated

Auto-update is off by default for third-party marketplaces. Turn it on once:

/plugin → Marketplaces tab → select s3rgiosan-wp-skills → Enable auto-update

Claude Code then refreshes the marketplace and installed plugins in the background shortly after startup (random delay of up to 10 minutes), and prompts you to run /reload-plugins.

Without it, update by hand:

/plugin marketplace update s3rgiosan-wp-skills
/plugin update
/reload-plugins

Heads-up on namespaces. Skills installed via plugins are invoked with the <plugin>:<skill> form (e.g. wp-plugin-code-audit:wp-plugin-code-audit). Skills installed via install.sh keep the bare name (e.g. wp-plugin-code-audit). Pick one source per skill to avoid duplicates.

Install via shell script (fallback)

If you can't use the plugin marketplace (older Claude Code build, scripted environment, etc.) each skill ships an install.sh. See the individual skill README under each subdir.

git clone https://github.com/s3rgiosan/wp-skills.git
cd wp-skills/<skill-name>
bash install.sh                                       # → ~/.claude
CLAUDE_CONFIG_DIR=~/.some-other-dir bash install.sh   # → custom dir

Requirements

• Claude Code — v2.1.110+ for plugin marketplace support.
• Bash (macOS, Linux, or WSL on Windows) for fallback install.sh.

Philosophy

WordPress work — including the React side of it (blocks, editor, Interactivity API, headless frontends) — is full of recurring workflows that benefit from
consistent, opinionated guidance: estimating tickets, auditing plugins,
reviewing blocks, planning migrations. These skills encode that guidance so
every session starts from the same baseline.

Each skill installs into Claude Code's user-level config (~/.claude/skills/)
and becomes available in every project automatically.

Contributing

New skill ideas are welcome. If you build a Claude Code skill for WordPress
development (including its React-flavored surfaces), open a PR.

Each skill lives in its own directory and follows the same structure:

skill-name/
├── .claude-plugin/
│   └── plugin.json              ← plugin manifest (marketplace install)
├── skills/
│   └── skill-name/
│       ├── SKILL.md
│       └── references/          ← optional
│       └── scripts/             ← optional
├── install.sh                   ← fallback installer
├── uninstall.sh
└── README.md

Contributors

• Sérgio Santos (@s3rgiosan)
• Marco Almeida (@webdados)

License

MIT