
wp-github-actions
Sets up GitHub Actions CI/CD workflows for WordPress plugins — coding standards (WPCS/PHPCS), PHP/JS/CSS linting, PHPUnit testing, static analysis (PHPStan), Composer security scanning, WordPress Playground PR previews, and automated deployment to WordPress.org. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for a WordPress plugin — even if they don't use the exact phrase "GitHub Actions". This includes any request to: add automated coding standards or PHPCS/WPCS checks to a WP plugin repo; set up linting (PHP, JS, CSS) for a WordPress plugin; configure PHPUnit testing in CI for a plugin; auto-deploy a plugin to WordPress.org from GitHub; add Playground previews to pull requests; add security scanning or static analysis to a plugin pipeline; or generally "add CI", "add automated checks", "set up workflows", or "automate" anything related to a WordPress plugin's GitHub repository. Also trigger
- Installs
- 43
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/jdevalk/skills --skill wp-github-actions- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads wp-github-actions automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
WordPress Plugin GitHub Actions
This skill helps you set up a comprehensive CI/CD pipeline for WordPress plugins using GitHub Actions. The goal is to help plugin authors ship higher-quality code with less manual effort.
What this skill covers
There are several categories of workflows that a healthy WordPress plugin should have. Not every plugin needs all of them — the right mix depends on the plugin's complexity, whether it has JavaScript/CSS assets, whether it uses Composer, etc. Your job is to figure out which ones are relevant and set them up.
The workflows fall into these categories:
- Code quality — WPCS/PHPCS checks, PHP linting, JS/CSS linting
- Testing — PHPUnit with WordPress test library
- Static analysis — PHPStan with WordPress extensions
- Dependency management — Composer diff on PRs, security scanning
- Preview — WordPress Playground PR previews
- Deployment — Automated deploy to WordPress.org on tag/release
Read references/workflows.md for the detailed configuration of each workflow, including ready-to-use YAML templates and configuration files.
How to approach a request
Step 1: Understand the plugin
Before writing any workflow files, figure out what you're working with:
- Does the plugin use Composer? Check for
composer.json. If yes, Composer-related workflows (diff, security, autoloading) are relevant. - Does it have JavaScript/CSS assets? Check for
package.json, any JS/CSS source files, or a build process. If yes, JS/CSS linting and possibly a build step matter. - Does it have tests? Check for a
tests/directory,phpunit.xml, orphpunit.xml.dist. If yes, set up the PHPUnit workflow. If not, mention that adding tests would be valuable but don't force it. - Is it on WordPress.org? Check for a
.wordpress-orgdirectory or ask. If yes, the deploy workflow is relevant and you should also set up.distignore. - What PHP versions should it support? WordPress itself requires PHP 7.4+, but many plugins target 7.4, 8.0, 8.1, 8.2, and 8.3. Check the plugin's readme or ask.
- What WordPress versions? Similarly, check what WP versions the plugin declares compatibility with.
Step 2: Recommend a set of workflows
Based on what you found, recommend which workflows to set up. A good default for most plugins:
- WPCS check (almost always)
- PHP lint (almost always — catches syntax errors across PHP versions)
- PHPUnit tests (if tests exist)
- Deploy to WordPress.org (if on WordPress.org)
- Playground PR preview (nice to have for any plugin)
And conditionally:
- JS/CSS linting (if the plugin has frontend assets)
- Composer diff + security (if using Composer)
- PHPStan (for plugins that want deeper static analysis)
Step 3: Create the workflow files
Create each workflow as a separate YAML file in .github/workflows/. Using separate files rather than one monolithic workflow gives clearer feedback in PRs (each check shows independently) and makes it easier to enable/disable individual checks.
Use the templates from references/workflows.md as starting points, but adapt them to the specific plugin. Common adaptations include adjusting PHP version matrices, changing the WPCS standard, adjusting file paths, and tweaking the deploy workflow for plugins with build steps.
Step 4: Create supporting config files
Depending on which workflows you set up, you may also need:
phpcs.xml.dist— Custom PHPCS ruleset (if the plugin needs rule exclusions or custom config).distignore— Files to exclude from WordPress.org deploymentphpstan.neonorphpstan.neon.dist— PHPStan configuration
Step 5: Set up secrets reminder
If you're adding the deploy workflow, remind the user that they need to configure two repository secrets in GitHub:
SVN_USERNAME— Their WordPress.org usernameSVN_PASSWORD— Their WordPress.org password
Walk them through: Repository Settings > Secrets and variables > Actions > New repository secret.
Naming conventions
Use descriptive workflow file names that make it obvious what each one does:
wpcs.yml— WordPress Coding Standardsphpunit.yml— PHPUnit testslint-php.yml— PHP syntax lintinglint-js-css.yml— JavaScript and CSS lintingphpstan.yml— Static analysiscomposer-diff.yml— Composer dependency diff on PRssecurity.yml— Composer security scanningplayground-preview.yml— WordPress Playground PR previewdeploy.yml— Deploy to WordPress.org
Important details
Branch naming: Many WordPress plugin repos use trunk as the default branch (mirroring WordPress.org SVN conventions), while others use main or master. Always check the actual repo and use the correct branch name in workflow triggers.
PHP version matrix: WordPress 6.x requires PHP 7.4+. A good default matrix is ['7.4', '8.0', '8.1', '8.2', '8.3'] for PHPUnit, but use only the latest stable PHP for WPCS and linting (they don't need a matrix).
WordPress version matrix: For PHPUnit, test against at least latest and consider adding the previous major version. Some plugins also test against nightly to catch upcoming issues early.
The 10up ecosystem: 10up maintains a set of well-maintained GitHub Actions specifically for WordPress. Prefer these over generic alternatives when they exist — they handle WordPress-specific edge cases well. The key ones are 10up/wpcs-action for coding standards and 10up/action-wordpress-plugin-deploy for deployment.
FAQ
What does the wp-github-actions skill do?
Sets up GitHub Actions CI/CD workflows for WordPress plugins — coding standards (WPCS/PHPCS), PHP/JS/CSS linting, PHPUnit testing, static analysis (PHPStan), Composer security scanning, WordPress Playground PR previews, and automated deployment to WordPress.org. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for a WordPress plugin — even if they don't use the exact phrase "GitHub Actions". This includes any request to: add automated coding standards or PHPCS/WPCS checks to a WP plugin repo; set up linting (PHP, JS, CSS) for a WordPress plugin; configure PHPUnit testing in CI for a plugin; auto-deploy a plugin to WordPress.org from GitHub; add Playground previews to pull requests; add security scanning or static analysis to a plugin pipeline; or generally "add CI", "add automated checks", "set up workflows", or "automate" anything related to a WordPress plugin's GitHub repository. Also trigger
How do I install wp-github-actions?
Run npx skills add https://github.com/jdevalk/skills --skill wp-github-actions in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/wp-github-actions/ (personal) or .claude/skills/wp-github-actions/ (project).
Which AI agents can use wp-github-actions?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is wp-github-actions safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains wp-github-actions?
It is published by jdevalk in jdevalk/skills. It has 43 recorded installs.
More from jdevalk/skills
astro-seo
jdevalk/skills
Audits and improves SEO for Astro sites. Use when the user asks to audit, set up, or improve SEO on an Astro site, or mentions head metadata, structured data, JSON-LD, sitemaps, IndexNow, Open Graph images, schema endpoints, NLWeb, hreflang, or search engine indexing in an Astro project. Produces drop-in code routed through @jdevalk/astro-seo-graph and chains into metadata-check for generated SEO strings.
github-profile
jdevalk/skills
Audits and optimizes GitHub profile pages — profile README, metadata fields, pinned repositories, stats widgets, and contribution visibility. Use this skill whenever the user asks to improve, create, review, or optimize their GitHub profile, or mentions "profile README", "GitHub bio", "pinned repos", "GitHub stats", "contribution graph", or "GitHub presence". Also trigger when someone says things like "make my GitHub look good", "I want a better GitHub profile", "help me stand out on GitHub", "set up my GitHub page", or "optimize my developer profile". Works for both personal profiles and organization profile pages.
content-seo
jdevalk/skills
Open the skill to read its SKILL.md instructions.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.