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:
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
|
||||
Reference in New Issue
Block a user