agentleFS
nuttarujnuttaruj/rolepod-wplab/skills/wp-content/SKILL.md

wp-content

Skill1 starsChanged 6 months agoMITView on GitHub

Create, read, update, search posts/pages/users/options/taxonomies via the core WP REST API on a connected target. Phase = Build.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 2 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    NEVER post status=publish on a brand-new draft without explicit user confirmation — drafts are reversible, publishes are user-visible.

    line 16
  2. Very specific:

    NEVER call rolepod_wp_db_query with anything other than SELECT — write/update/delete via REST or wp-cli.

    line 17
  3. Very specific:

    ALWAYS read the existing post (post_get or post_list) before post_update if you do not know the current content — the REST endpoint …

    line 18
  4. Very specific:

    NEVER delete a user without reassign_to — every post the user authored is destroyed with the account otherwise.

    line 19
  5. Very specific:

    When content is a Gutenberg-block page, use the comment-syntax block markup:

    line 96
  6. Very specific:

    Default to status=draft on create.

    line 112
  7. Distinctive:

    No durable artifact — content lives in WordPress.

    line 147
  8. Distinctive:

    Read when constructing Gutenberg block markup or chaining multiple REST calls:

    line 151
  9. Very specific:

    After publish → wp-health-check to verify the page is reachable.

    line 171

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

WP Content

Core-REST CRUD skill. Owns the most common WordPress operations: write a page, list posts, update an option, register a user, query the DB read-only. Anything builder-specific (Elementor JSON, Divi shortcodes) belongs to wp-edit-design; anything plugin-specific (Yoast meta, Woo products) belongs to wp-edit-plugin.

Iron Rule

<EXTREMELY-IMPORTANT> 1. NEVER post `status=publish` on a brand-new draft without explicit user confirmation — drafts are reversible, publishes are user-visible. 2. NEVER call `rolepod_wp_db_query` with anything other than SELECT — write/update/delete via REST or wp-cli; the db_query path is read-only by design and the guard fires hard. 3. ALWAYS read the existing post (`post_get` or `post_list`) before `post_update` if you do not know the current content — the REST endpoint replaces fields, and overwriting an unknown post loses the live content irrecoverably. 4. NEVER delete a user without `reassign_to` — every post the user authored is destroyed with the account otherwise. `rolepod_wp_user_write(action: delete)` refuses (USER_DELETE_NEEDS_REASSIGN) until you name the inheriting user id. </EXTREMELY-IMPORTANT>

When to use

  • "Create a landing page with these sections..."
  • "List the last 10 posts" / "show all pages" / "find posts containing X"
  • "Update the site title to ..." / "change blogname"
  • "Add a tag / category"
  • "Show me all admins"
  • "Query wp_options to see ..."
  • Anything /wp/v2/* REST surface.

Skip when:

  • The content is a builder layout (Elementor / Divi / Oxygen / Bricks) → wp-edit-design.
  • The content is a plugin config (Yoast SEO meta, WooCommerce product) → wp-edit-plugin.
  • The content is a custom block / plugin / theme bootstrap → wp-scaffold.

Boundary

Owns:

  • rolepod_wp_post_{get,list,create,update} for posts/pages/CPTs.
  • rolepod_wp_user_list (read) + rolepod_wp_user_write (create/update/delete).
  • rolepod_wp_term for taxonomy terms (category / tag / custom), rolepod_wp_comment for comment moderation, rolepod_wp_cpt_scaffold to register a custom post type.
  • rolepod_wp_option_{get,set} for the WP-allowed settings surface (siteurl, blogname, etc.).
  • rolepod_wp_db_query (SELECT only). Output is capped at max_bytes (default 64 KB, stdout and stderr each) and the result says total_bytes / returned_bytes / truncated. truncated: true means add LIMIT or select fewer columns — not run it again unchanged.
  • rolepod_wp_rest_request for arbitrary /wp/v2/* calls.
  • rolepod_wp_rest_dump to discover routes — per-namespace counts by default (~1 KB); pass filter_namespace for one namespace's path/methods table, or full: true for all of them (300+ routes, ~50 KB on a plugin-heavy site).

Does not own:

  • Builder content (_elementor_data, Divi shortcodes, Oxygen JSON, Bricks JSON) → wp-edit-design.
  • Plugin-specific writes (Yoast post meta, ACF fields, Woo products) → wp-edit-plugin.
  • File writes outside the REST surface → wp-scaffold or wp-edit-design.

Return / hand off:

  • User wants a layout in Elementor → wp-edit-design.
  • User wants ACF custom fields on the new post → wp-edit-plugin.
  • DB SELECT shows a problem worth diagnosing → wp-diagnose.

Inputs to gather

  • target_id (always).
  • For create: type (default posts), title, content, status (default draft).
  • For update: id + the fields to change (read the post first if content is unknown).
  • For list: type, optional search, status, per_page, page, orderby.
  • For options: name; for set, value + confirm: true if on production.
  • For rest_request: path, method, optional body/query.

Workflow

1. Pick the operation

User intentTool
create a page/post/cptrolepod_wp_post_create
update an existing onerolepod_wp_post_get first (if unknown), then rolepod_wp_post_update
list / search / filterrolepod_wp_post_list
upload an image / set a featured imagerolepod_wp_media_upload
list usersrolepod_wp_user_list
create/update/delete a userrolepod_wp_user_write (delete needs reassign_to)
add/find a category, tag, or custom termrolepod_wp_term (action=ensure is idempotent)
approve / spam / trash / delete a commentrolepod_wp_comment
register a custom post typerolepod_wp_cpt_scaffold
change a post's slug (URL)rolepod_wp_post_update with slug — heed slug_changed_warning
add a 301 redirect (Rank Math backend)rolepod_wp_redirect_set
read site settingrolepod_wp_option_get
write site settingrolepod_wp_option_set (production guard fires if siteurl-matched)
arbitrary REST callrolepod_wp_rest_request
discover what routes existrolepod_wp_rest_dump
read-only DBrolepod_wp_db_query

2. Gutenberg block markup for content fields

When content is a Gutenberg-block page, use the comment-syntax block markup:

<!-- wp:paragraph -->
<p>Hello world.</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":2} -->
<h2>Section title</h2>
<!-- /wp:heading -->

See examples/content-examples.md for non-trivial cases (group blocks, columns, cover, image with attributes).

3. Status flow

Default to status=draft on create. Promote to publish only with explicit user OK. Never set publish for the first commit of a major page (allows revision review).

4. Media + featured images

Upload with rolepod_wp_media_upload(source: base64, data, filename, alt) — or source: url for a remote image, or source: local_path for a file already on the server. Always pass alt (accessibility + SEO). To set a post's featured image in one step, add rolepod_wp_media_upload(source: url, url, alt, set_featured: true, attach_to_post).

With the rolepod-wp companion (v2.23+) the upload is bounded server-side and recorded as a reversible ledger row (disable it to delete the attachment). Without the companion it falls back to a bare REST upload that is not ledgered — remove such an upload manually via rolepod_wp_rest_request DELETE on /wp/v2/media/<id>?force=true.

5. Terms, users, comments, CPTs (dual-path)

These four tools branch on target kind — wp-cli for shell targets (local/ssh/docker), WP REST for a RestTarget — so they work on every connection. The ledger records only on rest targets. Production writes need confirm: true.

  • Terms: rolepod_wp_term(action: ensure, taxonomy: category, name, slug) is idempotent — it returns the existing term (existed: true) or creates it. action: list / action: create are also available. For a custom taxonomy whose REST base differs from its key, pass rest_base.
  • Users: rolepod_wp_user_write(action: create, username, email, role) / action: update / action: delete. A delete ALWAYS needs reassign_to — the user id that inherits the deleted account's posts (Iron Rule #4).
  • Comments: rolepod_wp_comment(action: moderate, id, status) where status is approve / hold / spam / trash; action: delete (add force: true to purge permanently instead of trashing); action: list.
  • Custom post types: rolepod_wp_cpt_scaffold(slug, singular, plural) writes a small regular plugin that register_post_types the CPT + flushes rewrite rules on activation, then activates it. Re-running for the same slug returns CPT_ALREADY_EXISTS. Multisite is unsupported.

6. Confirm + surface

State the operation, the id (post / user / option / attachment), and any warnings. If the response includes _links, just show the canonical link.

If a matching Rolepod agent is available

  • rolepod:rolepod-builder with domain: writing (audience: user) for copy quality.
  • rolepod:rolepod-builder for non-trivial REST orchestration.

If no matching agent is available

  1. Pick the tool from the table.
  2. For updates: read first, then update.
  3. Default status=draft.
  4. Surface the result.

Output

No durable artifact — content lives in WordPress. The MCP returns IDs + canonical links.

Examples

Read when constructing Gutenberg block markup or chaining multiple REST calls:

  • examples/content-examples.md — good vs bad block markup; full landing-page composition example.

References

Inline only. REST surface is documented at https://developer.wordpress.org/rest-api/reference/. Use rolepod_wp_rest_dump to discover the current site's actual routes.

Hard stops

  • db_query with non-SELECT → tool returns DB_WRITE_BLOCKED. STOP; re-route via REST or wp-cli (companion /wp-cli endpoint via wp-execute-php's sibling pattern — but cleaner: use the right REST endpoint).
  • option_set on production-matched siteurl without confirm: true → STOP. Ask user for explicit confirmation, then retry with confirm: true.
  • post_update without id → STOP, ask the user which post.

Full Rolepod enhancement

Full Rolepod adds bulk batching (run 20 post_create in one composite call with optimistic concurrency); standalone, batch by orchestrating individual calls.

Next phase

  • After publish → wp-health-check to verify the page is reachable.
  • For a builder layout pass → wp-edit-design.
  • For plugin-specific writes (Yoast meta, ACF fields) → wp-edit-plugin.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.