AI can write a plugin before lunch. Whether you should install it after lunch is a different question. WordPress plugin requirements cover more than getting a PHP file to activate: the code needs appropriate permissions, safe data handling, honest documentation, and a release you have actually checked.
WordPress.org official rules and guidelines you must abide by are documented, but going through them will take plenty of time, and these specific rules for the AI can accelerate the process. They are current at this time, but as the bar moves, they may become obsolete, and I’ll need to keep up with the changes.
Naturally, nothing stops you from making your own edits to them.
The short answer: Define the plugin’s behavior, users, data, and external services before asking AI to code. Load technical rules first, make small changes, and review each change against the permissions and data it touches. Use WordPress APIs, run automated checks and functional tests, investigate every finding, then inspect the release package.
If you want WordPress.org distribution, review its directory policies separately. The developer remains responsible; neither an AI assistant nor a clean Plugin Check report takes that responsibility away.
This guide covers AI WordPress plugin development for developers, agencies, and technically comfortable site owners. It is about building plugins with AI, rather than choosing plugins that add AI features to a website.
In this article
WordPress plugin requirements: four separate checks
Start with the minimum, then build beyond it
Why AI-generated plugin code can fail review
Load the rules before asking AI to code
Security rules to give the AI before implementation
Directory rules secure code alone cannot satisfy
Plugin Check is a gate, not a verdict
A verification matrix worth keeping
A reusable prompt for your AI coding assistant
WordPress plugin requirements: four separate checks
A compliant WordPress plugin meets the technical and distribution requirements that apply to its intended use. A private integration and a public directory plugin share security concerns, but directory distribution adds its own policies. Treat compliance as several checks with different evidence, rather than one reassuring green label.
| Layer | What it covers | Who or what checks it | What passing does not prove |
|---|---|---|---|
| Valid structure | Recognizable plugin file and header | WordPress and header checks | That any useful behavior works safely |
| Secure, maintainable code | Permissions, data handling, APIs and readable implementation | Developer review, analyzers, and tests | Directory eligibility or absence of vulnerabilities |
| Directory policy | Licensing, services, privacy, presentation and naming | WordPress.org policy and manual review | That every future version is safe |
| Verified release | Tested behavior and the files actually distributed | Test matrix, package inspection and release owner | Correct behavior in every possible environment |
A plugin that activates has passed a very small audition. Keep the remaining checks on the schedule.
Four separate checks. Passing one does not prove the others.
Start with the minimum, then build beyond it
The Learn WordPress plugin requirements lesson explains the minimum: a PHP file with an opening PHP tag and a header containing Plugin Name. That makes a plugin recognizable. It does not supply permissions, input handling or useful functionality.
For a maintained project, follow the plugin header requirements: provide an accurate version, description, author, license, and supported WordPress/PHP versions. Add dependencies and translation information where appropriate. Compatibility claims should come from testing, not from an AI assistant choosing pleasantly low version numbers.
Give the plugin its own directory and use distinctive prefixes or namespaces to prevent collisions. Separate the bootstrap, request handlers, business logic, and assets as the project grows. WordPress’s plugin best practices provide the starting point; a tiny plugin does not need a ceremonial collection of empty classes.
An ABSPATH guard can stop a PHP file from executing directly outside WordPress. It cannot authorize an action, prevent every vulnerability, or protect source files when a broken server sends PHP as plain text. In that last case, PHP never executes the guard.
Why AI-generated plugin code can fail review
These are review targets, not claims that every model makes the same mistakes. The problem is usually a missing requirement hiding inside otherwise convincing code.
A settings screen may sanitize text but accept an array where it expects a string. A delete handler may verify a nonce while never checking whether the user may delete that particular record. A REST endpoint may hide its button from subscribers yet remain callable directly. The REST endpoint documentation describes separate argument validation and permission callbacks for a reason.
Other trouble spots include request values assembled into SQL, arbitrary download URLs, uploads accepted because their filenames look harmless, and diagnostic responses containing secrets. The presence of a sanitizer somewhere nearby is not evidence that the entire operation is safe.
Review the package as well as the code. Bundled dependencies need provenance; external requests need a clear purpose; development notes and test credentials should not drift into a customer download. An AI assistant can produce a polished readme while documenting behavior the implementation does not have. Read both side by side.
Load the rules before asking AI to code
I created the public wp-compliance skill to make technical review expectations reusable. The revision examined for this article contains 28 numbered rules. It covers input, output, access control, SQL, files, remote requests, secrets, and release hygiene.
It is an opinionated instruction layer, not an official WordPress standard, vulnerability scanner, or approval certificate. It does not assess branding, trademarks, plugin names, or slugs. Some rules deliberately favor conservative, statically recognizable code. Current official documentation and the actual application behavior still need to be checked.
Use this workflow whether you use that skill or maintain your own checklist:
1. Define features, roles, stored data, external services, and explicit non-goals.
2. Identify trust boundaries: every place outside data enters, privileges change, or information leaves.
3. Read the compliance rules before generating code or assigning implementation work.
4. Give each implementer and reviewer the same checklist and project-specific constraints.
5. Request one small, reviewable change at a time.
6. Inspect the diff and test successful, rejected, and hostile requests.
7. Run syntax, standards, Plugin Check, and functional checks.
8. Classify findings as defects, justified false positives, or documented items outside the agreed scope.
9. Build and inspect the exact release artifact.
10. Have the developer make the release decision from the evidence.
The skill explicitly requires its controller to load the rules before dispatching coding agents and pass its checklist to implementers and reviewers. In a single-agent session, the same principle applies: load the constraints before the first change. Saying “follow the skill” afterward is rather like adding the seat belt to the accident report.
Record the revision used and keep the test output. An instruction acknowledgement is useful context; it is not a test result.
Review findings return to the next small change. Release remains a human decision.
Security rules to give the AI before implementation
Start with the WordPress plugin security handbook and its linked Common APIs guidance, then map those principles to the actual feature.
Validate shape, sanitize deliberately, escape late
Define the expected type, range, length, and allowed values of each input. Reject an array where a scalar is required, and reject unknown keys where the contract requires a closed set. WordPress’s validation guidance favors checking against known acceptable values where possible.
Sanitization cleans data according to a purpose; it does not decide whether that data belongs in the operation. A cleaned email address can still belong to the wrong account.
Apply context-specific escaping at output. HTML text, HTML attributes, and URLs need their respective handling. Allowed HTML needs an explicit tag policy. Storing a value successfully does not make it safe to print into every context later.
Capabilities and nonces have different jobs
Check the capability appropriate to the operation, including the target object where relevant. Being logged in is insufficient, and hiding a menu is not endpoint protection.
For applicable browser-driven state changes, also verify a nonce to help prevent cross-site request forgery (CSRF). WordPress nonces do not authenticate users or grant permission. Other authenticated request designs need their own appropriate protection; do not bolt a browser nonce onto every integration without understanding its authentication model.
Keep SQL values separate from SQL structure
Prefer suitable WordPress APIs. When SQL is necessary, use wpdb::prepare() with the right placeholders and allowlist selectable identifiers and directions. Build LIKE search patterns with esc_like() before passing them as values.
The skill prefers static query templates for analyzer visibility. That is a conservative project convention, not proof that every dynamically composed, correctly parameterized query is insecure. Review correctness and query performance as well as the report.
Decode JSON according to its source
Decode JSON before validating and sanitizing its fields. Do not run a plain-text sanitizer across the encoded document. Validate nested structures and every leaf value; a cast to an array does not do that work.
One qualification matters: a JSON string inside a WordPress-slashed form field differs from a raw REST request body. WordPress’s REST JSON parser decodes the body directly. Do not automatically unslash raw JSON or already-decoded REST parameters. wp_unslash() recursively removes slashes; it does not validate or sanitize an array. These distinctions qualify the skill’s shorthand instructions.
Constrain uploads, paths and remote requests
Treat filenames, supplied paths, file types and remote responses as untrusted. Use WordPress upload handling as part of a deliberately restricted upload flow, with permission checks and safe storage.
For remote requests, restrict destinations to what the feature needs. wp_safe_remote_get() validates the URL and redirects to help reduce server-side request forgery (SSRF). It does not replace your service allowlist, response limits or decision about which data may leave the website.
Keep secrets and cleanup out of the guesswork
Never place private API keys in generated source, public JavaScript, or browser-facing error messages. Review logs and downloadable diagnostics for sensitive values and access controls. “Debug only” becomes an awkward explanation when the debug file is publicly readable.
Define retention and deletion behavior before implementing it. Follow the uninstall methods documentation, including the WP_UNINSTALL_PLUGIN check for an uninstall.php entry point. Do not casually delete business data on deactivation. Test both the chosen cleanup and the data you deliberately retain.
Directory rules secure code alone cannot satisfy
For public distribution, read the Detailed Plugin Guidelines. Check GNU General Public License (GPL) compatibility, third-party licenses, and service terms. Provide readable source/build access and a stable directory version.
Trialware is prohibited; substantive, documented software as a service (SaaS) can qualify. Document external communication and appropriate consent, including service provisions. Remote requests are not automatically tracked.
Review external-code and asset restrictions. Use WordPress-provided libraries where required. Make front-end credits opt-in and notices restrained and dismissible where required. Avoid readme spam; disclose affiliate links. Submit a complete plugin. Review names, slugs, and trademarks separately; my technical skill does not handle them.
Use no more than five relevant tags and follow the readme requirements for the actual listing. The main PHP header supplies minimum WordPress and PHP requirements. Keep release metadata consistent and use a versioned stable tag; the handbook prohibits Stable tag: trunk for new plugins.
Treat Subversion (SVN) as the directory’s release system. Increment versions for new releases, inspect trunk and tags, and keep everyday development elsewhere. Review what users will download, including dependencies and generated files, rather than trusting the working directory you happened to test.
Plugin Check is a gate, not a verdict
Plugin Check runs directory-oriented checks and additional best-practice checks. Open Tools → Plugin Check, or use its documented wp plugin check command. Record which categories ran; a repository-focused run is not the same as every available check.
As checked on 22 September 2026, its documentation says command-line runs are static by default; runtime checks need the documented --require setup. It also describes optional AI review of selected findings, an SVN Checker, and a separate AI Plugin Namer requiring WordPress 7.0+ and configured AI connectors. Naming feedback remains advisory and outside my skill’s scope.
False positives happen. Prefer a clearer, safer implementation; use a narrowly scoped suppression only when you can explain the false positive. Keep the original finding and justification. Passing does not guarantee security or manual approval.
My review rule is simple: ask the assistant what changed, why the report appeared, and what test supports the fix. A warning disappearing after an entire directory was excluded is not the evidence I am looking for.
A verification matrix worth keeping
Use this as a project checklist. Scale the tests to the plugin’s behavior and risks, and retain evidence against the actual release revision. PHP_CodeSniffer (PHPCS) with WordPress Coding Standards complements functional review; it cannot understand your entire business model.
| Check | Tool or method | Evidence to keep | What it cannot prove |
|---|---|---|---|
| Syntax and build | PHP lint; applicable JS/build checks | Versions, commands and output | Correct runtime behavior |
| Coding standards | PHPCS and WordPress rules | Findings and justified exceptions | Complete security |
| Directory and general checks | Plugin Check; record categories | Report, version and runtime coverage | Manual acceptance |
| Unit and integration behavior | Tests for the implemented features | Cases, fixtures and results | Unwritten expectations |
| REST/AJAX and roles | Permission matrix; malformed and hostile input | Allowed/denied cases and side effects | Every possible attack |
| Lifecycle | Install, activate, upgrade, deactivate, uninstall | Data and scheduled-task checks | Every migration history |
| Claimed compatibility | Supported PHP/WordPress; multisite if claimed | Environment matrix and results | Untested combinations |
| External data and privacy | Request inspection and consent review | Destinations, payloads and retention | Legal compliance |
| Dependencies and licensing | Source, asset and license audit | Versions, provenance and build instructions | Future dependency safety |
| Names and trademarks | Separate official-policy/human review | Decisions and outstanding questions | Approval by the technical skill |
| Release contents | ZIP/SVN inspection and secret scan | File inventory and artifact hash | Secrets a scanner misses |
| Release hygiene | Consistent line endings; development-file review | Checked files and exclusions | Functional correctness |
| Final human review | Diff review and staging scenarios | Sign-off, limits and rollback plan | Universal compatibility |
Add a negative test for every permission boundary. Try a lower role, missing or invalid nonce where applicable, another user’s object, unexpected input types, and unavailable external services. Check that rejection prevents the action, rather than merely displaying an error after it happened.
Keep performance evidence separate from security evidence. Speed Analyzer can support website performance diagnosis; it is not a plugin-security certificate. Likewise, selecting WordPress speed optimization plugins is a different decision from verifying the code of a new one.
A reusable prompt for your AI coding assistant
Replace the bracketed project details. Supply the actual requirements and pin the skill revision you want reviewed. This is a starting instruction, not a substitute for supervising the result.
Build or update [plugin purpose] for [supported environments]. Before coding, read the official WordPress plugin requirements and directory guidelines, and this technical skill: https://github.com/2slowDD/claude-compliance-by-D/blob/main/skills/wp-compliance/SKILL.md Record the revision read. Identify conflicts with current official APIs; explain them before implementation. State assumptions and clarify permissions, data, external services and deletion behavior. Propose the files and small changes first. For each input, validate shape and allowed values, sanitize when needed, check authorization and applicable CSRF protection before acting, and escape output for its context. Handle JSON according to its source. Use appropriate WordPress APIs. Keep secrets out of code and logs. Give any implementer and reviewer the same requirements. Review small diffs. Define and run syntax, standards, Plugin Check, functional, permission and release-package checks. Report commands, coverage, findings and checks you could not run. Never hide unresolved warnings or claim guaranteed security or approval. Review branding and names separately against WordPress.org policy; the skill does not approve them. Do not publish, deploy or push without authorization.
Where AI helps, and where I keep the decision
AI is useful for scaffolding, repetitive API wiring, draft tests, documentation, and an additional diff review. Give it a concrete question: “Which requests can alter this option, and what authorizes each one?” That is more useful than asking whether the plugin looks secure.
Keep architecture, permissions, privacy, licensing, and release decisions with someone who understands the consequences. An assistant cannot resolve an unknown product requirement by confidently choosing a default. Record open questions while changes are still cheap.
My own products illustrate why behavior matters: AI Assets Scanner analyzes page assets, while Code Unloader applies asset-unloading rules. Analysis and changes need different verification. This is a product example, not a claim that either product was built under the skill revision discussed here.
My verdict
I created the compliance skill because technical expectations are easier to enforce when they exist before the first generated file. Developers and agencies using AI repeatedly can benefit from that consistency, provided they read the rules critically and verify the output.
It does not approve branding or plugin names, and it does not replace a security review or the WordPress.org team. Read the public repository, try the workflow on a disposable local project, and adapt it to the risks you actually have.
WordPress plugin requirements do not become optional because the code arrived quickly. Let AI help finish the plugin before lunch. Decide whether to install it after you have checked it.
Frequently asked questions
Can an AI-generated plugin be submitted to WordPress.org?
Yes. AI assistance does not remove the developer’s responsibility to meet the applicable directory requirements. Submit a complete plugin whose code, dependencies, behavior and documentation you have reviewed.
Does passing Plugin Check prove security or guarantee approval?
No. It is an automated check with limited coverage and possible false positives. It does not replace functional security testing or WordPress.org’s manual review.
Does wp-compliance check plugin names or branding?
No. Its scope is technical code compliance and security guardrails. Review names, slugs and trademarks separately against official guidance; naming assistance is not final approval.
Are paid SaaS services allowed in directory plugins?
They can be, when they meet the directory’s service requirements. A substantive documented service differs from locking locally included functionality behind payment. Check the actual implementation against the guidelines.
Do nonces replace capability checks?
No. Nonces help protect applicable requests against CSRF; capabilities determine permission. A valid nonce alone does not authorize a privileged action.
Founder of WPservice.pro
Dalibor is a master of web excellence. With a Bachelor of Science (BS) in civil engineering, Dalibor had an unusual road to end up in IT. Cultivating deep expertise in WordPress website speed optimization, meticulous maintenance, development, and search engine optimization (SEO) while preserving his engineering approach to problem-solving.
Having completed over 90 projects and achieved a top-rated status (on Upwork) in the highly competitive digital niche, Dalibor is a proper authority on enhancing performance and ensuring websites look exceptional and perform flawlessly.
Dalibor is a published writer and an avid learner who continually explores and embraces the latest digital trends. With a commitment to quality and a keen eye for detail, Dalibor is your trusted guide to achieving web success.