release

Coordinate semver version bumps, tagging, and CI-driven draft GitHub releases.

2|Updated May 8, 2026
One-click install
npx skills add https://github.com/akiotanaka847/qaio-desktop --skill release-akiotanaka847
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/akiotanaka847/qaio-desktop/tree/main/skills/release
Command: npx skills add https://github.com/akiotanaka847/qaio-desktop --skill release-akiotanaka847

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill removes the manual, error-prone steps involved in shipping a new Qaio version by providing a clear release workflow that coordinates version bumps, tagging, CI builds, and release-note preparation.

Core Features & Use Cases

  • Unified version bump across all packages: Applies a single semver version to every related package in the repository, with patch-by-default behavior.
  • Controlled semver changes with guardrails: Defaults to patch bumps, and requires explicit user permission for minor bumps.
  • CI-driven build, signing, and notarization (macOS): Uses the repository’s CI to build for both Apple CPU architectures, sign, notarize, and publish artifacts as a draft release for user review.

Quick Start

Use the release skill to bump the Qaio version, generate release notes, and let CI produce a draft GitHub release that you review and publish.

Frequently Asked Questions about release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate semver version bumps and release tagging with GitHub Actions?

To automate semver version bumps and tagging with GitHub Actions, this Skill applies a single patch version across all repository packages, tags the commit, and pushes it to trigger CI-driven builds. It defaults to patch bumps and requires explicit permission for minor version changes.

What's the best way to draft signed GitHub releases with macOS notarization?

Drafting signed GitHub releases with macOS notarization uses repository CI to build for both Apple CPU architectures, sign the artifacts, and submit them for notarization. The process stops after creating a draft GitHub release for manual user review and publishing.

Do I need to write release notes before creating a git tag for a production release?

Yes, you must write a .github/release-notes/<version>.md file before tag creation when preparing a production release. This ensures user-visible release notes are created before tagging and coordinate with the subsequent CI-driven draft release.

Can I use this release workflow for minor version bumps, or is it only for patch updates?

You can use this workflow for minor version bumps, but it requires explicit user permission before proceeding. The process defaults to patch-level updates and applies guardrails to control minor semver changes during production release preparation.

How does CI-driven code signing and notarization work for macOS builds during a release?

CI-driven code signing and notarization for macOS builds works by using the repository's CI pipeline to build for both Apple CPU architectures, sign the resulting artifacts, and submit them for notarization before publishing them as a draft GitHub release.