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>
2026-02-06 14:52:11 -05:00
parent 5098422858
commit 2d51df7a42
321 changed files with 13582 additions and 1019 deletions
--- a/plugins/ops-release-manager/skills/changelog-conventions.md
+++ b/plugins/ops-release-manager/skills/changelog-conventions.md
@@ -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
--- a/plugins/ops-release-manager/skills/release-workflow.md
+++ b/plugins/ops-release-manager/skills/release-workflow.md
@@ -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
--- a/plugins/ops-release-manager/skills/semver-rules.md
+++ b/plugins/ops-release-manager/skills/semver-rules.md
@@ -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
--- a/plugins/ops-release-manager/skills/version-detection.md
+++ b/plugins/ops-release-manager/skills/version-detection.md
@@ -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.
--- a/plugins/ops-release-manager/skills/visual-header.md
+++ b/plugins/ops-release-manager/skills/visual-header.md
@@ -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.