release

Automate Chorus releases with CHANGELOG updates, version bumps, PRs, tags, and GitHub release notes.

1.1k|99|Updated Feb 4, 2026
One-click install
npx skills add https://github.com/Chorus-AIDLC/Chorus --skill release-chorus-aidlc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/Chorus-AIDLC/Chorus/tree/main/.claude/skills/release
Command: npx skills add https://github.com/Chorus-AIDLC/Chorus --skill release-chorus-aidlc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Releasing software involves many manual, error-prone steps—updating CHANGELOG, bumping package versions, creating pull requests, tagging, and publishing releases—which can lead to inconsistent release notes, missed commits, or incorrect tags.

Core Features & Use Cases

  • Changelog preparation & approval: Guides drafting the new release section from commits and requires explicit user approval before proceeding.
  • Version bump and PR workflow: Instructs updating package.json, committing on develop, and opening a PR to main for CI and review.
  • Tagging and GitHub release creation: Details tagging the merged commit on main and creating a GitHub release with concise release notes.
  • Use Case: A maintainer preparing a patch, minor, or major release for Chorus who needs a repeatable, review-gated process to ensure accurate notes and correct semantic versioning.

Quick Start

Draft the new CHANGELOG section, confirm the proposed version, bump package.json on develop, push the changes, open a PR to main, merge after CI passes, and then create the GitHub release with the new tag.

Frequently Asked Questions about release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate changelog preparation and version bumping for a GitHub release?

Automating a GitHub release requires drafting the new CHANGELOG section from recent commits and bumping the package.json version on your develop branch before pushing changes. You must explicitly approve the proposed release notes and semantic version before the workflow proceeds to commit changes.

What's the best way to manage a git release workflow from develop to main with semver tagging?

Managing a git release workflow involves bumping the package.json version on develop, opening a pull request to main for CI and review, and tagging the merged commit. This semver-tagged process ensures accurate release notes and correct versioning upon GitHub release creation.

Does this release automation process require a clean git working tree and gh CLI authentication?

Yes, cutting a release requires an authenticated gh CLI and a clean working tree on the develop branch. Maintainers must adhere to semantic versioning rules and provide explicit approval before any commits, merges, or GitHub release notes are created.

How does the pull request workflow handle version bumping and CI checks before publishing?

The pull request workflow handles version bumping by instructing updates to package.json on the develop branch, then opening a PR to main. This gates the release publication behind CI checks and code review, ensuring the new tag is only created after the merge.

Can I publish GitHub release notes without explicit approval during the version bump process?

No, you cannot publish GitHub release notes without explicit approval. The release process requires user confirmation before proceeding with commits, merging the PR to main, and creating the final GitHub release with the generated changelog entries.