Run any Skill in Manus with one click

wp-org-submission

Stars26

Forks3

UpdatedJuly 4, 2026 at 16:08

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", "Extern

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mralaminahamed

mralaminahamed/wp-dev-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

7 files

SKILL.md

readonly

name

wp-org-submission

description

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.

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.
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.
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.
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.
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 name.
Main PHP file name doesn't match the slug (plugin.php instead of <slug>.php).
Invalid URLs in plugin header or readme.txt — verify with curl -I before submission.
External service called but not documented in == External services ==.
Unsanitized $_GET/$_POST, unescaped output, missing nonces + capability checks.
Loading JS/CSS from a CDN instead of bundling; inline <style> / <script> tags.
No source for compiled output — src/ not in zip and no public repo linked.
.wordpress-org/ or node_modules/ in the zip.
Generic function/class prefix or mixed prefixes across one plugin.
Trialware (Guideline 5) — features gated behind license key or Pro plan check. See references/trialware-compliance.md.
Admin notices on every screen, persistent nags, full-page upsell flows (Guideline 11).
Stable tag names a tag that doesn't exist under tags/ → users get nothing.

References

references/submission-checklist.md — comprehensive pre-submission checklist (identity, readme.txt, guidelines, zip hygiene, security pattern, automated checks).
references/review-issues-catalog.md — 17-issue catalog with exact reviewer quotes and corrective actions, sourced from 8 real submissions.
references/trialware-compliance.md — Guideline 5 freemium pattern, audit checklist, and step-by-step licensing-layer removal.
references/svn-deploy.md — complete SVN workflow, asset spec, Stable-tag mechanics, hotfix flow.
scripts/svn-deploy.sh — git/build → SVN trunk+tag deploy helper.
Official: wp-plugin-directory-guidelines (WordPress/agent-skills) — authoritative source for the 18 WP.org Plugin Directory guidelines; use it for GPL/naming/trialware rule interpretation when our 17-issue catalog conflicts or is ambiguous.

More from this repository

same repository

wp-ci-qa

mralaminahamed/wp-dev-skills

Use when a pull request has QA failures, a "Testing Failed" label, or QA comments reporting broken features — reading QA feedback and PR comments, tracing root cause using root-cause-patterns.md, applying scoped conventional-commit fixes, swapping labels (Testing Failed to Need Testing), and posting a structured QA re-test comment. Triggers: "QA failed my PR", "Testing Failed label on my PR", "fix the QA comments on PR", "QA says feature X is broken", "post a re-test comment", "how do I respond to QA feedback", "CI is failing on my PR", "QA reopened the ticket", "update the PR label after fixing", "testing failed label", "QA comment says the button is broken", "phpcs failing in CI", "yarn lint error on the PR", "npm run build failing in CI", "root cause of the QA failure", "write a re-test instruction comment", "fix failing checks on this PR", "QA triage workflow", "phpcs prints nothing and exits 0", "composer run test produces no output", "phpstan workers keep crashing", "did my static checks actually run",

2026-07-2026

wp-woocommerce

mralaminahamed/wp-dev-skills

Use when building, extending, or debugging a WooCommerce plugin — custom product types, payment gateways (WC_Payment_Gateway, process_payment(), process_refund()), shipping methods (WC_Shipping_Method, calculate_shipping()), CRUD via WC_Product / WC_Order / WC_Customer (wc_get_product, wc_create_order, wc_get_orders, get_meta, update_meta_data), HPOS compatibility (FeaturesUtil::declare_compatibility, wc_get_orders instead of WP_Query on posts), REST API extensions (woocommerce_rest_prepare, woocommerce_rest_pre_insert, Store API woocommerce_store_api_register_endpoint_data), cart/checkout blocks (registerCheckoutFilters, extensionCartUpdate, SlotFills), key hooks (woocommerce_cart_calculate_fees, woocommerce_checkout_fields, woocommerce_order_status_changed, woocommerce_payment_gateways), or WooCommerce subscription/coupon/webhook logic. Triggers: "WooCommerce extension", "custom product type", "payment gateway", "hook into WooCommerce checkout", "WC_Order", "wc_create_order()", "wc_get_product()", "add a sh

2026-07-2026

wp-background-processing

mralaminahamed/wp-dev-skills

Use when a WordPress plugin needs to run work outside the HTTP request cycle — scheduling async or recurring jobs with Action Scheduler (as_enqueue_async_action, as_schedule_single_action, as_schedule_recurring_action, as_unschedule_action), implementing WP_Background_Process (push_to_queue, save, dispatch, is_queue_empty), registering WP Cron events (wp_schedule_event, wp_clear_scheduled_hook), batch-processing large datasets without hitting PHP timeouts, tracking job progress, handling retries on failure, or debugging the actionscheduler_actions table. Triggers: "schedule this for later", "run this without hitting timeout", "queue these items for background processing", "why is my cron not running", "Action Scheduler job keeps failing", "as_enqueue_async_action", "WP_Background_Process", "push_to_queue", "dispatch the queue", "DISABLE_WP_CRON", "process records in batches", "send emails in the background", "WP Cron not firing", "batch import without timeout", "scheduled action not running", "background job

2026-07-2026

wp-build-tools

mralaminahamed/wp-dev-skills

Use when setting up, configuring, or debugging the JavaScript/CSS build pipeline for a WordPress plugin — @wordpress/scripts, webpack (webpack.config.js, entry points, externals), Vite, block editor asset compilation with block.json, enqueueing built assets with .asset.php dependency files, wp_enqueue_script / wp_localize_script, Sass/SCSS/PostCSS compilation, TypeScript support, register_block_type, or reusing a JS/CSS library already bundled by a host plugin (EDD, WooCommerce, Elementor). Triggers: "npm run build fails", "webpack config error", "my script is not loading", "set up @wordpress/scripts", "enqueue my block assets", "why is my CSS not compiling", ".asset.php not found", "how do I reuse this bundled library", "TypeScript in a WP plugin", "block.json attributes", "missing dependency in build", "wp_enqueue_script not loading", "externals in webpack", "Vite for WordPress", "Sass not compiling", "PostCSS setup", "build output is in the wrong folder", "npm ci vs npm install", "externalize React from my

2026-07-0426

wp-coding-standards

mralaminahamed/wp-dev-skills

Use when setting up PHPCS with WordPress Coding Standards (WPCS), configuring phpcs.xml.dist, running phpcs/phpcbf, fixing sniff violations, adding PHPCS to CI (GitHub Actions), configuring IDE integration, or verifying a plugin meets WP.org code style requirements. Covers squizlabs/php_codesniffer, wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer, WordPress-Extra, WordPress-Docs, WooCommerce-Core rulesets. Triggers: "phpcs error", "WPCS violation", "fix my code style", "set up PHPCS", "configure phpcs.xml.dist", "my code fails PHPCS", "add linting to CI", "WordPress.Security.EscapeOutput sniff", "WordPress.WP.I18n error", "WordPress.NamingConventions sniff", "how do I ignore a phpcs rule", "phpcbf auto-fix", "phpcs in GitHub Actions", "add PHPCS to pre-commit hook", "vendor/bin/phpcs -i", "WordPress-Extra ruleset", "WordPress-Docs ruleset", "WooCommerce sniff", "phpcs.xml.dist example", "phpcs says my spacing is wrong", "fix indentation for WP standards", "PHPCS not finding WPCS", "de

2026-07-0426

wp-plugin-audit

mralaminahamed/wp-dev-skills

Use when auditing a WordPress plugin for security issues, code inconsistencies, or quality gaps — fans out parallel checks across four dimensions: A (version/metadata sync), B (naming/prefix/i18n), C (docs vs code), D (code conventions/security), verifies every finding with file:line references before reporting, and routes confirmed issues to the correct fix skill. Security patterns checked: XSS (missing esc_html/esc_attr), SQL injection (raw $wpdb), CSRF (missing nonce), missing capability checks, file upload validation, object unserialize, open redirect, path traversal, REST auth hardening. Triggers: "audit this plugin", "find inconsistencies in my plugin", "security review", "check my plugin for XSS", "is my escaping correct", "find missing nonces", "check capabilities in my plugin", "audit readme.txt", "find security issues", "plugin quality sweep", "are there SQL injection risks", "review my plugin before submission", "missing esc_html()", "raw wpdb query without prepare()", "missing current_user_can()",

2026-07-0426

name

wp-org-submission

description

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).

Phase 1 — Initial submission

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

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.
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.
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.
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.
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

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>

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 name.
Main PHP file name doesn't match the slug (plugin.php instead of <slug>.php).
Invalid URLs in plugin header or readme.txt — verify with curl -I before submission.
External service called but not documented in == External services ==.
Unsanitized $_GET/$_POST, unescaped output, missing nonces + capability checks.
Loading JS/CSS from a CDN instead of bundling; inline <style> / <script> tags.
No source for compiled output — src/ not in zip and no public repo linked.
.wordpress-org/ or node_modules/ in the zip.
Generic function/class prefix or mixed prefixes across one plugin.
Trialware (Guideline 5) — features gated behind license key or Pro plan check. See references/trialware-compliance.md.
Admin notices on every screen, persistent nags, full-page upsell flows (Guideline 11).
Stable tag names a tag that doesn't exist under tags/ → users get nothing.

References

references/submission-checklist.md — comprehensive pre-submission checklist (identity, readme.txt, guidelines, zip hygiene, security pattern, automated checks).
references/review-issues-catalog.md — 17-issue catalog with exact reviewer quotes and corrective actions, sourced from 8 real submissions.
references/trialware-compliance.md — Guideline 5 freemium pattern, audit checklist, and step-by-step licensing-layer removal.
references/svn-deploy.md — complete SVN workflow, asset spec, Stable-tag mechanics, hotfix flow.
scripts/svn-deploy.sh — git/build → SVN trunk+tag deploy helper.
Official: wp-plugin-directory-guidelines (WordPress/agent-skills) — authoritative source for the 18 WP.org Plugin Directory guidelines; use it for GPL/naming/trialware rule interpretation when our 17-issue catalog conflicts or is ambiguous.