How to teach an AI agent your WordPress conventions
Updated October 15, 2026 · by the Novamira team
An AI agent that builds WordPress sites well on the first try is rarely running a better model than yours; it is running on better instructions. Coding standards, naming schemes, builder rules, design tokens: when these live somewhere the agent reads, the output matches your way of working instead of a generic one. This guide maps what counts as a convention, the places it can live, and how to decide what goes where.
How do you make an AI agent follow your conventions?
You write them down once, in a place the agent reads automatically: an agent instruction file in your project, the site’s Context page, a skill stored on the site, or memory that persists between sessions. The agent then applies them in every conversation without being reminded, and everyone who connects an agent to the same site inherits the same rules.
What counts as a WordPress convention?
More than coding style. The conventions that pay off with an agent are the decisions you would otherwise repeat in every prompt:
- Code: standards, prefixes, where custom code lives, what is off limits.
- Builder and components: which builder, which version, which existing sections and templates to reuse instead of inventing new ones. Elementor before Bricks in your stack order, if that is your stack.
- Design tokens: the real color variables, type scale and spacing, so a new section uses your palette rather than an approximation of it.
- Content model: which post types and fields exist, what each is for, naming for new ones.
- Workflow: which environment to work on, what needs review, what the agent should never touch (payment settings, user data, that one legacy plugin).
Where can your conventions live?
Agent instruction files (AGENTS.md, CLAUDE.md)
Every coding agent reads a standing instruction file in the project: AGENTS.md as the cross-agent convention, CLAUDE.md for Claude Code, equivalents elsewhere. This is the right home for repository-level rules: how to run the project, code style, branch and deploy process. Its limit is its scope: it lives in one checkout, so it travels with the repo, not with the site, and a colleague connecting a different client from a different machine does not see it.
The site’s Context page
Novamira’s Context page (under Novamira > Context in the WordPress admin) holds instructions that every connected agent receives in every conversation, prepended to the system context Novamira generates for the site. This is the home for stable, site-wide guidance: brand voice, audience, builder of choice, deployment limits, things agents must avoid. It applies to every administrator’s agent, whatever client they use, and can be toggled on and off without losing the text. Keep passwords and one-off task notes out of it.
Skills: playbooks that fire on demand
Skills are short Markdown playbooks stored on the site. At session start the agent skims only each skill’s one-line description; when your prompt matches one, the body loads and the agent follows it. That makes skills the home for procedures rather than facts: “how we build a landing page”, “how we add a product”, “how we write a news post”. Author once and every admin’s agent follows the same playbook. You do not have to learn the format: Novamira ships a skill-creator, so “create a skill that does X” produces a first draft you review and save from the admin.
Memory: what the agent learns as it works
Conventions you wrote down are half the picture; the other half is what emerges while working: that this site’s header is a template part, that the client prefers short excerpts, that one plugin misbehaves when autoloaded. Novamira Pro keeps per-site memory between sessions, so what the agent learns on Monday is still known on Friday, by every connected agent. The details are on the Pro page and in the memory docs.
What goes where
| Convention | Best home | Why |
|---|---|---|
| Code style, repo workflow | AGENTS.md / CLAUDE.md | Belongs to the repository and travels with it |
| Brand voice, site rules, hard limits | Context page | Applies to every conversation, every client, every admin |
| Repeatable procedures | Skills | Loaded only when the task matches, cheap to keep many |
| What emerges while working | Memory (Pro) | Accumulates on its own, persists between sessions |
The duplication test: if you find yourself pasting the same paragraph into prompts, it belongs on the Context page; if you keep re-explaining the same procedure, it is a skill; if the agent keeps rediscovering the same site fact, that is what memory is for.
A worked example
A small agency that builds Elementor sites might end up with: an AGENTS.md in each project repo with the PHP prefix and the deploy steps; a Context page saying which plugins are under the agency’s ownership, that new sections reuse the site’s global styles, and that nothing is installed without approval; a “landing page” skill with the agency’s section order and copy rules; and Pro memory quietly accumulating each site’s quirks. None of these is long. Together they are the difference between an agent that asks and an agent that already knows, and the result is fewer retries, fewer surprises.
Where to start
Start with the Context page: ten lines about the site, the builder, and what to avoid already change the quality of every session. Add a skill the second time you explain the same procedure. The Context docs and Skills docs have the details, and the Claude Code guide shows where instruction files fit in a developer workflow.