feat(marketplace): command consolidation + 8 new plugins (v8.1.0 → v9.0.0) [BREAKING]
Phase 1b: Rename all ~94 commands across 12 plugins to /<noun> <action> sub-command pattern. Git-flow consolidated from 8→5 commands (commit variants absorbed into --push/--merge/--sync flags). Dispatch files, name: frontmatter, and cross-reference updates for all plugins. Phase 2: Design documents for 8 new plugins in docs/designs/. Phase 3: Scaffold 8 new plugins — saas-api-platform, saas-db-migrate, saas-react-platform, saas-test-pilot, data-seed, ops-release-manager, ops-deploy-pipeline, debug-mcp. Each with plugin.json, commands, agents, skills, README, and claude-md-integration. Marketplace grows from 12→20. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
25
plugins/ops-release-manager/.claude-plugin/plugin.json
Normal file
25
plugins/ops-release-manager/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"name": "ops-release-manager",
|
||||
"version": "1.0.0",
|
||||
"description": "Release management with semantic versioning, changelog generation, and tag management",
|
||||
"author": {
|
||||
"name": "Leo Miranda",
|
||||
"email": "leobmiranda@gmail.com"
|
||||
},
|
||||
"homepage": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace/src/branch/main/plugins/ops-release-manager/README.md",
|
||||
"repository": "https://gitea.hotserv.cloud/personal-projects/leo-claude-mktplace.git",
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
"release",
|
||||
"semver",
|
||||
"versioning",
|
||||
"changelog",
|
||||
"tags",
|
||||
"deployment",
|
||||
"release-management"
|
||||
],
|
||||
"commands": [
|
||||
"./commands/"
|
||||
],
|
||||
"domain": "ops"
|
||||
}
|
||||
66
plugins/ops-release-manager/README.md
Normal file
66
plugins/ops-release-manager/README.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# ops-release-manager
|
||||
|
||||
Release management with semantic versioning, changelog generation, and tag management.
|
||||
|
||||
## Overview
|
||||
|
||||
ops-release-manager automates the release process: version bumping across all project files, changelog updates following Keep a Changelog format, git tag creation with release notes, and rollback capabilities. It supports Node.js, Python, Rust, and Claude marketplace projects.
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/release setup` | Detect version locations and configure release workflow |
|
||||
| `/release prepare` | Bump versions, update changelog, create release branch |
|
||||
| `/release validate` | Pre-release checks (versions, changelog, dependencies) |
|
||||
| `/release tag` | Create annotated git tag with release notes |
|
||||
| `/release rollback` | Revert a release (remove tag, revert version bump) |
|
||||
| `/release status` | Show current version and unreleased changes |
|
||||
|
||||
## Agents
|
||||
|
||||
| Agent | Model | Mode | Role |
|
||||
|-------|-------|------|------|
|
||||
| release-coordinator | sonnet | acceptEdits | Version bumping, changelog, tags, branches |
|
||||
| release-validator | haiku | plan (read-only) | Pre-release validation and dependency checks |
|
||||
|
||||
## Skills
|
||||
|
||||
| Skill | Purpose |
|
||||
|-------|---------|
|
||||
| version-detection | Find version in package.json, pyproject.toml, Cargo.toml, README, etc. |
|
||||
| semver-rules | SemVer bump logic, conventional commit analysis |
|
||||
| changelog-conventions | Keep a Changelog format, Unreleased section management |
|
||||
| release-workflow | Branch-based and tag-based release patterns, rollback procedures |
|
||||
| visual-header | Consistent command output headers |
|
||||
|
||||
## Supported Ecosystems
|
||||
|
||||
| Ecosystem | Version File | Lock File |
|
||||
|-----------|-------------|-----------|
|
||||
| Node.js | package.json | package-lock.json |
|
||||
| Python | pyproject.toml, setup.cfg | poetry.lock, requirements.txt |
|
||||
| Rust | Cargo.toml | Cargo.lock |
|
||||
| Claude Marketplace | marketplace.json, plugin.json | N/A |
|
||||
|
||||
## Release Flow
|
||||
|
||||
```
|
||||
/release status -> See what is unreleased
|
||||
/release prepare -> Bump versions + changelog
|
||||
/release validate -> Pre-release checks
|
||||
/release tag -> Create git tag
|
||||
```
|
||||
|
||||
If something goes wrong:
|
||||
```
|
||||
/release rollback -> Revert the release
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
This plugin is part of the Leo Claude Marketplace. It is installed automatically when the marketplace is configured.
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
59
plugins/ops-release-manager/agents/release-coordinator.md
Normal file
59
plugins/ops-release-manager/agents/release-coordinator.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: release-coordinator
|
||||
description: Version bumping, changelog updates, and release branch/tag management
|
||||
model: sonnet
|
||||
permissionMode: acceptEdits
|
||||
---
|
||||
|
||||
# Release Coordinator Agent
|
||||
|
||||
You are a release engineer specializing in semantic versioning, changelog management, and release automation across multiple language ecosystems.
|
||||
|
||||
## Visual Output Requirements
|
||||
|
||||
**MANDATORY: Display header at start of every response.**
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - [Command Context] |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Version consistency is non-negotiable** — Every version location must match. A mismatch between package.json and README is a release blocker.
|
||||
|
||||
2. **Changelogs are for humans** — Write changelog entries that explain the impact on users, not the implementation details.
|
||||
|
||||
3. **Tags are immutable** — Once a tag is pushed, treat it as permanent. Rollbacks create revert commits, not force-pushed tags (unless explicitly requested).
|
||||
|
||||
4. **Releases are reversible** — Every action taken during release preparation must have a documented undo path.
|
||||
|
||||
## Expertise
|
||||
|
||||
- **SemVer:** Major/minor/patch rules, pre-release identifiers (-alpha, -beta, -rc.1)
|
||||
- **Changelog:** Keep a Changelog format, conventional commits parsing
|
||||
- **Git:** Annotated tags, release branches, merge strategies
|
||||
- **Ecosystems:** package.json, pyproject.toml, Cargo.toml, marketplace.json, setup.cfg
|
||||
- **CI/CD:** Release triggers, deployment pipelines, artifact publishing
|
||||
|
||||
## Release Workflow
|
||||
|
||||
When preparing a release:
|
||||
|
||||
1. **Verify state** — Clean working directory, correct branch, versions in sync.
|
||||
|
||||
2. **Determine version** — From explicit input or conventional commit analysis. When in doubt, ask the user.
|
||||
|
||||
3. **Update files atomically** — Change all version locations in a single commit. Never leave versions out of sync.
|
||||
|
||||
4. **Changelog first** — Update the changelog before creating the tag. The changelog is the source of truth for what is in the release.
|
||||
|
||||
5. **Review before finalizing** — Always show the complete diff before creating tags or pushing. A release is hard to undo once published.
|
||||
|
||||
## Output Style
|
||||
|
||||
- Show diffs for every file change
|
||||
- Confirm destructive actions (tag deletion, force push) explicitly
|
||||
- Provide copy-pasteable commands for manual steps
|
||||
- Include "next steps" at the end of every operation
|
||||
70
plugins/ops-release-manager/agents/release-validator.md
Normal file
70
plugins/ops-release-manager/agents/release-validator.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
name: release-validator
|
||||
description: Pre-release validation and dependency checks
|
||||
model: haiku
|
||||
permissionMode: plan
|
||||
disallowedTools: Write, Edit, MultiEdit
|
||||
---
|
||||
|
||||
# Release Validator Agent
|
||||
|
||||
You are a release quality gate focused on detecting issues before they reach production. You never modify files — only analyze and report.
|
||||
|
||||
## Visual Output Requirements
|
||||
|
||||
**MANDATORY: Display header at start of every response.**
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Validate Release |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Block on critical issues** — Version mismatches, missing changelog entries, and failing tests are release blockers. Do not soft-pedal them.
|
||||
|
||||
2. **Warn on non-critical** — Minor documentation gaps or low-severity advisories are warnings, not blockers.
|
||||
|
||||
3. **Be specific** — "Version mismatch" is useless. "package.json says 2.4.0 but README.md says 2.3.1" is actionable.
|
||||
|
||||
4. **Check everything** — Users forget things. Check version files, changelog, git state, lock files, and documentation systematically.
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
When validating a release, check every item:
|
||||
|
||||
1. **Version Files**
|
||||
- All detected locations report the same version
|
||||
- Version is greater than the latest git tag
|
||||
- Version follows SemVer format (no leading zeros, valid pre-release)
|
||||
|
||||
2. **Changelog**
|
||||
- Current version section exists
|
||||
- Date is present and reasonable (today or within last 7 days)
|
||||
- At least one entry exists
|
||||
- Categories follow Keep a Changelog ordering
|
||||
- No leftover [Unreleased] content that should have been moved
|
||||
|
||||
3. **Git State**
|
||||
- Working directory clean
|
||||
- Branch up to date with remote
|
||||
- No unresolved merge conflicts
|
||||
- Tag does not already exist
|
||||
|
||||
4. **Dependencies**
|
||||
- Lock file matches manifest
|
||||
- No critical security advisories
|
||||
- No deprecated packages in direct dependencies
|
||||
|
||||
5. **Documentation**
|
||||
- README version matches
|
||||
- Migration guide exists for major bumps
|
||||
- Breaking changes are documented in changelog
|
||||
|
||||
## Output Style
|
||||
|
||||
- Use a structured pass/fail/warn table
|
||||
- Include specific details for every non-pass result
|
||||
- Provide a clear GO/NO-GO verdict at the end
|
||||
- List exact steps to fix any failures
|
||||
31
plugins/ops-release-manager/claude-md-integration.md
Normal file
31
plugins/ops-release-manager/claude-md-integration.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Release Manager Integration
|
||||
|
||||
Add to your project's CLAUDE.md:
|
||||
|
||||
## Release Management
|
||||
|
||||
This project uses ops-release-manager for versioning and release automation.
|
||||
|
||||
### Commands
|
||||
- `/release setup` - Detect version locations and configure release workflow
|
||||
- `/release status` - Show current version and unreleased changes
|
||||
- `/release prepare <major|minor|patch>` - Bump versions and update changelog
|
||||
- `/release validate` - Pre-release checks before tagging
|
||||
- `/release tag` - Create annotated git tag with release notes
|
||||
- `/release rollback` - Revert a release if needed
|
||||
|
||||
### Versioning
|
||||
- Follows [SemVer](https://semver.org/) (MAJOR.MINOR.PATCH)
|
||||
- Version locations: package.json, README.md, CHANGELOG.md (auto-detected)
|
||||
- Changelog follows [Keep a Changelog](https://keepachangelog.com) format
|
||||
|
||||
### Release Process
|
||||
1. All changes documented under `[Unreleased]` in CHANGELOG.md
|
||||
2. Run `/release prepare minor` (or major/patch) when ready
|
||||
3. Run `/release validate` to verify readiness
|
||||
4. Run `/release tag --push` to finalize
|
||||
|
||||
### Conventions
|
||||
- Tag format: `vX.Y.Z` (annotated tags with release notes)
|
||||
- Branch format: `release/X.Y.Z` (for major/minor releases)
|
||||
- Commit message: `chore(release): prepare vX.Y.Z`
|
||||
88
plugins/ops-release-manager/commands/release-prepare.md
Normal file
88
plugins/ops-release-manager/commands/release-prepare.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: release prepare
|
||||
description: Prepare a release — bump versions across all files, update changelog, create release branch
|
||||
---
|
||||
|
||||
# /release prepare
|
||||
|
||||
Prepare a new release by bumping version numbers, updating the changelog, and optionally creating a release branch.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Prepare Release |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/release prepare <version|bump-type> [--branch] [--no-branch]
|
||||
```
|
||||
|
||||
**Version:** Explicit version (e.g., `2.4.0`) or bump type (`major`, `minor`, `patch`)
|
||||
**--branch:** Create a release/X.Y.Z branch (default for minor/major)
|
||||
**--no-branch:** Skip branch creation
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/version-detection.md
|
||||
- skills/semver-rules.md
|
||||
- skills/changelog-conventions.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Determine Target Version**
|
||||
- If explicit version: validate it follows SemVer
|
||||
- If bump type: calculate from current version
|
||||
- `patch`: 2.3.1 -> 2.3.2
|
||||
- `minor`: 2.3.1 -> 2.4.0
|
||||
- `major`: 2.3.1 -> 3.0.0
|
||||
- If no argument: analyze commits since last tag, suggest bump type
|
||||
|
||||
2. **Pre-flight Checks**
|
||||
- Working directory is clean (no uncommitted changes)
|
||||
- On correct base branch (development or main)
|
||||
- [Unreleased] section in CHANGELOG.md has content
|
||||
- All tests passing (if CI status available)
|
||||
|
||||
3. **Update Version Files**
|
||||
- Update all detected version locations (from setup)
|
||||
- Show diff for each file before applying
|
||||
- Maintain format consistency (quotes, spacing)
|
||||
|
||||
4. **Update Changelog**
|
||||
- Replace `[Unreleased]` with `[X.Y.Z] - YYYY-MM-DD`
|
||||
- Add new empty `[Unreleased]` section above
|
||||
- Update comparison links at bottom if present
|
||||
|
||||
5. **Create Release Branch** (if applicable)
|
||||
- Branch name: `release/X.Y.Z`
|
||||
- Commit all version changes
|
||||
- Commit message: `chore(release): prepare vX.Y.Z`
|
||||
|
||||
6. **Summary**
|
||||
- List all files modified
|
||||
- Show the new version
|
||||
- Next steps: review, validate, then tag
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Release Preparation: v2.4.0
|
||||
|
||||
### Files Updated
|
||||
- package.json: 2.3.1 -> 2.4.0
|
||||
- README.md: v2.3.1 -> v2.4.0
|
||||
- CHANGELOG.md: [Unreleased] -> [2.4.0] - 2026-02-06
|
||||
|
||||
### Branch
|
||||
- Created: release/2.4.0
|
||||
- Commit: chore(release): prepare v2.4.0
|
||||
|
||||
### Next Steps
|
||||
1. Review changes: `git diff development`
|
||||
2. Validate: `/release validate`
|
||||
3. Tag: `/release tag`
|
||||
```
|
||||
79
plugins/ops-release-manager/commands/release-rollback.md
Normal file
79
plugins/ops-release-manager/commands/release-rollback.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
name: release rollback
|
||||
description: Revert a release — remove git tag, revert version bump commit, restore previous state
|
||||
---
|
||||
|
||||
# /release rollback
|
||||
|
||||
Revert a release by removing the git tag and reverting version bump changes.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Rollback Release |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/release rollback [<version>] [--tag-only] [--force]
|
||||
```
|
||||
|
||||
**Version:** Version to rollback (defaults to latest tag)
|
||||
**--tag-only:** Only remove the tag, keep version changes
|
||||
**--force:** Skip confirmation prompts
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/release-workflow.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Release to Rollback**
|
||||
- If version specified: find matching tag
|
||||
- If not specified: use most recent tag
|
||||
- Show the release details for confirmation
|
||||
|
||||
2. **Safety Checks**
|
||||
- Warn if tag has been pushed to remote
|
||||
- Warn if other branches have been based on this release
|
||||
- Warn if CI pipeline has already deployed
|
||||
- Require explicit confirmation (unless --force)
|
||||
|
||||
3. **Remove Git Tag**
|
||||
- Delete local tag: `git tag -d vX.Y.Z`
|
||||
- If tag was pushed: `git push origin :refs/tags/vX.Y.Z`
|
||||
- Confirm tag removal
|
||||
|
||||
4. **Revert Version Changes** (unless --tag-only)
|
||||
- Find the version bump commit
|
||||
- Create a revert commit: `git revert <commit> --no-edit`
|
||||
- This restores CHANGELOG.md, version files to previous state
|
||||
|
||||
5. **Cleanup**
|
||||
- If release branch exists: offer to delete it
|
||||
- Update any tracking references
|
||||
- Show final state
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Rollback: v2.4.0
|
||||
|
||||
### Actions Taken
|
||||
- [x] Deleted local tag v2.4.0
|
||||
- [x] Deleted remote tag v2.4.0
|
||||
- [x] Reverted commit abc1234 (chore(release): prepare v2.4.0)
|
||||
- [x] Deleted branch release/2.4.0
|
||||
|
||||
### Current State
|
||||
- Version: 2.3.1 (restored)
|
||||
- Latest tag: v2.3.1
|
||||
- CHANGELOG.md: [Unreleased] section restored
|
||||
|
||||
### Warnings
|
||||
- If any deployments were triggered, manual rollback may be needed
|
||||
- Notify team members of the release revert
|
||||
```
|
||||
71
plugins/ops-release-manager/commands/release-setup.md
Normal file
71
plugins/ops-release-manager/commands/release-setup.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
name: release setup
|
||||
description: Detect version locations, release conventions, and configure release workflow
|
||||
---
|
||||
|
||||
# /release setup
|
||||
|
||||
Setup wizard for release management. Detects existing version locations and release conventions.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Setup |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/version-detection.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Detect Version Locations**
|
||||
- Scan for version strings in standard files:
|
||||
- `package.json` (Node.js)
|
||||
- `pyproject.toml` (Python)
|
||||
- `setup.cfg`, `setup.py` (Python legacy)
|
||||
- `Cargo.toml` (Rust)
|
||||
- `marketplace.json` (Claude plugins)
|
||||
- `README.md` title line
|
||||
- `CHANGELOG.md` header
|
||||
- Record each location with current version value
|
||||
|
||||
2. **Check Version Consistency**
|
||||
- Compare all detected versions
|
||||
- Flag any mismatches between files
|
||||
- Identify the "source of truth" file
|
||||
|
||||
3. **Detect Release Conventions**
|
||||
- Git tags: check `git tag` for existing pattern (v1.0.0 vs 1.0.0)
|
||||
- Branching: check for release/* branches
|
||||
- Changelog format: detect Keep a Changelog vs other
|
||||
- CI/CD: check for release workflows in .github/workflows or .gitlab-ci.yml
|
||||
|
||||
4. **Present Configuration**
|
||||
- Show detected settings
|
||||
- Ask user to confirm or override
|
||||
- Store preferences for future commands
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Release Configuration
|
||||
|
||||
### Version Locations
|
||||
| File | Current Version | Pattern |
|
||||
|------|----------------|---------|
|
||||
| package.json | 2.3.1 | "version": "X.Y.Z" |
|
||||
| README.md | 2.3.1 | # Project - vX.Y.Z |
|
||||
| CHANGELOG.md | 2.3.1 | ## [X.Y.Z] - YYYY-MM-DD |
|
||||
|
||||
### Conventions
|
||||
- Tag format: vX.Y.Z
|
||||
- Branch pattern: release/X.Y.Z
|
||||
- Changelog: Keep a Changelog format
|
||||
- Source of truth: package.json
|
||||
|
||||
### Status: Ready
|
||||
All versions in sync. Release workflow configured.
|
||||
```
|
||||
86
plugins/ops-release-manager/commands/release-status.md
Normal file
86
plugins/ops-release-manager/commands/release-status.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: release status
|
||||
description: Show current version, unreleased changes, and release readiness
|
||||
---
|
||||
|
||||
# /release status
|
||||
|
||||
Display the current version, unreleased changes, and overall release readiness.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Status |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/release status [--verbose]
|
||||
```
|
||||
|
||||
**--verbose:** Include full unreleased changelog and commit list
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/version-detection.md
|
||||
- skills/semver-rules.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Current Version**
|
||||
- Read version from all known locations
|
||||
- Show the latest git tag
|
||||
- Flag any version mismatches
|
||||
|
||||
2. **Unreleased Changes**
|
||||
- Read [Unreleased] section from CHANGELOG.md
|
||||
- Count entries by category (Added, Changed, Fixed, etc.)
|
||||
- If verbose: show full content
|
||||
|
||||
3. **Commit Analysis**
|
||||
- List commits since last tag
|
||||
- Parse conventional commit prefixes (feat, fix, chore, etc.)
|
||||
- Suggest bump type based on commit types:
|
||||
- Any `BREAKING CHANGE` or `!` → major
|
||||
- Any `feat` → minor
|
||||
- Only `fix`, `chore`, `docs` → patch
|
||||
- If verbose: show commit list
|
||||
|
||||
4. **Readiness Assessment**
|
||||
- Check if [Unreleased] has content
|
||||
- Check if all versions are in sync
|
||||
- Check git state (clean working directory)
|
||||
- Summarize blockers if any
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Release Status
|
||||
|
||||
### Current Version: 2.3.1 (tag: v2.3.1)
|
||||
All 3 version locations in sync.
|
||||
|
||||
### Unreleased Changes
|
||||
| Category | Count |
|
||||
|----------|-------|
|
||||
| Added | 3 |
|
||||
| Fixed | 2 |
|
||||
| Changed | 1 |
|
||||
|
||||
### Commits Since v2.3.1: 14
|
||||
- 5 feat (new features)
|
||||
- 6 fix (bug fixes)
|
||||
- 3 chore (maintenance)
|
||||
|
||||
### Suggested Bump: MINOR (2.3.1 -> 2.4.0)
|
||||
Reason: 5 new features detected
|
||||
|
||||
### Readiness: READY
|
||||
- [x] Unreleased changes documented
|
||||
- [x] Versions in sync
|
||||
- [x] Working directory clean
|
||||
Run `/release prepare minor` to begin.
|
||||
```
|
||||
83
plugins/ops-release-manager/commands/release-tag.md
Normal file
83
plugins/ops-release-manager/commands/release-tag.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: release tag
|
||||
description: Create annotated git tag with release notes extracted from changelog
|
||||
---
|
||||
|
||||
# /release tag
|
||||
|
||||
Create and push an annotated git tag with release notes from the changelog.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Tag Release |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/release tag [--push] [--draft]
|
||||
```
|
||||
|
||||
**--push:** Push tag to remote immediately (default: ask)
|
||||
**--draft:** Create tag locally without pushing
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/release-workflow.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Pre-flight**
|
||||
- Verify `/release validate` passes (run automatically if not done)
|
||||
- Confirm current version from version files
|
||||
- Check that tag does not already exist
|
||||
|
||||
2. **Extract Release Notes**
|
||||
- Read the current version's section from CHANGELOG.md
|
||||
- Format as tag annotation body
|
||||
- Include version number and date in tag message
|
||||
|
||||
3. **Create Tag**
|
||||
- Tag name: `vX.Y.Z` (matching project convention)
|
||||
- Annotated tag with release notes as message
|
||||
- Command: `git tag -a vX.Y.Z -m "Release vX.Y.Z\n\n<release notes>"`
|
||||
|
||||
4. **Push Decision**
|
||||
- If --push: push tag to origin
|
||||
- If --draft: keep local only
|
||||
- Otherwise: show tag details and ask user
|
||||
|
||||
5. **Post-Tag Actions**
|
||||
- If release branch exists: remind to merge back and delete branch
|
||||
- If CI release pipeline detected: note it will be triggered
|
||||
- Show the complete release summary
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Release Tagged: v2.4.0
|
||||
|
||||
### Tag
|
||||
- Name: v2.4.0
|
||||
- Commit: abc1234 (HEAD)
|
||||
- Date: 2026-02-06
|
||||
|
||||
### Release Notes
|
||||
#### Added
|
||||
- New feature X
|
||||
- New feature Y
|
||||
|
||||
#### Fixed
|
||||
- Bug fix Z
|
||||
|
||||
### Status: Tag created locally
|
||||
Run `git push origin v2.4.0` to publish.
|
||||
|
||||
### Post-Release
|
||||
- [ ] Merge release/2.4.0 back to development
|
||||
- [ ] Delete release/2.4.0 branch
|
||||
- [ ] Verify CI pipeline triggered
|
||||
```
|
||||
75
plugins/ops-release-manager/commands/release-validate.md
Normal file
75
plugins/ops-release-manager/commands/release-validate.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: release validate
|
||||
description: Pre-release validation — verify version consistency, changelog, dependencies, and readiness
|
||||
---
|
||||
|
||||
# /release validate
|
||||
|
||||
Run pre-release checks to verify the project is ready for release.
|
||||
|
||||
## Visual Output
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - Validate Release |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Skills to Load
|
||||
|
||||
- skills/version-detection.md
|
||||
- skills/changelog-conventions.md
|
||||
|
||||
## Process
|
||||
|
||||
1. **Version Consistency**
|
||||
- Read version from all known locations
|
||||
- Verify all locations report the same version
|
||||
- Check version is greater than the latest git tag
|
||||
- Verify version follows SemVer format
|
||||
|
||||
2. **Changelog Validation**
|
||||
- Verify [X.Y.Z] section exists with today's date (or recent date)
|
||||
- Check all required categories are present if entries exist
|
||||
- Verify no empty [Unreleased] content was left behind
|
||||
- Check comparison links are updated
|
||||
|
||||
3. **Git State**
|
||||
- Working directory is clean
|
||||
- Branch is up to date with remote
|
||||
- No merge conflicts pending
|
||||
- All CI checks passing (if detectable)
|
||||
|
||||
4. **Dependency Check**
|
||||
- Lock file is up to date (package-lock.json, poetry.lock, Cargo.lock)
|
||||
- No known vulnerable dependencies (if audit tool available)
|
||||
- No unpinned dependencies in production config
|
||||
|
||||
5. **Documentation**
|
||||
- README references correct version
|
||||
- Migration guide exists for major versions
|
||||
- Breaking changes are documented
|
||||
|
||||
6. **Report**
|
||||
- Show pass/fail for each check
|
||||
- Block release if any critical check fails
|
||||
- Warn on non-critical issues
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
## Release Validation: v2.4.0
|
||||
|
||||
### Checks
|
||||
| Check | Status | Details |
|
||||
|-------|--------|---------|
|
||||
| Version consistency | PASS | 3/3 files match v2.4.0 |
|
||||
| Changelog | PASS | [2.4.0] section with 5 entries |
|
||||
| Git state | PASS | Clean, up to date |
|
||||
| Lock file | PASS | package-lock.json current |
|
||||
| Dependencies | WARN | 1 advisory (low severity) |
|
||||
| Documentation | PASS | README updated |
|
||||
|
||||
### Result: READY FOR RELEASE
|
||||
1 warning (non-blocking). Proceed with `/release tag`.
|
||||
```
|
||||
18
plugins/ops-release-manager/commands/release.md
Normal file
18
plugins/ops-release-manager/commands/release.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: Release management — version bumping, changelog updates, tag creation
|
||||
---
|
||||
|
||||
# /release
|
||||
|
||||
Release management with semantic versioning, changelog generation, and tag management.
|
||||
|
||||
## Sub-commands
|
||||
|
||||
| Sub-command | Description |
|
||||
|-------------|-------------|
|
||||
| `/release setup` | Setup wizard — detect version locations and release conventions |
|
||||
| `/release prepare` | Prepare release: bump versions, update changelog, create branch |
|
||||
| `/release validate` | Pre-release checks — verify versions, changelog, dependencies |
|
||||
| `/release tag` | Create and push git tag with release notes |
|
||||
| `/release rollback` | Revert a release — remove tag, revert version bump |
|
||||
| `/release status` | Show current version and unreleased changes |
|
||||
74
plugins/ops-release-manager/skills/changelog-conventions.md
Normal file
74
plugins/ops-release-manager/skills/changelog-conventions.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
description: Keep a Changelog format, Unreleased section management, and category ordering
|
||||
---
|
||||
|
||||
# Changelog Conventions Skill
|
||||
|
||||
## Overview
|
||||
|
||||
Standards for maintaining a changelog following the Keep a Changelog format (keepachangelog.com). The changelog is the primary release communication artifact.
|
||||
|
||||
## File Structure
|
||||
|
||||
```markdown
|
||||
# Changelog
|
||||
|
||||
All notable changes to this project will be documented in this file.
|
||||
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com),
|
||||
and this project adheres to [Semantic Versioning](https://semver.org).
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
### Added
|
||||
- New features go here during development
|
||||
|
||||
## [2.3.1] - 2026-01-15
|
||||
|
||||
### Fixed
|
||||
- Bug fix description
|
||||
|
||||
## [2.3.0] - 2026-01-01
|
||||
|
||||
### Added
|
||||
- Feature description
|
||||
|
||||
[Unreleased]: https://github.com/user/repo/compare/v2.3.1...HEAD
|
||||
[2.3.1]: https://github.com/user/repo/compare/v2.3.0...v2.3.1
|
||||
[2.3.0]: https://github.com/user/repo/releases/tag/v2.3.0
|
||||
```
|
||||
|
||||
## Category Ordering
|
||||
|
||||
Categories must appear in this order (only include categories with entries):
|
||||
|
||||
1. **Added** — New features
|
||||
2. **Changed** — Changes to existing functionality
|
||||
3. **Deprecated** — Features that will be removed in future
|
||||
4. **Removed** — Features removed in this release
|
||||
5. **Fixed** — Bug fixes
|
||||
6. **Security** — Security vulnerability fixes
|
||||
|
||||
## Unreleased Section Management
|
||||
|
||||
### During Development
|
||||
All changes go under `[Unreleased]`. Never create a versioned section until release time.
|
||||
|
||||
### At Release Time
|
||||
1. Replace `[Unreleased]` heading with `[X.Y.Z] - YYYY-MM-DD`
|
||||
2. Add new empty `[Unreleased]` section above
|
||||
3. Update comparison links at bottom of file
|
||||
|
||||
### Entry Writing Guidelines
|
||||
- Start with a verb (Add, Fix, Change, Remove, Deprecate)
|
||||
- Focus on user impact, not implementation details
|
||||
- Reference issue numbers where applicable
|
||||
- Keep entries concise (one line preferred)
|
||||
- Group related changes into a single entry when appropriate
|
||||
|
||||
## Comparison Links
|
||||
|
||||
Maintain comparison links at the bottom of the file:
|
||||
- `[Unreleased]` compares latest tag to HEAD
|
||||
- Each version compares to the previous version
|
||||
- First version links to the release tag
|
||||
99
plugins/ops-release-manager/skills/release-workflow.md
Normal file
99
plugins/ops-release-manager/skills/release-workflow.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
description: Release patterns, branching strategies, tagging, and pre-release versions
|
||||
---
|
||||
|
||||
# Release Workflow Skill
|
||||
|
||||
## Overview
|
||||
|
||||
End-to-end release workflow patterns including branching, tagging, and rollback procedures.
|
||||
|
||||
## Release Patterns
|
||||
|
||||
### Tag-Based Release (Simple)
|
||||
Best for: small projects, continuous deployment
|
||||
|
||||
1. Commit changes to main/development
|
||||
2. Update version files and changelog
|
||||
3. Create annotated tag: `git tag -a vX.Y.Z -m "message"`
|
||||
4. Push tag: `git push origin vX.Y.Z`
|
||||
5. CI triggers deployment from tag
|
||||
|
||||
### Branch-Based Release (Standard)
|
||||
Best for: projects with QA cycles, staged releases
|
||||
|
||||
1. Create branch: `git checkout -b release/X.Y.Z`
|
||||
2. Update version files and changelog on branch
|
||||
3. QA testing on release branch
|
||||
4. Merge to main: `git merge release/X.Y.Z`
|
||||
5. Tag on main: `git tag -a vX.Y.Z`
|
||||
6. Merge back to development: `git merge release/X.Y.Z`
|
||||
7. Delete release branch
|
||||
|
||||
## Git Tag Operations
|
||||
|
||||
### Creating Tags
|
||||
```bash
|
||||
# Annotated tag with release notes
|
||||
git tag -a vX.Y.Z -m "Release vX.Y.Z
|
||||
|
||||
Added:
|
||||
- Feature description
|
||||
|
||||
Fixed:
|
||||
- Bug fix description"
|
||||
|
||||
# Push single tag
|
||||
git push origin vX.Y.Z
|
||||
|
||||
# Push all tags
|
||||
git push origin --tags
|
||||
```
|
||||
|
||||
### Deleting Tags (Rollback)
|
||||
```bash
|
||||
# Delete local tag
|
||||
git tag -d vX.Y.Z
|
||||
|
||||
# Delete remote tag
|
||||
git push origin :refs/tags/vX.Y.Z
|
||||
```
|
||||
|
||||
## Pre-Release Workflow
|
||||
|
||||
For releases that need staged rollout:
|
||||
|
||||
1. `vX.Y.Z-alpha.1` — First alpha, feature incomplete
|
||||
2. `vX.Y.Z-alpha.2` — Updated alpha
|
||||
3. `vX.Y.Z-beta.1` — Feature complete, testing
|
||||
4. `vX.Y.Z-rc.1` — Release candidate, final validation
|
||||
5. `vX.Y.Z` — Stable release
|
||||
|
||||
Each pre-release tag follows the same tagging process but does not update the main changelog section.
|
||||
|
||||
## Rollback Procedure
|
||||
|
||||
### If Tag Not Yet Pushed
|
||||
1. Delete local tag
|
||||
2. Revert version commit
|
||||
3. Done
|
||||
|
||||
### If Tag Already Pushed
|
||||
1. Delete remote tag
|
||||
2. Delete local tag
|
||||
3. Revert version commit
|
||||
4. Push revert commit
|
||||
5. Notify team about release revert
|
||||
|
||||
### If Deployment Occurred
|
||||
1. Follow the above steps
|
||||
2. Trigger deployment of the previous version
|
||||
3. Verify rollback in production
|
||||
4. Post-mortem on what went wrong
|
||||
|
||||
## Safety Rules
|
||||
|
||||
- Never force-push tags without explicit user confirmation
|
||||
- Always create annotated tags (not lightweight)
|
||||
- Include release notes in tag message
|
||||
- Verify tag points to expected commit before pushing
|
||||
65
plugins/ops-release-manager/skills/semver-rules.md
Normal file
65
plugins/ops-release-manager/skills/semver-rules.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
description: Semantic versioning bump logic and conventional commit analysis
|
||||
---
|
||||
|
||||
# SemVer Rules Skill
|
||||
|
||||
## Overview
|
||||
|
||||
Rules for determining the correct version bump based on the nature of changes, following Semantic Versioning 2.0.0 (semver.org).
|
||||
|
||||
## Bump Type Rules
|
||||
|
||||
### MAJOR (X.0.0)
|
||||
Increment when making incompatible API changes:
|
||||
- Removing a public function, class, or endpoint
|
||||
- Changing function signatures (parameter types, return types)
|
||||
- Renaming public exports
|
||||
- Changing default behavior in a breaking way
|
||||
- Dropping support for a platform or runtime version
|
||||
|
||||
### MINOR (x.Y.0)
|
||||
Increment when adding functionality in a backwards-compatible manner:
|
||||
- Adding new functions, classes, or endpoints
|
||||
- Adding optional parameters to existing functions
|
||||
- New configuration options with sensible defaults
|
||||
- Deprecating functionality (without removing it)
|
||||
- Performance improvements that do not change behavior
|
||||
|
||||
### PATCH (x.y.Z)
|
||||
Increment when making backwards-compatible bug fixes:
|
||||
- Fixing incorrect behavior
|
||||
- Correcting documentation errors that affected usage
|
||||
- Security patches that do not change API
|
||||
- Fixing edge cases or error handling
|
||||
|
||||
## Conventional Commits Mapping
|
||||
|
||||
| Commit Prefix | Bump Type | Examples |
|
||||
|---------------|-----------|---------|
|
||||
| `feat:` | MINOR | New feature, new command, new option |
|
||||
| `fix:` | PATCH | Bug fix, error correction |
|
||||
| `docs:` | PATCH | Documentation update |
|
||||
| `chore:` | PATCH | Dependency update, cleanup |
|
||||
| `refactor:` | PATCH | Internal restructuring, no behavior change |
|
||||
| `perf:` | PATCH | Performance improvement |
|
||||
| `test:` | PATCH | Test additions or fixes |
|
||||
| `BREAKING CHANGE:` | MAJOR | Any commit with this footer |
|
||||
| `feat!:` / `fix!:` | MAJOR | Breaking change indicated by `!` |
|
||||
|
||||
## Pre-release Versions
|
||||
|
||||
For releases not yet stable:
|
||||
- Alpha: `X.Y.Z-alpha.N` — feature incomplete, unstable
|
||||
- Beta: `X.Y.Z-beta.N` — feature complete, testing
|
||||
- Release Candidate: `X.Y.Z-rc.N` — ready for release, final testing
|
||||
|
||||
Pre-release versions have lower precedence than the normal version:
|
||||
`1.0.0-alpha.1 < 1.0.0-beta.1 < 1.0.0-rc.1 < 1.0.0`
|
||||
|
||||
## Decision Flow
|
||||
|
||||
1. Any breaking changes? -> MAJOR
|
||||
2. Any new features? -> MINOR
|
||||
3. Only fixes and maintenance? -> PATCH
|
||||
4. When in doubt, ask the user
|
||||
58
plugins/ops-release-manager/skills/version-detection.md
Normal file
58
plugins/ops-release-manager/skills/version-detection.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
description: Detect version locations across project files and parse current version
|
||||
---
|
||||
|
||||
# Version Detection Skill
|
||||
|
||||
## Overview
|
||||
|
||||
Find and parse version strings from all standard locations in a project. Supports multiple language ecosystems.
|
||||
|
||||
## Detection Targets
|
||||
|
||||
### Node.js / JavaScript
|
||||
| File | Pattern | Example |
|
||||
|------|---------|---------|
|
||||
| `package.json` | `"version": "X.Y.Z"` | `"version": "2.3.1"` |
|
||||
| `package-lock.json` | `"version": "X.Y.Z"` (root) | `"version": "2.3.1"` |
|
||||
|
||||
### Python
|
||||
| File | Pattern | Example |
|
||||
|------|---------|---------|
|
||||
| `pyproject.toml` | `version = "X.Y.Z"` | `version = "2.3.1"` |
|
||||
| `setup.cfg` | `version = X.Y.Z` | `version = 2.3.1` |
|
||||
| `setup.py` | `version="X.Y.Z"` | `version="2.3.1"` |
|
||||
| `__version__.py` | `__version__ = "X.Y.Z"` | `__version__ = "2.3.1"` |
|
||||
|
||||
### Rust
|
||||
| File | Pattern | Example |
|
||||
|------|---------|---------|
|
||||
| `Cargo.toml` | `version = "X.Y.Z"` | `version = "2.3.1"` |
|
||||
|
||||
### Claude Marketplace
|
||||
| File | Pattern | Example |
|
||||
|------|---------|---------|
|
||||
| `marketplace.json` | `"version": "X.Y.Z"` | `"version": "2.3.1"` |
|
||||
| `plugin.json` | `"version": "X.Y.Z"` | `"version": "2.3.1"` |
|
||||
|
||||
### Documentation
|
||||
| File | Pattern | Example |
|
||||
|------|---------|---------|
|
||||
| `README.md` | Title containing `vX.Y.Z` | `# Project - v2.3.1` |
|
||||
| `CHANGELOG.md` | `## [X.Y.Z]` | `## [2.3.1] - 2026-01-15` |
|
||||
|
||||
## Git Tags
|
||||
|
||||
Parse existing tags to determine latest released version:
|
||||
- `git tag --sort=-v:refname` — list tags by version
|
||||
- Support both `vX.Y.Z` and `X.Y.Z` formats
|
||||
- Detect the project's tag convention from existing tags
|
||||
|
||||
## Version Parsing
|
||||
|
||||
Extract and validate SemVer components:
|
||||
- Major, Minor, Patch (required)
|
||||
- Pre-release identifier (optional): `-alpha.1`, `-beta.2`, `-rc.1`
|
||||
- Build metadata (optional): `+build.123`
|
||||
|
||||
Report any versions that do not conform to SemVer.
|
||||
27
plugins/ops-release-manager/skills/visual-header.md
Normal file
27
plugins/ops-release-manager/skills/visual-header.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Visual Header Skill
|
||||
|
||||
Standard visual header for ops-release-manager commands.
|
||||
|
||||
## Header Template
|
||||
|
||||
```
|
||||
+----------------------------------------------------------------------+
|
||||
| RELEASE-MANAGER - [Context] |
|
||||
+----------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Context Values by Command
|
||||
|
||||
| Command | Context |
|
||||
|---------|---------|
|
||||
| `/release setup` | Setup |
|
||||
| `/release prepare` | Prepare Release |
|
||||
| `/release validate` | Validate Release |
|
||||
| `/release tag` | Tag Release |
|
||||
| `/release rollback` | Rollback Release |
|
||||
| `/release status` | Status |
|
||||
| Agent mode | Release Management |
|
||||
|
||||
## Usage
|
||||
|
||||
Display header at the start of every command response before proceeding with the operation.
|
||||
Reference in New Issue
Block a user