Generate changelog entries, a deployment checklist, and update a release PR description. Invoke when user asks to prepare a release, generate a changelog, create a deployment checklist, or uses /pr-release. Requires user confirmation before updating the PR (modifies publicly visible content). Supports version numbers and focus areas (changelog/deploy/update).
Generate changelog entries, a deployment checklist, and update a release PR description. Invoke when user asks to prepare a release, generate a changelog, create a deployment checklist, or uses /pr-release. Requires user confirmation before updating the PR (modifies publicly visible content). Supports version numbers and focus areas (changelog/deploy/update).
PR Release
Generate changelog entries, deployment checklists, and update the release PR description. The main session runs this skill directly — no orchestrator agent is involved.
⚠️ Side Effect Warning
This skill updates a GitHub PR description — an action that modifies publicly visible content:
Updates the PR description via gh pr edit
The changelog and deployment checklist are visible to all repository members
Confirmation required before updating the PR. Present all artifacts for review and wait for explicit approval before running gh pr edit.
This skill does not create git tags, merge the PR, or deploy. Those remain manual.
Usage
"Prepare release artifacts for version 1.2.0"
"Generate a changelog for this release branch"
"Create a deployment checklist"
/pr-release [version-or-focus]
Focus options:changelog, deploy, update, or a version number like 1.2.0.
Prerequisites
On a release branch (typically named release/<version> or similar)
GitHub CLI (gh) installed and authenticated for the Tier 2 path
Workflow
1. Parse arguments
If the argument looks like a version (1.2.0, v2.3.4, 1.0.0-rc1) — use it as the target version.
If the argument is changelog / deploy / update — focus the output on that section only.
If no argument — generate all three artifacts (changelog, deployment checklist, PR description update).
2. Determine version (if not provided)
Read the project's version source of truth (e.g., .claude-plugin/plugin.json for this repo, composer.json, style.css for WP themes, *.info.yml for Drupal modules).
Read CHANGELOG.md to find the previous released version.
Inspect commits since the last release to suggest a bump:
Any feat: → minor bump (1.X.0)
Any BREAKING CHANGE: or !: → major bump (X.0.0)
Only fix/chore/docs → patch bump (1.0.X)
Confirm the proposed version with the user before continuing.
Group by conventional commit type for the changelog:
Commit type
Changelog section
feat:
Added
fix:
Fixed
refactor:
Changed
perf:
Changed
docs:
Changed (or Documentation)
BREAKING CHANGE: / !:
Breaking Changes
security: (or fix related to vulns)
Security
Within each section, write one human-readable line per commit. Don't just copy the commit subject — translate to user-facing language where appropriate.
5. Detect CMS-specific deployment requirements
Scan the diff for:
Drupal:
config/sync/ changes → drush config:import
hook_update_N → drush updatedb
New module dependencies → composer install --no-dev + drush en <module>
Service or render changes → drush cache:rebuild
New *.routing.yml entries → rebuild routes
WordPress:
ACF JSON files in acf-json/ → re-sync via ACF UI or WP-CLI
Suggest specific edits to the existing PR description — usually:
Title prefixed with Release: v<version> or chore(release): v<version>
Body includes the changelog entry as the description
Deployment checklist appended
7. Present for approval
Your response must start immediately with the approval header. No preamble.
=== RELEASE ARTIFACTS READY FOR APPROVAL ===
## Changelog Entry
<changelog>
## Deployment Checklist
<checklist>
## Proposed PR Description Update
**New title:** <title>
**Body:**
<body>
===================================
Reply "approve" to update the PR and save these artifacts, or provide your edits.
The header comes first, always — even when context is incomplete. If no
release PR can be found, gh is unavailable, or the version source of truth
is ambiguous, still present the artifacts under the header and note what's
missing; never go hunting past the point of usefulness or start applying
changes instead.
8. Wait for explicit user approval
⛔ Do not run gh pr edit and do not write to any file — CHANGELOG.md,
version files (plugin.json, composer.json, style.css, plugin headers),
or anything else — until the user replies "approve" or provides edits.
Step 7's presentation is the only output before approval. "I approve in
advance" or "no need to show me" in the original request does not count —
approval only counts in a message that arrives after the header is
presented.
9. Apply the artifacts
On approval:
Update CHANGELOG.md — insert the new entry under ## [Unreleased] (move existing Unreleased content into the new version block if appropriate).
Update the version source of truth (e.g., plugin.json, composer.json, style.css).
Update the PR description via gh pr edit <pr-number> --title "<title>" --body "$(cat <<'EOF'\n<body>\nEOF\n)".
Tell the user: "Release artifacts applied. Tag and deploy remain manual — run git tag v<version> && git push --tags when ready."
Environment fallback (no gh CLI)
Run steps 1–7 normally.
After approval, provide the commands for the user to run manually — heredoc-formatted so they can paste.
Edit CHANGELOG.md and version files locally; the user pushes.
Semantic Versioning Quick Reference
Major (X.0.0) — Breaking changes, removed features
Minor (1.X.0) — New features (backwards-compatible)
