wp-wpcli-and-ops
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.
Best use case
wp-wpcli-and-ops is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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.
Teams using wp-wpcli-and-ops should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/wp-wpcli-and-ops/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How wp-wpcli-and-ops Compares
| Feature / Agent | wp-wpcli-and-ops | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# WP-CLI and Ops ## When to use Use this skill when the task involves WordPress operational work via WP-CLI, including: - `wp search-replace` (URL changes, domain migrations, protocol switch) - DB export/import, resets, and inspections (`wp db *`) - plugin/theme install/activate/update, language packs - cron event listing/running - cache/rewrite flushing - multisite operations (`wp site *`, `--url`, `--network`) - building repeatable scripts (`wp-cli.yml`, shell scripts, CI jobs) ## Inputs required - Where WP-CLI will run (local dev, staging, production) and whether it’s safe to run. - How to target the correct site root: - `--path=<wordpress-root>` and (multisite) `--url=<site-url>` - Whether this is multisite and whether commands should run network-wide. - Any constraints (no downtime, no DB writes, maintenance window). ## Procedure ### 0) Guardrails: confirm environment and blast radius WP-CLI commands can be destructive. Before running anything that writes: 1. Confirm environment (dev/staging/prod). 2. Confirm targeting (path/url) so you don’t hit the wrong site. 3. Make a backup when performing risky operations. Read: - `references/safety.md` ### 1) Inspect WP-CLI and site targeting (deterministic) Run the inspector: - `node skills/wp-wpcli-and-ops/scripts/wpcli_inspect.mjs --path=<path> [--url=<url>]` If WP-CLI isn’t available, fall back to installing it via the project’s documented tooling (Composer, container, or system package), or ask for the expected execution environment. ### 2) Choose the right workflow #### A) Safe URL/domain migration (`search-replace`) Follow a safe sequence: 1. `wp db export` (backup) 2. `wp search-replace --dry-run` (review impact) 3. Run the real replace with appropriate flags 4. Flush caches/rewrite if needed Read: - `references/search-replace.md` #### B) Plugin/theme operations Use `wp plugin *` / `wp theme *` and confirm you’re acting on the intended site (and network) first. Read: - `references/packages-and-updates.md` #### C) Cron and queues Inspect cron state and run individual events for debugging rather than “run everything blindly”. Read: - `references/cron-and-cache.md` #### D) Multisite operations Multisite changes can affect many sites. Always decide whether you’re operating: - on a single site (`--url=`), or - network-wide (`--network` / iterating sites) Read: - `references/multisite.md` ### 3) Automation patterns (scripts + wp-cli.yml) For repeatable ops, prefer: - `wp-cli.yml` for defaults (path/url, PHP memory limits) - shell scripts that log commands and stop on error - CI jobs that run read-only checks by default Read: - `references/automation.md` ## Verification - Re-run `wpcli_inspect` after changes that could affect targeting or config. - Confirm intended side effects: - correct URLs updated - plugins/themes in expected state - cron/caches flushed where needed - If there’s a health check endpoint or smoke test suite, run it after ops changes. ## Failure modes / debugging - “Error: This does not seem to be a WordPress installation.” - wrong `--path`, wrong container, or missing `wp-config.php` - Multisite commands affecting the wrong site - missing `--url` or wrong URL - Search-replace causes unexpected serialization issues - wrong flags or changing serialized data unsafely See: - `references/debugging.md` ## Escalation - If you cannot confirm environment safety, do not run write operations. - If the repo uses containerized tooling (Docker/wp-env) but you can’t access it, ask for the intended command runner or CI job.
Related Skills
use-zod
Answer questions about the Zod schema validation library and help build schemas, parsers, refinements, transforms, codecs, and error formatters. Use when developers: (1) ask about Zod APIs like `z.object`, `z.string`, `z.array`, `z.union`, `z.discriminatedUnion`, `parse`, `safeParse`, `z.infer`; (2) define request/response/form schemas in TypeScript; (3) handle `ZodError` or customize error messages; (4) migrate between Zod v3 and v4 (entry-point split, `formatError` → `treeifyError`/`prettifyError`, unified `error` param replacing `message`/`errorMap`). Triggers on: "zod", "z.object", "z.string", "z.array", "z.union", "z.infer", "z.input", "z.output", "ZodError", "$ZodError", "safeParse", "parseAsync", "z.codec", "treeifyError", "prettifyError", "flattenError", "discriminatedUnion", "zod/v4", "zod/v3", "zod/mini", "z.coerce", "superRefine".
workflow
Creates durable, resumable workflows using Vercel's Workflow SDK. Use when building workflows that need to survive restarts, pause for external events, retry on failure, or coordinate multi-step operations over time. Triggers on mentions of "workflow", "durable functions", "resumable", "workflow sdk", "queue", "event", "push", "subscribe", or step-based orchestration.
wpds
Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.
wp-rest-api
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.
wp-project-triage
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.
wp-plugin-development
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.
wp-playground
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).
wp-phpstan
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.
wp-performance
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.
wp-block-development
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.
wp-abilities-api
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.
wordpress-router
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).