wordpress

name	wordpress
description	Draft posts and pages, coordinate wp-admin work, use WP-CLI, inspect themes or plugins, and publish safely.
user-invocable	true
metadata	{"hybridclaw":{"category":"publishing","short_description":"WordPress drafting and publishing.","tags":["wordpress","cms","publishing","web"],"install":["[Truncated]"],"related_skills":["write-blog-post","stripe"]}}

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

1. Confirm whether the target is a local, staging, or production site.
2. Prefer read-only inspection before any mutation.
3. Draft content first, then create a WordPress draft unless the user explicitly wants immediate publish.
4. 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:

1. outline or write the post
2. confirm title, slug, category, and publish state
3. create or update a draft
4. 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.