Skip to content

feat(development-planning): add manage-release skill#460

Open
wkoutre wants to merge 1 commit intonextfrom
feat/add-skill-manage-release
Open

feat(development-planning): add manage-release skill#460
wkoutre wants to merge 1 commit intonextfrom
feat/add-skill-manage-release

Conversation

@wkoutre
Copy link
Copy Markdown
Contributor

@wkoutre wkoutre commented Apr 14, 2026

What gap this fills

The development-planning plugin 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 automatically

Changes

  • Adds packages/plugins/development-planning/skills/manage-release/SKILL.md
  • Updates plugin.json (version 2.0.12.1.0, skill registered)
  • Updates CLAUDE.md and README.md with new skill documentation

Test plan

  • Skill triggers on "release the next version", "cut a release", "bump the version and release"
  • Auto-detects next semver from conventional commits (feat → minor, fix → patch, BREAKING → major)
  • Handles pre-1.0 semver correctly (no major bumps)
  • Detects and lists package files to update (package.json, plugin.json)
  • Creates release branch and commits version bumps correctly
  • Generates CHANGELOG entry and prepends to CHANGELOG.md
  • Creates PR targeting base branch
  • --dry-run shows plan without making changes
  • Respects --version override and --type override
  • Plugin validates: node scripts/validate-plugin.cjs packages/plugins/development-planning
  • Markdown lints clean
AI-Generated Description

Summary

  • Adds a new manage-release skill to the development-planning plugin that coordinates the full release workflow: version determination from conventional commits, package file updates, changelog generation, release branch creation, and PR opening
  • Bumps plugin version from 2.0.1 → 2.1.0 (new skill = minor bump)
  • Updates plugin CLAUDE.md and README.md with the new skill documentation

Changes

File Change
packages/plugins/development-planning/skills/manage-release/SKILL.md New skill with 10-step release workflow, dry-run support, semver auto-detection from conventional commits, and safety guardrails
packages/plugins/development-planning/.claude-plugin/plugin.json Bump version 2.0.1 → 2.1.0; register manage-release in skills array
packages/plugins/development-planning/CLAUDE.md Add manage-release to skills list and file structure tree
packages/plugins/development-planning/README.md Add manage-release row to skills table

Context

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

  • Skill triggers on "release the next version", "cut a release", "bump the version and release"
  • Auto-detects next semver from conventional commits (feat → minor, fix → patch, BREAKING → major)
  • Handles pre-1.0 semver correctly (no major bumps)
  • Detects package files to update (package.json, plugin.json)
  • Creates release branch and commits version bumps correctly
  • Generates CHANGELOG entry and prepends to CHANGELOG.md
  • Creates PR targeting base branch
  • --dry-run shows plan without making changes
  • Plugin validates: node scripts/validate-plugin.cjs packages/plugins/development-planning
  • Markdown lints clean

@wkoutre wkoutre requested a review from a team as a code owner April 14, 2026 11:02
@vercel
Copy link
Copy Markdown

vercel bot commented Apr 14, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
ai-toolkit-slack-oauth-backend Ready Ready Preview, Comment Apr 14, 2026 11:02am

Request Review

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 14, 2026

🤖 Claude Code Review

Review complete

Review Summary

This PR adds a new manage-release skill to the development-planning plugin. The skill coordinates a full software release workflow: version detection via conventional commits, package file updates, changelog generation, release branch creation, and PR opening.

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).

Issues

Non-blocking: Dangling reference to generate-changelog skill

In SKILL.md:109, Step 6 says:

Format as a conventional changelog entry (see generate-changelog skill for format)

No generate-changelog skill exists in this plugin or any other plugin in the repo. This will confuse the executing agent. Either remove the reference or describe the expected changelog format inline.

Non-blocking: macOS-specific sed syntax

The sed -i '' examples in Step 5 (lines 97-100) use macOS syntax. On Linux, sed -i '' creates a backup file with an empty-string suffix rather than editing in-place. Since this is a skill prompt that Claude will interpret (not a literal script), the agent will likely adapt — but it could lead to unexpected behavior if followed literally on Linux. Consider using sed -i (GNU) or noting the platform difference.

Non-blocking: Confusing dry-run phrasing in Step 2

Line 64 says: "unless --dry-run is false and user already provided the version". Since --dry-run defaults to false, this condition is almost always true. The intent appears to be "unless the user already provided an explicit version" — the dry-run clause is redundant/confusing here.

Verdict

No bugs, security issues, or blocking problems. The skill is well-structured with clear steps, safety rules, and dry-run support. The issues noted are minor documentation improvements.


💡 Want a fresh review? Add a comment containing @request-claude-review to trigger a new review at any time.

@github-actions
Copy link
Copy Markdown
Contributor

📚 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 Review

This PR adds the manage-release skill to the development-planning plugin. Documentation coverage is largely complete:

  • Version bump: ✅ plugin.json version bumped from 2.0.12.1.0 (correct minor bump for new feature)
  • Plugin CLAUDE.md: ✅ New skill added to both the skills list and directory tree
  • Plugin README.md: ✅ New skill added to the skills table
  • SKILL.md: ✅ New file created with comprehensive documentation

Minor gap: The root CLAUDE.md contains a plugin version table that still shows development-planning | 2.0.1 — it should reflect the new 2.1.0 version after this PR merges.

Missing Updates

Type File Severity Reason
📄 readme CLAUDE.md ℹ️ info Root CLAUDE.md plugin version table still references development-planning at 2.0.1 — should be updated to 2.1.0 to stay in sync.

Suggestions (1)

💡 Inline suggestions have been posted as review comments. Click "Commit suggestion" to apply each fix directly.

  • ℹ️ CLAUDE.md: The root CLAUDE.md contains a plugin version reference table. The development-planning plugin version should be updated from 2.0.1 to 2.1.0 to match the bump in this PR.

🤖 Generated by Claude Documentation Validator | Mode: suggest

Copy link
Copy Markdown
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📋 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant