Automation & Ops release-automationsemverchangeloggit-taggingmacos-notarizationgithub-releasesconventional-commits

Chops Release Pipeline Skill

Infers the next version from git history, updates the changelog and marketing site, then runs packaging, notarization, and GitHub Release in one guided pipeline.

FollowSkills review · FSRS-1.0
Use with care
53/ 100 5-point scale 2.7 / 5
This review was completed under FSRS 1.0. Dimension scores are not converted; it is queued for re-review under FSRS 2.0.
1 2 3 4 5 6
1Utility9 / 20 · 2.3/5

The project's own release-automation workflow (macOS code signing/notarization, git tagging, release scripting), for the project's maintainer — involves signing credentials and real releases, not a general-purpose skill.

2Reliability12 / 20 · 3.0/5
3Safety16 / 25 · 3.2/5

Involves Apple signing/notarization credentials and real software releases, but has pre-flight checks (clean working tree, branch confirmation) as guardrails.

4Evidence4 / 15 · 1.3/5
5Usability7 / 10 · 3.5/5
6Maintenance5 / 10 · 2.5/5
Evidence confidence:Low Reviewed Jul 17, 2026
Review evidence [1]
See the full review method →

What does this skill do, and when should you use it?

This is a Claude Code skill bundled inside the Chops repository (a macOS app for organizing AI agent skills) that automates that project's own release process. It verifies release prerequisites (.env, Apple notarization credentials, a clean git tree), infers a semver bump from conventional commit messages, and after user confirmation rewrites the CHANGELOG, bumps the marketing site version, and runs the repo's release.sh for archiving, DMG creation, notarization, tagging, and GitHub Release. It is tightly coupled to the Chops repo's scripts and file layout — best treated as an in-repo workflow rather than a general-purpose release tool.

Reads git tags and commit history to infer the next semver version (feat commits trigger a minor bump, fix/chore/docs a patch, BREAKING CHANGE asks the user); verifies the Apple notarization keychain profile via xcrun notarytool; rewrites the Unreleased section of CHANGELOG.md into user-facing entries; edits site/src/pages/index.astro to update the version shown on the marketing site; commits, pushes, and runs ./scripts/release.sh <version>, which handles xcodegen, archive, export, DMG, notarization, stapling, git tagging, appcast update, and the GitHub Release.

  1. A Chops maintainer who just merged a batch of feat commits wants the next minor version inferred and the full release pipeline executed automatically
  2. A maintainer wants to catch missing notarization credentials or .env config before the release script fails at the last step
  3. A team wants changelog entries rewritten from commit messages into user-facing descriptions instead of echoing commit prefixes
  4. After a release, the minimum version displayed on the chops.md marketing site needs to be synced
  5. A developer studying how to write a Claude Code in-repo skill with human confirmation gates and a multi-step pipeline

What are this skill's strengths and limitations?

Pros
  • Covers the entire flow from version inference through notarization, tagging, and GitHub Release, eliminating manual steps
  • Built-in guardrails: stops immediately if .env is missing, the tree is dirty, or you're not on main
  • Every key decision (version, changelog entries) requires explicit user confirmation — no silent releases
  • Never retries a failed release script, avoiding duplicate tags or duplicate notarization
  • Changelog entries are rewritten as user-facing descriptions rather than copied commit messages
Limitations
  • Only works for the Chops repository — depends on its specific release.sh, site/ layout, and file paths
  • Relies on the mcp__conductor__AskUserQuestion MCP tool, which must be replaced or adapted in other environments
  • Requires macOS and a configured Apple Developer notarization setup, a nontrivial cost and barrier
  • The repository has no automated test suite; the README explicitly says to validate manually
  • Licensed under FSL-1.1-MIT (not standard OSI open source) — check terms before commercial reuse

How do you install this skill?

The skill ships with the Chops repository at .claude/skills/release/SKILL.md. Clone the repo and Claude Code discovers it automatically: git clone https://github.com/Shpigford/chops.git && cd chops. No separate installation is needed; to actually run a release you must also configure APPLE_TEAM_ID, APPLE_ID, and SIGNING_IDENTITY_NAME in .env (copy from .env.example) and set up notarization credentials on macOS.

How do you use this skill?

From the Chops repo, on the main branch with a clean working tree, prompt Claude Code with something like "cut a new release". The skill verifies prerequisites, then walks you through confirming the version and changelog entries before running release.sh. Note: it depends heavily on the repo's scripts/release.sh, the site/ directory, and the mcp__conductor__AskUserQuestion tool, so it will not work outside this repository without modification.

How does this skill compare with similar options?

This is essentially a repo-specific release workflow. It addresses the same problem space as general release tools like semantic-release or changesets (version inference from commits, changelog generation, automated publishing), but those are language-ecosystem-generic tools while this skill is a Claude Code orchestration layer tailored to Chops' macOS notarization pipeline.

FAQ

Can I use this skill in my own project?
Not directly. It hardcodes Chops' release.sh script, the site/src/pages/index.astro path, and the conductor MCP tool. To reuse the approach, you'd need to swap in your own release script and file paths.
What prerequisites and costs are involved?
You need macOS 15+, an Apple Developer account (notarization uses an app-specific password), git, and a configured .env at the repo root. Notarization is included with Apple Developer Program membership — no per-release fee.
What happens if the release script fails?
The skill has an explicit rule: do not retry automatically. It reports the error output and stops. This is intentional to prevent duplicate tags or double notarization — you diagnose and re-trigger manually.
Is the version number decided automatically?
Partially. With conventional commits it applies rules (feat→minor, fix/chore→patch), but BREAKING CHANGE markers or ambiguous messages trigger an interactive question, and the final version is always confirmed with you before anything ships.

More skills from this repository

All from Shpigford/chops

Related skills