craft-plugin-release

# Releasing Craft Plugins A plugin release involves three independent systems that all claim to describe the same version: **git tags**, **Packagist**, and **GitHub release objects**. They drift from each other silently, and every observable signal can say "success" while consumers get nothing. This skill is the checklist and risk model for keeping them in agreement. **Core rule: verify what each system actually serves, not what you pushed to it.** A `202 Accepted` from the Packagist webhook, a green tag push, and a rendered releases page each prove nothing about the other two. ## Companion Skills - **`craft-php-guidelines`** — `references/tooling.md` for commit conventions and composer hygiene of the plugin manifest itself. - **`craftcms`** — `references/quality.md` for the CI workflows a release depends on (`code-analysis`, `create-release.yml`). - **`craft-pest`** — the suite must be green from the plugin's own root before tagging. ## The release commit If the plugin's `composer.json` carries a `version` key, **bumping it is a mandatory release step, in the same commit that dates the changelog.** A tag whose `composer.json` says a different version is silently useless: Packagist reads the manifest from the tag's own tree, sees the mismatch, and skips the tag — ``` Reading composer.json of acme/craft-thing (1.7.4) Skipped tag 1.7.4, tag (1.7.4.0) does not match version (1.7.3.0) in composer.json ``` — while the GitHub webhook still returns `202 Accepted`. Nothing in...