CI/CD and release engineering

When to use it

Build, debug or review GitHub Actions CI/CD for WordPress plugins, themes and sites: workflow trust and secrets, PHP/WP test matrices, merge gates, release zips, version drift, WordPress.org SVN delivery, host deploys and rollback. Writing the tests themselves belongs to test strategy.

Boundaries and hand-offs

Authoring tests and fixtures to wp-devkit-test-strategy; PHPStan configuration to wp-devkit-phpstan-review; WP-CLI runbooks to wp-devkit-wpcli-and-ops; plugin activation, upgrade and uninstall code to wp-devkit-plugin-development; data upgrade logic to wp-devkit-migration-upgrade-review; vulnerabilities in the shipped code to wp-devkit-security-review.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:release-review <target-path>

The short form /wp-devkit:release requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-ci-cd-and-release-engineering
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• github-actions-hardening-and-gates.md : read for trust boundaries, permissions, pinning, injection, secrets, gates.
• packaging-and-artifact-verification.md : read for deterministic builds, archive inspection, version checks, provenance.
• test-matrix-and-quality-gates.md : read for matrix derivation, gate catalog, runtimes, baselines.
• wordpress-org-release-and-rollback.md : read for SVN/readme mechanics, tag workflow, deploy and rollback.

How a review runs

1. Trace events, identities and privileges from checkout to release. Decide for each privileged job whose code and whose text it executes.
2. Follow required gates: which job reports each check, whether a path filter, if: skip, continue-on-error or || true lets a failure pass, and whether the release job depends on the gates.
3. Check whether the tested bytes are the promoted bytes: one build, recorded digest, no rebuild at publish. Inspect build inputs (lockfile installs, pinned toolchain).
4. Compare plugin header, readme Stable tag , tag, changelog and constants for the intended channel. Compare support-policy headers with what the matrix proves.
5. Check recovery: previous good artifact, who can roll back, migration reversibility, data restore, communication. A rollback keyword is not a tested path.
6. Report what is established from the repository and what depends on settings you could not see (branch rules, environments, secret scopes). Insufficient evidence is a valid outcome; name the setting or run that would settle it. Do not downgrade a reachable secret exposure because the attacker needs a fork PR; do not escalate a pattern match without a reachable path.

What you get back

Review: result and reviewed scope first. Each confirmed finding: severity per the contract, file:line, actor, trigger, reachable path, impact, confidence, minimal fix, regression check. Candidates and unverified settings in a separate list.

Implementation: changed workflow/files, stage affected, commands run with exit status, evidence of the failing-then-passing proof, unexecuted checks, residual risk, rollback plan.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.