How to Write Good Instructions for an AI Working in WordPress

A strong WordPress instruction tells the assistant what outcome is required, which records and sources are in scope, what it may do, what it must not do, what format to return, how the result will be checked and when it must stop. “Improve my site” is not a usable operational instruction.

The prompt should not be the only control. WordPress permissions must independently prevent actions that the identity is not allowed to perform.

In one sentence: Treat the instruction as a task contract and the WordPress identity as the enforcement boundary.

What this guide helps you accomplish

This guide provides a reusable prompt architecture for content, SEO, UX and maintenance tasks. It helps beginners write clearer requests while giving advanced operators fields that can be validated and logged.

A useful AI workflow is not defined only by the quality of the answer. It is also defined by the data the assistant can reach, the actions it is permitted to take, the evidence you can inspect afterward and the ease with which access can be withdrawn.

Why this matters

Vague prompts force the assistant to invent scope, priorities and stopping conditions. In a chat, that may produce a mediocre answer. In a connected WordPress workflow, it can produce unexpected actions. A structured instruction reduces ambiguity and makes failure easier to diagnose.

Prompt quality cannot compensate for excessive permissions. Both layers are necessary.

Expected output

A successful run should produce:

• A reusable WordPress task-instruction template.
• Explicit allowed and forbidden actions.
• A defined output schema and evidence requirement.
• A stopping and escalation condition.
• A prompt that can be tested across assistants.

The eight fields of a good instruction

Include objective, target, source of truth, allowed actions, forbidden actions, required output, verification method and stop condition. Add audience, style or examples only after these operational fields are clear.

Name the source of truth

Tell the assistant which WordPress records, documents, exports or official sources are authoritative. When sources disagree, instruct it to report the conflict rather than choose the most plausible answer.

Use positive and negative constraints

“Create one draft” is a positive constraint. “Do not publish, schedule, delete or edit other records” is a negative constraint. Both are valuable. Avoid impossible blanket instructions such as “never make a mistake”; define observable behavior instead.

Design the output for review

A useful output includes stable IDs, affected URLs, evidence, confidence, unresolved questions and a summary of actions taken. Long prose without identifiers is difficult to verify against WordPress.

A safe workflow

1. Write the one-sentence objective.
2. Name exact records, post types, URLs or data sources.
3. Define the WordPress access level independently.
4. List allowed actions.
5. List forbidden actions and escalation triggers.
6. Specify the output schema and evidence.
7. Add a stopping condition.
8. Test the prompt on a small sample and refine ambiguity.

Prompt recipe

Before copying this prompt, replace every value in square brackets. Do not paste credentials, customer data or private information into the instruction.

Objective: [one measurable outcome]

Target:
- Site/environment: [staging, production read-only, or export]
- Record scope: [IDs, URLs, post types, statuses, maximum count]

Sources of truth:
- [source 1]
- [source 2]

Allowed actions:
- [action]

Forbidden actions:
- Do not publish, schedule, delete, install, remove, change users or modify unrelated records.
- Do not infer missing facts.
- Do not broaden the scope without approval.

Required output:
- [table, draft, report, patch or checklist]
- Include record IDs, evidence, confidence and unresolved questions.

Verification:
- [how a human will compare the result]

Stop when:
- [deliverable is complete, record cap is reached, data is missing or permission is refused]

Why the prompt is structured this way

The template is deliberately operational. It can be specialized for a simple public analysis or a connected WordPress task. The access level remains outside the prompt because the environment must enforce it independently.

Recommended access boundary

The correct level depends on the requested action. Start with no connection or Read Only, then move to Draft or Content Editor only when the task cannot be completed safely at the lower level.

Low does not mean zero. Review the input scope and make sure the output contains no private or irrelevant information.

The access level is a starting recommendation, not a universal entitlement. The exact WordPress capabilities available to an identity must come from the installed product version and its published coverage, not from this article alone.

What must remain outside the task

• Do not place passwords, tokens or licence keys in the instruction.
• Do not use prompt wording as the only permission control.
• Do not leave target scope or maximum record count implicit.
• Do not hide unresolved information inside fluent prose.

How WP Agent Control fits

Get structured site information and inspect selected published pages after connecting. No temporary task is needed for this public reading. You can also browse public pages without the plugin; Agent Control adds structured access and a path toward authorized WordPress work.

Authorize a draft task and select any reference content. The assistant can create and revise drafts created by that task. Existing references remain read-only, even when a reference is itself a draft. Review the result in WordPress.

With Solo, Pro or Agency, authorize a proposal task for selected content and fields. Examine the complete comparison in WordPress and select the proposals you approve. Approval is tied to that object, its fields and current content; a changed source or task can invalidate it. Approving a content change does not authorize publication. Solo, Pro or Agency must also have a publication task that covers the still-valid approval. Check the published result yourself.

Connect your AI: docs first profile · See features and compatibility: coverage

Verification checklist

• ☐ Objective and target are measurable.
• ☐ Sources of truth are named.
• ☐ Allowed and forbidden actions are explicit.
• ☐ The output contains stable identifiers and evidence.
• ☐ A stop condition exists.
• ☐ WordPress permissions independently enforce the boundary.

Common failure modes

• Writing only a role prompt: “You are an SEO expert” does not define scope, actions or evidence.
• Hiding the target: The assistant chooses records or pages without approval.
• No stopping condition: The task expands into additional analysis or changes.
• Relying on “be careful”: A vague caution is not an observable control.

Advanced note

Prompts can be represented as versioned task specifications with machine-readable fields. A renderer can produce client-specific wording while keeping the objective, source, permissions and output contract stable. This makes prompt changes reviewable and reduces drift across languages.

Related guides

• WordPress AI Audit Prompts: A Safe Starter Library
• Which WordPress Access Level Should You Give an AI?
• Which WordPress Tasks Should You Delegate to AI?
• How to Prepare WordPress Edits with AI Without Publishing

Continue

Next step: copy the prompt, run it first with the recommended access level and verify the output before granting any broader permission. WP Agent Control can provide a separate, revocable WordPress identity for that controlled workflow. See Product and Pricing.