/wp-org-submission

name: wp-org-submission
description: "Use when submitting a WordPress plugin to the WP.org directory for the first time, deploying a new version via SVN (plugins.svn.wordpress.org trunk, tags, assets), fixing a reviewer rejection (17-issue catalog with exact reviewer quotes), writing or correcting readme.txt (Stable tag, Changelog, Upgrade Notice, Requires, Tested up to, External services), or preparing WP.org assets (banner-772x250.png, banner-1544x500.png, icon-128x128.png, icon-256x256.png, icon.svg, screenshot-N.png). Triggers: \"submit my plugin to WP.org\", \"SVN deploy\", \"reviewer rejected my plugin\", \"fix WP.org review feedback\", \"how do I set up the SVN repo\", \"WP.org assets\", \"prepare my plugin for the directory\", \"what does the reviewer want\", \"Stable tag\", \"readme.txt requirements\", \"WP.org banner dimensions\", \"fix this reviewer comment\", \"plugin zip for submission\", \"svn commit trunk\", \"svn cp trunk tags\", \"reviewer says missing nonce\", \"reviewer says not prefixed\", \"reviewer says missing sanitization\", \"Upgrade Notice section\", \"External services section in readme\", \"submit.wordpress.org form\", \"icon.svg for WP.org\". For WP.org guideline compliance review only, use `wp-plugin-directory-guidelines` instead."

WordPress.org Plugin Submission & SVN Deploy

> **Model note:** SVN deploy steps and asset setup are mechanical (`haiku`). Pre-submission rejection-pattern scan across a real codebase (17 patterns) requires code judgment — use `sonnet`. Responding to a human reviewer rejection also needs `sonnet`.

Get a plugin into the WP.org directory and keep releasing to it. Two distinct phases — know which one applies:

• **Phase 1 — Initial submission.** Plugin not yet in the directory. One-time human review, then SVN access is granted.
• **Phase 2 — SVN deploy.** Plugin already approved. Ship a new version into the existing SVN repo.

`wp-org-submission` is about the *directory/SVN side*. Sync the version sources first with [[wp-plugin-release]] — this skill assumes the codebase already carries the target version.

When to use

• "Submit this plugin to WordPress.org", "publish to the .org directory", "add my plugin to wp.org".
• "Deploy the new version to SVN", "push the release to wp.org", "tag a release on plugins.svn".
• "Set up screenshots / banner / icon", "why aren't my assets showing".
• "Fix a WP.org rejection", "respond to plugin review email", "they flagged trialware / source code / external service".
• Pre-submission hygiene sweep using the 17-issue rejection catalog (real reviewer quotes).

**Not for:** "will this pass WP.org review?", "check guideline violations", "is my plugin GPL-compliant?" — use the official `wp-plugin-directory-guidelines` skill for authoritative 18-guideline compliance review. This skill owns the *workflow* (SVN, assets, rejections); that skill owns the *rules*.

Phase 1 — Initial submission

The review is done by humans and can take days to weeks. Submitting a clean plugin avoids round-trips.

1. **Slug availability** — the directory slug is derived from the plugin name in the main file header. Pick a name not already taken at `https://wordpress.org/plugins/<slug>/` (404 = free). Slug is permanent. 2. **readme.txt valid** — must parse in the official validator: `https://wordpress.org/plugins/developers/readme-validator/`. Required header fields, valid `Stable tag`, GPL-compatible `License`. See `references/submission-checklist.md`. 3. **Guidelines compliance** — sanitize input, escape output, nonce-protect actions, prefix all globals, no obfuscation/minified-only code, no external loading of scripts, no tracking or calling home without explicit opt-in consent, GPL-compatible code + assets only. Full checklist in `references/submission-checklist.md`. 17-issue catalog with exact reviewer quotes in `references/review-issues-catalog.md`. 4. **Build a clean zip** — source files (`src/`, `composer.json`, build configs) must be included; `.wordpress-org/` and `node_modules` must not. Full include/exclude lists in §4 of `references/submission-checklist.md`. 5. **Submit** at `https://wordpress.org/plugins/developers/add/`. The reviewer replies by email. Fix what they flag, reply briefly (context only, no change list), attach the updated zip. On approval, SVN access is granted at `https://plugins.svn.wordpress.org/<slug>/`.

Phase 2 — SVN deploy

WP.org distributes via **Subversion**, not git. The SVN repo has three top-level dirs:

<slug>/
├── trunk/        # current development copy of the plugin
├── tags/         # one immutable dir per released version (tags/1.2.0/)
└── assets/       # directory listing images — NOT shipped in the plugin zip

**The `Stable tag` in `trunk/readme.txt` decides what users download** — it must name a directory under `tags/`. Set `Stable tag: 1.2.0` and ensure `tags/1.2.0/` exists. (Pointing Stable tag at `trunk` is legal but discouraged — always release from a tag.)

Deploy = copy the production build into `trunk/`, then `svn cp trunk tags/<version>`, then commit. Use the helper:

scripts/svn-deploy.sh <slug> <path-to-built-plugin-dir> <version>

It checks out SVN, syncs `trunk/` to the build (adding/removing files), copies `trunk` → `tags/<version>`, and prints the `svn commit` to run after review. Full manual walkthrough and the add/delete handling in `references/svn-deploy.md`.

**Assets** (banner, icon, screenshots) live only in `assets/`, never in the zip. Exact filenames and dimensions are mandatory — `banner-772x250.png`, `banner-1544x500.png` (retina), `icon-128x128.png`, `icon-256x256.png`, `icon.svg`, `screenshot-1.png` (matched to the `1.` line under `== Screenshots ==` in readme.txt). See `references/svn-deploy.md`.

Top rejection patterns

Most frequent — not exhaustive. Full 17-issue catalog with exact reviewer quotes in `references/review-issues-catalog.md`.

• Generic or trademarked slug; "WordPress"/"Woo" in the plugin nam