WordPress
Use this skill for WordPress content, admin, and site-maintenance workflows.
Scope
- draft or update posts and pages
- inspect plugins, themes, users, and site settings
- coordinate wp-admin actions through the browser
- use WP-CLI when shell access to the site exists
- support safe publishing workflows for content teams
Default Strategy
- Confirm whether the target is a local, staging, or production site.
- Prefer read-only inspection before any mutation.
- Draft content first, then create a WordPress draft unless the user explicitly
wants immediate publish.
- Use WP-CLI when it is already available; otherwise use wp-admin or an
existing REST integration.
WP-CLI
Basic checks:
wp --info
wp core version
wp option get home
wp option get siteurl
Useful read commands:
wp post list --post_type=post --fields=ID,post_title,post_status,post_date
wp post get 123 --field=post_title
wp page list --fields=ID,post_title,post_status,post_date
wp plugin list
wp theme list
wp user list --fields=ID,user_login,user_email,roles
Draft-first content workflow:
wp post create --post_type=post --post_status=draft --post_title="Example Title"
wp post update 123 --post_status=draft
Use WP-CLI for content only when you know the site root and environment are
correct. Do not guess against an unknown production checkout.
wp-admin Workflow
Use the browser when:
- the user is already signed in to wp-admin
- content editing is easier visually
- plugin or theme screens must be inspected
- the site uses custom fields or builders that WP-CLI does not represent well
Prepare the exact target before acting:
- site URL
- post or page id
- slug or title
- plugin or theme name
- whether the action is draft, update, publish, install, or delete
Content Workflow
For blog content, draft outside WordPress first when possible:
- outline or write the post
- confirm title, slug, category, and publish state
- create or update a draft
- preview before publish
Default to drafts. Publishing should be explicit.
REST API Guidance
If the site already exposes a safe authenticated REST path:
- read before write
- target one specific post, page, or media item at a time
- keep credentials outside the repo and out of chat
If no REST auth path exists, prefer WP-CLI or wp-admin instead of inventing one
mid-task.
Working Rules
- Always state whether you are using WP-CLI, wp-admin, or REST.
- Never publish, delete, or update production plugins without explicit
confirmation.
- Treat staging and production as separate targets; verify the environment
before running write commands.
- For plugin or theme investigations, collect version and status before changing
anything.
- If the site uses page builders or custom fields, prefer the admin UI unless
there is a known automation path.
Common Use Cases
- create or update a blog post draft
- inspect plugin and theme status
- find a page or post by title or id
- verify site URL, permalink, or user configuration
- coordinate safe content publishing on an existing WordPress site
Pitfalls
- Do not assume the current shell directory is the correct WordPress install.
- Do not publish drafts by default.
- Do not install or update plugins on production just because an update exists.
- Do not treat custom-field-heavy sites as plain post-content workflows.
1---2name: wordpress3description: Draft posts and pages, coordinate wp-admin work, use WP-CLI, inspect themes or plugins, and publish safely.4---5# WordPress67Use this skill for WordPress content, admin, and site-maintenance workflows.89## Scope1011- draft or update posts and pages12- inspect plugins, themes, users, and site settings13- coordinate wp-admin actions through the browser14- use WP-CLI when shell access to the site exists15- support safe publishing workflows for content teams1617## Default Strategy18191. Confirm whether the target is a local, staging, or production site.202. Prefer read-only inspection before any mutation.213. Draft content first, then create a WordPress draft unless the user explicitly22 wants immediate publish.234. Use WP-CLI when it is already available; otherwise use wp-admin or an24 existing REST integration.2526## WP-CLI2728Basic checks:2930```bash31wp --info32wp core version33wp option get home34wp option get siteurl35```3637Useful read commands:3839```bash40wp post list --post_type=post --fields=ID,post_title,post_status,post_date41wp post get 123 --field=post_title42wp page list --fields=ID,post_title,post_status,post_date43wp plugin list44wp theme list45wp user list --fields=ID,user_login,user_email,roles46```4748Draft-first content workflow:4950```bash51wp post create --post_type=post --post_status=draft --post_title="Example Title"52wp post update 123 --post_status=draft53```5455Use WP-CLI for content only when you know the site root and environment are56correct. Do not guess against an unknown production checkout.5758## wp-admin Workflow5960Use the browser when:6162- the user is already signed in to wp-admin63- content editing is easier visually64- plugin or theme screens must be inspected65- the site uses custom fields or builders that WP-CLI does not represent well6667Prepare the exact target before acting:6869- site URL70- post or page id71- slug or title72- plugin or theme name73- whether the action is draft, update, publish, install, or delete7475## Content Workflow7677For blog content, draft outside WordPress first when possible:78791. outline or write the post802. confirm title, slug, category, and publish state813. create or update a draft824. preview before publish8384Default to drafts. Publishing should be explicit.8586## REST API Guidance8788If the site already exposes a safe authenticated REST path:8990- read before write91- target one specific post, page, or media item at a time92- keep credentials outside the repo and out of chat9394If no REST auth path exists, prefer WP-CLI or wp-admin instead of inventing one95mid-task.9697## Working Rules9899- Always state whether you are using WP-CLI, wp-admin, or REST.100- Never publish, delete, or update production plugins without explicit101 confirmation.102- Treat staging and production as separate targets; verify the environment103 before running write commands.104- For plugin or theme investigations, collect version and status before changing105 anything.106- If the site uses page builders or custom fields, prefer the admin UI unless107 there is a known automation path.108109## Common Use Cases110111- create or update a blog post draft112- inspect plugin and theme status113- find a page or post by title or id114- verify site URL, permalink, or user configuration115- coordinate safe content publishing on an existing WordPress site116117## Pitfalls118119- Do not assume the current shell directory is the correct WordPress install.120- Do not publish drafts by default.121- Do not install or update plugins on production just because an update exists.122- Do not treat custom-field-heavy sites as plain post-content workflows.