release-process

# Release Process Guidance

Execute semantic versioning releases with bracket-based version freezing. This skill helps prevent version thrashing and coordinate releases across single projects, monorepos, plugins, and multi-component systems.

## Quick Start: 6-Step Release Process

Follow these steps in order. Use references for complex scenarios (scope creep, multi-component, breaking changes).

### Step 1: Determine Scope

What's changing? Pick ONE:

**PATCH** (bump Z: 1.0.2 → 1.0.3) — Fixes, clarifications, no user-facing additions
- Bug fixes in existing code
- Documentation updates or rewording
- Correcting typos and wording
- Better examples or explanations of existing features
- Improving performance (without API change)
- Adding warnings/guardrails to existing functionality
- Restructuring guides for clarity (same content)

**MINOR** (bump Y, reset Z: 1.0.5 → 1.1.0) — New capabilities, backward compatible
- New commands or features users can access
- New tool access or permissions
- New reference guides or entirely new sections
- Expanding existing API with new methods
- Adding completely new capabilities

**MAJOR** (bump X, reset Y,Z: 1.5.2 → 2.0.0) — Breaking changes
- Removing or renaming commands
- Changing behavior incompatibly
- Changing output format incompatibly
- Restructuring that requires user migration

⚠️ **Key distinction:** "Clarifying existing feature" (PATCH) ≠ "Adding new feature" (MINOR)

⚠️ **If uncertain:** Run `git diff` to see exact changes. Don't rely on memory.

### Step 2: Find Current Version

```bash
# Single-component (pick one):
grep '"version"' package.json
grep 'version:' SKILL.md frontmatter
grep 'version =' Cargo.toml

# Multi-component:
grep -r '"version"' .
```

### Step 3: Apply Bracket Rules

**Core principle:** Version freezes at scope level until commit. Can jump up, never down.

| If Currently At | And Discover | Do This | Example |
|---|---|---|---|
| 1.0.1 (fresh) | Patch work | Bump Z | 1.0.1 → 1.0.2 |
| 1.0.1 (fre