home / skills / madappgang / claude-code / release

release skill

/skills/release

This skill guides you through releasing new plugin versions by updating plugin.json and marketplace.json, tagging, and verifying marketplace visibility.

npx playbooks add skill madappgang/claude-code --skill release

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.9 KB
---
name: release
description: Plugin release process for MAG Claude Plugins marketplace. Covers version bumping, marketplace.json updates, git tagging, and common mistakes. Use when releasing new plugin versions or troubleshooting update issues.
---

# Plugin Release Process

Complete guide for releasing new versions of plugins in the MAG Claude Plugins marketplace.

## Critical Understanding

Claude Code plugin discovery works through **TWO** configuration files that **MUST BOTH BE UPDATED**:

1. **`plugins/{plugin-name}/plugin.json`** - The plugin's own version metadata
2. **`.claude-plugin/marketplace.json`** - The marketplace catalog (what users see when browsing)

**Why both?**
- `plugin.json` - Defines the plugin itself (agents, commands, version)
- `marketplace.json` - The "catalog" that Claude Code reads for plugin discovery
- Users run `/plugin marketplace update` which reads `marketplace.json`
- **If you only update `plugin.json`, users won't see the new version!**

---

## Release Checklist

### Step 1: Update Plugin Files

- [ ] `plugins/{plugin-name}/plugin.json` - Update `version` field
- [ ] `plugins/{plugin-name}/agents/*.md` - Add new agents (if any)
- [ ] `plugins/{plugin-name}/commands/*.md` - Update commands (if any)
- [ ] `plugins/{plugin-name}/skills/*/SKILL.md` - Add new skills (if any)

### Step 2: Update Documentation

- [ ] `CHANGELOG.md` - Add new version entry at the top
- [ ] `RELEASES.md` - Add detailed release notes at the top
- [ ] `CLAUDE.md` - Update ALL version references (6+ locations)

### Step 3: ⚠️ **CRITICAL** - Update Marketplace Catalog

**File:** `.claude-plugin/marketplace.json`

Update TWO fields:

1. **Marketplace metadata version** (line ~10):
   ```json
   "metadata": {
     "version": "3.3.0"  // ← Update this
   }
   ```

2. **Specific plugin version** (in plugins array):
   ```json
   "plugins": [
     {
       "name": "frontend",
       "version": "3.3.0",      // ← Update this (CRITICAL!)
       "description": "..."     // ← Update if description changed
     }
   ]
   ```

### Step 4: Commit and Tag

```bash
# Commit all changes
git add -A
git commit -m "feat({plugin}): v{X.Y.Z} - {Feature summary}"

# Create tag (format: plugins/{plugin-name}/v{X.Y.Z})
git tag -a plugins/{plugin}/v{X.Y.Z} -m "..."

# Push
git push origin main
git push origin plugins/{plugin}/v{X.Y.Z}
```

### Step 5: Verify

```bash
/plugin marketplace update mag-claude-plugins
# Should show new version ✅
```

---

## Common Mistakes

### ❌ #1: Forgot to update marketplace.json

**Symptom:** Users still see old version after `/plugin marketplace update`

**Fix:**
```bash
# Update .claude-plugin/marketplace.json
vim .claude-plugin/marketplace.json
# Update plugins[].version field

git add .claude-plugin/marketplace.json
git commit -m "fix(marketplace): Update {plugin} version to v{X.Y.Z}"
git push origin main
```

### ❌ #2: Wrong git tag format

**Wrong:** `frontend-v3.3.0`, `v3.3.0`, `frontend/v3.3.0`
**Correct:** `plugins/frontend/v3.3.0` ✅

### ❌ #3: Inconsistent versions

**Problem:** plugin.json says v3.3.0 but marketplace.json says v3.2.0

**Prevention:** Use checklist, search for old version: `grep -r "3.2.0" .`

---

## Version Numbering

**MAJOR (X.0.0):** Breaking changes (removed agents, changed behavior)
**MINOR (x.Y.0):** New features (new agents/commands, backward compatible)
**PATCH (x.y.Z):** Bug fixes (no new features, backward compatible)

---

## Quick Reference

**Minimal checklist:**

1. ✅ Update `plugins/{plugin}/plugin.json` version
2. ✅ Update `.claude-plugin/marketplace.json` plugin version ⚠️ **CRITICAL**
3. ✅ Update `CHANGELOG.md`, `RELEASES.md`, `CLAUDE.md`
4. ✅ Commit: `git commit -m "feat({plugin}): v{X.Y.Z} - {summary}"`
5. ✅ Tag: `git tag -a plugins/{plugin}/v{X.Y.Z} -m "..."`
6. ✅ Push: `git push origin main && git push origin plugins/{plugin}/v{X.Y.Z}`
7. ✅ Verify: `/plugin marketplace update` shows new version

---

## Example Release

```bash
# 1. Update versions
vim plugins/frontend/plugin.json          # version: "3.3.0"
vim .claude-plugin/marketplace.json       # plugins[0].version: "3.3.0"  ← DON'T FORGET!
vim CHANGELOG.md RELEASES.md CLAUDE.md

# 2. Commit
git add -A
git commit -m "feat(frontend): v3.3.0 - Multi-Model Plan Review"

# 3. Tag
git tag -a plugins/frontend/v3.3.0 -m "Frontend Plugin v3.3.0"

# 4. Push
git push origin main
git push origin plugins/frontend/v3.3.0

# 5. Verify
/plugin marketplace update mag-claude-plugins
# Output: frontend v3.3.0 ✅
```

---

## Troubleshooting

**Q: Users still see old version**
**A:** Check `.claude-plugin/marketplace.json` - version must match `plugin.json`

**Q: Tag already exists**
**A:** `git tag -d {tag}` then `git push origin :{tag}` then recreate

**Q: How to test locally?**
**A:** `/plugin marketplace add /path/to/claude-code`

---

**Related:** [RELEASE_PROCESS.md](../../RELEASE_PROCESS.md) - Full detailed documentation

**Last Updated:** November 13, 2025

Overview

This skill automates and documents the plugin release process for the MAG Claude Plugins marketplace. It guides maintainers through version bumps, marketplace catalog updates, git tagging, and verification steps so new plugin versions become discoverable to users.

How this skill works

The skill inspects both the plugin's own version metadata and the marketplace catalog to ensure they match. It highlights required edits (plugin.json and .claude-plugin/marketplace.json), suggests commit and tag formats, and verifies release visibility with the marketplace update command. It also flags common mistakes and provides remediation steps.

When to use it

  • Releasing a new plugin version to the MAG Claude Plugins marketplace
  • Troubleshooting why users still see an old plugin version
  • Preparing release notes and updating CHANGELOG/RELEASES/CLAUDE references
  • Creating and pushing a release git tag in the correct format
  • Verifying marketplace discovery after pushing changes

Best practices

  • Always update both plugins/{plugin}/plugin.json and .claude-plugin/marketplace.json to the same version
  • Use the prescribed git tag format: plugins/{plugin}/vX.Y.Z
  • Update changelogs and all documentation references before committing
  • Commit with a structured message, e.g. feat({plugin}): vX.Y.Z - short summary
  • Run /plugin marketplace update mag-claude-plugins to confirm visibility after push

Example use cases

  • Bump a plugin from 1.2.0 to 1.3.0 after adding a backward-compatible agent
  • Fix a release where users see the old version by updating marketplace.json and pushing a new commit
  • Recover from an incorrectly named tag by deleting the bad tag and recreating plugins/{plugin}/vX.Y.Z
  • Prepare a patch release for a bug fix and follow semantic versioning rules
  • Test a local marketplace by adding a local path before publishing to the central catalog

FAQ

Why do I need to update two files for a release?

Claude Code reads the marketplace catalog separately from the plugin package. The plugin.json defines the plugin, while .claude-plugin/marketplace.json is the catalog users fetch. Both must match for users to see the new version.

What is the correct git tag format?

Use plugins/{plugin}/vX.Y.Z (for example, plugins/frontend/v3.3.0). Other formats like v3.3.0 or frontend-v3.3.0 are rejected.

Users still see the old version after I pushed changes. What next?

Check .claude-plugin/marketplace.json to ensure the plugin entry matches plugin.json, commit and push the change, then run /plugin marketplace update mag-claude-plugins to verify.