wordpress-plugin-publish

Use this skill when publishing, submitting, reuploading, verifying, packaging, checking, demoing, or releasing WordPress.org plugins with Pressship. It covers…

npx skills add https://github.com/automattic/pressship --skill wordpress-plugin-publish

WordPress Plugin Publish

Use Pressship for WordPress.org plugin submission and release work. Prefer npx pressship unless the user explicitly wants the local checkout version or the WP-CLI package (wp ship).

Install Surfaces

Use the install surface the user asks for:

npx pressship verify .
wp package install f/pressship
wp ship verify .
npm install -g pressship
pressship verify .

For agent skill installation:

npx skills add f/pressship --skill wordpress-plugin-publish -a codex
npx skills add f/pressship --skill wordpress-plugin-publish -a claude-code

Safety Rules

  • Never publish, submit, reupload, or release without first running a dry run, unless the user explicitly says to skip it.
  • Do not push git commits or tags unless the user explicitly asks.
  • Report Plugin Check findings clearly. Do not hide them just because Pressship can continue.
  • Use repeatable excludes for large or source-only files. Prefer .pressshipignore when the project already has one.
  • Use --no-verify only when the user explicitly asks to bypass readme validation and Plugin Check.
  • If Pressship prompts interactively, answer only with user-approved or obvious plugin metadata.
  • If authentication fails, run npx pressship login and let the user complete WordPress.org login.
  • For approved-plugin SVN releases, expect Pressship to verify before SVN changes, reject already-published versions, and ask for a generated WordPress.org SVN password when needed.

Orientation

From the plugin directory:

npx pressship whoami
npx pressship verify .
npx pressship status .
npx pressship info .
npx pressship info --remote

Use status to determine whether publish will target a pending submission reupload or an approved SVN release. Use verify when you need readme validation and Plugin Check without creating a zip.

Local Playground Test

Start a local WordPress Playground with the plugin mounted:

npx pressship demo .

Useful options:

npx pressship demo . --port 9401
npx pressship demo . --wp 6.8 --php 8.3
npx pressship demo . --reset
npx pressship demo . --skip-browser

Verify And Package

Run the publishing checks without creating a zip:

npx pressship verify .

Create a validated WordPress-installable zip without uploading:

npx pressship pack .

For projects with bulky assets or source-only files, pass explicit ignores:

npx pressship pack . --ignore "assets/**" --ignore "src/**" --ignore "node_modules/**"

pack, publish, submit, and SVN release verify by default. If the user explicitly chooses to bypass checks, use the unified flag:

npx pressship pack . --no-verify
npx pressship publish . --no-verify

Inspect package file count and included paths. Make sure the ZIP contains runtime PHP, built assets, readme.txt, and any required examples or static assets. Confirm .pressship-svn is never included.

Submit Or Reupload Pending Review

Use this for new plugins or WordPress.org submissions still awaiting review.

Dry run first:

npx pressship publish . --dry-run -y

Then upload:

npx pressship publish . -y

When the project contains large non-distribution directories, repeat the same ignore flags in both commands:

npx pressship publish . --dry-run -y \
  --ignore "assets/**" \
  --ignore "src/**" \
  --ignore "scripts/**" \
  --ignore "package.json" \
  --ignore "package-lock.json" \
  --ignore ".github/**" \
  --ignore "node_modules/**" \
  --ignore "dist/**"

npx pressship publish . -y \
  --ignore "assets/**" \
  --ignore "src/**" \
  --ignore "scripts/**" \
  --ignore "package.json" \
  --ignore "package-lock.json" \
  --ignore ".github/**" \
  --ignore "node_modules/**" \
  --ignore "dist/**"

After upload, confirm:

npx pressship status .

Release Approved Plugin

Use this only when the plugin is already approved and the user wants a WordPress.org release.

For an existing WordPress.org plugin, the normal SVN-based edit flow is:

npx pressship get my-plugin ./my-plugin
cd ./my-plugin
npx pressship version patch
npx pressship publish --release --dry-run -y
npx pressship publish --release -y

Pressship treats the SVN checkout root as the project root and edits trunk/. It should stop with "No version change detected" if the target tag already exists.

Dry run first:

npx pressship publish . --release --dry-run -y

Then release:

npx pressship publish . --release -y

If Pressship cannot infer the slug or username:

npx pressship release . --slug my-plugin --username WpOrgUser --dry-run
npx pressship release . --slug my-plugin --username WpOrgUser -y

If svn is missing, let Pressship detect the OS and offer installation, or pass --no-install-svn only when the user wants manual setup. If the SVN password is missing, Pressship points to the user's WordPress.org SVN password page and saves the generated password locally after they provide it.

Version Bumps

Only run version bumps when the user asks:

npx pressship version patch .
npx pressship version minor .
npx pressship version major .

After a version bump, review changed plugin headers, readme.txt stable tag, and changelog.

Final Report

Always include:

  • Whether a dry run was run.
  • Whether verify ran and whether validation was bypassed.
  • Package size and notable included/excluded files.
  • Plugin Check result summary.
  • Upload/release status and slug.
  • SVN checkout/tag status for approved releases.
  • Whether git was left untouched or changed.

Plus de skills de automattic

wp-phpstan
automattic
À utiliser lors de la configuration, de l'exécution ou de la correction de l'analyse statique PHPStan dans des projets WordPress (plugins/thèmes/sites) : configuration de phpstan.neon, baselines,…
official
wp-playground
automattic
Utiliser pour les workflows WordPress Playground : instances WP jetables rapides dans le navigateur ou localement via @wp-playground/cli (server, run-blueprint, build-snapshot),…
official
wp-plugin-development
automattic
À utiliser lors du développement de plugins WordPress : architecture et hooks, activation/désactivation/désinstallation, interface d'administration et API de réglages, stockage de données, cron/tâches, sécurité…
official
wp-project-triage
automattic
À utiliser lorsque vous avez besoin d'une inspection déterministe d'un dépôt WordPress (plugin/thème/thème de blocs/WP core/Gutenberg/site complet) incluant les outils/tests/versions…
official
wp-rest-api
automattic
À utiliser lors de la création, de l'extension ou du débogage des points de terminaison/routes de l'API REST WordPress : register_rest_route, classes WP_REST_Controller/controller, schéma/arguments…
official
wp-wpcli-and-ops
automattic
À utiliser lors du travail avec WP-CLI (wp) pour les opérations WordPress : recherche-remplacement sécurisé, export/import de base de données, gestion des plugins/thèmes/utilisateurs/contenu, cron, vidage du cache,…
official
wpds
automattic
À utiliser lors de la création d'interfaces utilisateur exploitant le WordPress Design System (WPDS) et ses composants, tokens, motifs, etc.
official
woocommerce-finalize
automattic
Audit de santé du code et de traçabilité en pré-libération pour les plugins WooCommerce. S'exécute après la revue de code -- se concentre sur le code mort, la duplication, la complexité structurelle, et…
official