feat(development-planning): add manage-release skill#460
feat(development-planning): add manage-release skill#460
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🤖 Claude Code Review
Review SummaryThis PR adds a new The documentation updates (plugin.json, CLAUDE.md, README.md) are all consistent and correctly reflect the new skill. The version bump from 2.0.1 → 2.1.0 is appropriate for a new skill addition (minor bump per repo conventions). IssuesNon-blocking: Dangling reference to
|
📚 Documentation Check ✅Verdict: Passed Plugin version was bumped (2.0.1 → 2.1.0), CLAUDE.md and README.md were updated to document the new manage-release skill. All required documentation is present. PR #460 Documentation ReviewThis PR adds the
Minor gap: The root Missing Updates
Suggestions (1)
🤖 Generated by Claude Documentation Validator | Mode: |
There was a problem hiding this comment.
📋 Review verdict: APPROVE
👆 The main review comment above is the source of truth for this PR review. It is automatically updated on each review cycle, so always refer to it for the most current feedback.
This formal review submission is for the verdict only. 3 inline comment(s) are attached below.
|
|
||
| If a `CHANGELOG.md` exists or the user wants one: | ||
|
|
||
| 1. Generate the changelog entry for the new version by running `git log` with the same range used for version detection |
There was a problem hiding this comment.
This references a generate-changelog skill that doesn't exist in this plugin or anywhere else in the repo. This will confuse the executing agent.
Either remove the parenthetical reference or describe the expected changelog format inline (e.g., Keep a Changelog format with ## [version] - date headers and grouped entries by type).
|
|
||
| ```bash | ||
| # For package.json — use a targeted sed (not npm version, to avoid side effects) | ||
| sed -i '' "s/\"version\": \"<CURRENT>\"/\"version\": \"<NEXT>\"/" path/to/package.json |
There was a problem hiding this comment.
sed -i '' is macOS-specific syntax. On GNU/Linux, this creates a backup file with an empty suffix instead of editing in-place. Since Claude will interpret this as guidance, it will probably adapt, but consider either using a platform-agnostic note or replacing the sed examples with the Edit tool (which is already in allowed-tools).
|
|
||
| - If no recognizable conventional commits found, default to **patch** | ||
| - If current version is `0.x.y`, a `feat` bumps **minor**, a breaking change bumps **minor** too (per semver pre-1.0 conventions — tell the user this is happening) | ||
| - Show the proposed version and ask for confirmation before proceeding (unless `--dry-run` is false and user already provided the version) |
There was a problem hiding this comment.
Minor: "unless --dry-run is false and user already provided the version" — since --dry-run defaults to false, this condition is almost always met. The intent seems to be simply "unless the user already provided an explicit version". Consider simplifying to avoid confusion.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 085a71e89d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @@ -0,0 +1,185 @@ | |||
| --- | |||
| description: Coordinate a full software release. Use when user says "release version 1.2.0", "cut a release", "bump the version and release", "prepare a release for this milestone", "tag and release the latest changes", "what version should we release next?", or "create a release PR". | |||
| allowed-tools: Bash(git log:*), Bash(git tag:*), Bash(git describe:*), Bash(git diff:*), Bash(git commit:*), Bash(git push:*), Bash(git checkout:*), Bash(git branch:*), Bash(grep:*), Bash(sed:*), Bash(cat:*), Bash(gh pr:*), Bash(gh release:*), Read, Write, Edit, Glob | |||
There was a problem hiding this comment.
Allow commands required by the release workflow
The tool allowlist is too narrow for the steps defined below: the workflow calls git ls-files (Step 3) and git add (Step 7), but allowed-tools only permits specific subcommands like git log, git tag, git commit, etc. In environments that enforce allowed-tools, this blocks file discovery and staging, so the skill cannot complete a release end-to-end.
Useful? React with 👍 / 👎.
|
|
||
| ```bash | ||
| # For package.json — use a targeted sed (not npm version, to avoid side effects) | ||
| sed -i '' "s/\"version\": \"<CURRENT>\"/\"version\": \"<NEXT>\"/" path/to/package.json |
There was a problem hiding this comment.
Use a cross-platform in-place edit command
The version-bump command uses sed -i '', which is BSD/macOS syntax; on GNU sed (common on Linux runners) this form fails and does not update the file. Since this is the core mutation step, releases on Linux will stop before version files are bumped.
Useful? React with 👍 / 👎.
| ### Step 7: Commit the release changes | ||
|
|
||
| ```bash | ||
| git add <all updated package files> CHANGELOG.md |
There was a problem hiding this comment.
Avoid adding CHANGELOG.md when it may not exist
Step 6 makes changelog generation conditional, but Step 7 always stages CHANGELOG.md. When no changelog file exists (and the user didn’t request one), git add ... CHANGELOG.md fails with a pathspec error and prevents the release commit from being created.
Useful? React with 👍 / 👎.
| # package.json at root or in packages/ | ||
| # plugin.json in .claude-plugin/ directories | ||
| # Any VERSION or version files | ||
| git ls-files | grep -E "(package\.json|plugin\.json|VERSION)$" | head -20 |
There was a problem hiding this comment.
Scan all version files instead of truncating at 20
The discovery command pipes to head -20, so only the first 20 candidate files are considered. In larger monorepos this can skip valid package.json/plugin.json files, producing partial version bumps and inconsistent release state.
Useful? React with 👍 / 👎.
What gap this fills
The
development-planningplugin had no release management tooling. Developers needed to manually determine the next semver, bump versions across all package files, generate a changelog entry, and create a release PR. This skill coordinates the entire release workflow in one command.How it was identified
During gap analysis, the release lifecycle phase was absent — no structured workflow for version determination, version bumping, changelog generation, or release branch creation. This is a common bottleneck in every release cycle.
Example usage scenarios
"release the next version"— auto-detect next semver from conventional commits and release"cut a patch release"— force a patch bump"bump to version 2.1.0 and create a release PR"— explicit version"manage-release --type minor --dry-run"— preview what would happen"what version should we ship next?"— semver analysis only"tag and release latest changes"— detect and release automaticallyChanges
packages/plugins/development-planning/skills/manage-release/SKILL.mdplugin.json(version2.0.1→2.1.0, skill registered)CLAUDE.mdandREADME.mdwith new skill documentationTest plan
--dry-runshows plan without making changes--versionoverride and--typeoverridenode scripts/validate-plugin.cjs packages/plugins/development-planningAI-Generated Description
Summary
manage-releaseskill to thedevelopment-planningplugin that coordinates the full release workflow: version determination from conventional commits, package file updates, changelog generation, release branch creation, and PR openingChanges
packages/plugins/development-planning/skills/manage-release/SKILL.mdpackages/plugins/development-planning/.claude-plugin/plugin.jsonmanage-releasein skills arraypackages/plugins/development-planning/CLAUDE.mdpackages/plugins/development-planning/README.mdContext
The development-planning plugin had no release management tooling. This skill fills that gap by coordinating the entire release lifecycle — from analyzing conventional commits to determine the next semver, through version bumping across package files, changelog generation, and release PR creation — in a single command.
Test plan
--dry-runshows plan without making changesnode scripts/validate-plugin.cjs packages/plugins/development-planning