WordPress AI automation, job by job, with the prompt, the abilities and the limits.

What WordPress AI automation means here, and what it does not

Automation in these workflows means a person asks for a bounded job, an AI client carries it out through typed abilities, and the site decides what is allowed. It does not mean an agent that wakes up on its own and edits the site overnight. The only thing that runs unattended is a routine: read-only audits of accessibility, content and media alt text, which the server schedules daily or weekly and emails to administrators. Every write still starts from a conversation someone opened.

That line is deliberate. A write you asked for, in a session you can list and undo, is easy to reason about. A write nobody asked for is the thing site owners worry about most when they hear AI and WordPress in the same sentence.

Writing your own workflow in the same shape

Most jobs not listed here can be written the same way. Start from the ability reference and find the reads and writes for your task, noting each one's edition and whether it needs confirmation. Then write the prompt in the order these pages use.

• Read first: list or get what will change, and record the current values.
• Propose: show the intended change with IDs and stop for approval. For the abilities it supports, such as update-post, update-media, update-site-settings and the core deletes, preview-ability computes the diff without writing anything, and apply-preview runs exactly that diff later, refusing if the target changed in between. It refuses other abilities by name, so for those the proposal is the client's own table.
• Write in small steps, one item or one batch at a time, so a mistake is caught early.
• Verify: read the result back, and for pages check what the site served with verify-rendered-page.
• Report: a table of what changed, what was skipped and what needs a person.

Choosing the profile for a new job

Match the profile to the job, not to convenience. Read Only suits any job whose output is a report, such as audits, inventories and reviews of what agents did. Production Safe suits content and settings changes on a live site; it still allows destructive calls that carry a confirmation flag, which the client sets itself unless "A person approves" is on. Developer Full Access, which opens plugin installation, code, filesystem, database and command surfaces, belongs on staging, and no job on this page needs it.

When you are unsure, run the read-only half of your new workflow under Read Only first. If it produces a useful proposal, switch profiles for the write half in a new session, so the ledger shows the two stages separately and the session you might undo contains only the writes.