playbooks

home / skills / falkicon / mechanic / s-release

s-release skill

/.agent/skills/s-release

This skill guides WoW addon releases end-to-end, automating bump, changelog, commit, and tag steps to publish a new version.

npx playbooks add skill falkicon/mechanic --skill s-release

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

Files (1)
SKILL.md
2.4 KB
---
name: s-release
description: >
  Prepare and execute an addon release, including version bumping, changelog
  updates, git tagging, and validation. Use when ready to publish a new version.
  Triggers: release, version bump, changelog, git tag, publish.
---

# Releasing WoW Addons

Expert guidance for the full addon release workflow using Mechanic automation.

## Related Commands

- [c-release](../../commands/c-release.md) - Automated release workflow

## CLI Commands (Use These First)

> **MANDATORY**: Always use CLI commands before manual exploration.

| Task | Command |
|------|---------|
| Full Release | `mech release MyAddon 1.2.0 "Release message"` |
| Bump Version | `mech call version.bump -i '{"addon": "MyAddon", "version": "1.2.0"}'` |
| Add Changelog | `mech call changelog.add -i '{"addon": "MyAddon", "version": "1.2.0", "message": "..."}'` |
| Commit Changes | `mech call git.commit -i '{"addon": "MyAddon", "message": "Release 1.2.0"}'` |
| Create Tag | `mech call git.tag -i '{"addon": "MyAddon", "version": "1.2.0"}'` |

## Capabilities

1. **Full Automation** — Single-command release workflow (bump → changelog → commit → tag)
2. **Version Management** — Consistent version bumping across `.toc` files
3. **Changelog Maintenance** — Structured `CHANGELOG.md` updates with categories
4. **Git Integration** — Automated commits and annotated tags

## Routing Logic

| Request type | Load reference |
|--------------|----------------|
| Release workflow, changelog format | [../../docs/integration/release.md](../../docs/integration/release.md) |
| CLI Reference | [../../docs/cli-reference.md](../../docs/cli-reference.md) |

## Quick Reference

### The One-Command Release
```bash
# Recommended: Validates → Bumps → Changelogs → Commits → Tags
mech release MyAddon 1.2.0 "Added cooldown tracking and fixed memory leaks"
```

### Pre-Release Checklist
1. **Validate**: `mech call addon.validate -i '{"addon": "MyAddon"}'`
2. **Lint**: `mech call addon.lint -i '{"addon": "MyAddon"}'`
3. **Test**: `mech call addon.test -i '{"addon": "MyAddon"}'`
4. **Audit**: `mech call addon.deprecations -i '{"addon": "MyAddon"}'`

### Changelog Categories
- `### Added`: New features
- `### Changed`: Changes to existing features
- `### Fixed`: Bug fixes
- `### Removed`: Removed features
- `### Deprecated`: Features to be removed
- `### Security`: Security-related changes

Overview

This skill prepares and executes World of Warcraft addon releases, handling version bumps, changelog updates, git commits and tags, and validation. It bundles a recommended one-command workflow and individual automation steps to ensure consistent, reproducible releases. Use it when you are ready to publish a new addon version and want reliable, repeatable steps.

How this skill works

The skill drives Mechanic CLI commands to validate the addon, bump versions in .toc files, append structured entries to CHANGELOG.md, commit release changes, and create annotated git tags. It can run a full release in one step (validate → bump → changelog → commit → tag) or execute each subtask separately for granular control. Hooks perform linting, testing, and deprecation audits before finalizing the release.

When to use it

  • Publishing a new addon version to distribution channels
  • After merging feature branches that require a formal version bump
  • When you need consistent changelog entries and git tags for releases
  • Before tagging a public release to ensure validation and tests pass
  • When standardizing release workflows across a team

Best practices

  • Always run the CLI validation and lint steps before bumping the version
  • Use the one-command release for routine releases; use individual commands for investigatory or staged releases
  • Write concise changelog messages and use the provided categories (Added, Changed, Fixed, etc.)
  • Verify .toc files are consistent across builds to avoid mismatched versions
  • Create annotated git tags to preserve release metadata and facilitate rollbacks

Example use cases

  • Run a full release: mech release MyAddon 1.2.0 "Added cooldown tracking and fixed memory leaks"
  • Bump only the version via: mech call version.bump -i '{"addon": "MyAddon", "version": "1.2.0"}'
  • Add a changelog entry before committing: mech call changelog.add -i '{"addon":"MyAddon","version":"1.2.0","message":"..."}'
  • Commit and tag programmatically to keep CI/CD deterministic: mech call git.commit ... then mech call git.tag ...
  • Pre-release checklist automation: validate → lint → test → audit before final mech release

FAQ

Can I run just part of the workflow?

Yes. Each step (validation, version bump, changelog, commit, tag) is available as an individual CLI command so you can run only the parts you need.

What changelog format is used?

CHANGELOG.md entries are structured with categories like Added, Changed, Fixed, Removed, Deprecated, and Security for consistent release notes.

Does this update .toc files automatically?

Yes. The version.bump command updates version strings in .toc files to keep all manifest files consistent.

Should I always use the one-command release?

It is recommended for routine releases because it validates and automates all steps, but use individual commands when you need manual inspection or staged deployment.