はじめに
チームで Skill やエージェント、MCP サーバーをまとめた「ツールキット」を社内共有していると、地味に面倒なのがリリース公開作業です。
前回のタグからの差分を眺め、変更点を分類してリリースノートにまとめ、セマンティックバージョニングで次の番号を決め、タグを切って公開する、一つひとつは難しくないのですが、毎回手でやると抜け漏れが出ますし、リリースノートの体裁もバラつきがちです。
この定型作業を Claude Code の Skill にまとめてみたので、実際に動かしたログとあわせて紹介します。
題材は GitLab で共有しているツールキット（Skill・エージェント・MCP が混在するリポジトリ）で、公開には GitLab CLI の glab を使います。
今回作った Skill のポイントは、全部を自動化しないことです。
リリースノートの下書きと次バージョンの提案まではやらせて、採番と公開だけは必ず人間が確認・承認する設計（human-in-the-loop）にしています。
今回作成したSkillがやること
ワークフローはざっくり次の8ステップです。
ポイントは、4 と 7 が「提案」と「実行」に分かれていて、その間の 6 で必ず止まることです。
バージョン採番という後戻りしづらい判断を、AI に勝手にやらせないための区切りです。
図の通り、6 で修正が入れば 4 に戻ってやり直し、承認されて初めて公開 7 に進みます。
前提
- 公開対象が正しいリリースブランチ（既定は
main/master）であること
公開対象が正しいリリースブランチでない場合はステップの途中で、main / master へスイッチします。
-
glabがインストール・認証済みであること（glab auth statusで確認）
glab が未インストールならステップの途中で、
macOS / Linux は brew install glab、
Windows は winget install glab.glab などで導入し、
glab auth login で認証します。
実際の公開ステップ
GitLab 上のデモ用ツールキットリポジトリ（直近タグ v0.3.0）に、新しい Skill を1つ追加した状態から公開してみます。各ステップで Skill が実行するコマンドと、その実出力を載せます。
ステップ1: 現在のバージョンを把握
$ git describe --tags --abbrev=0
v0.3.0
直近タグは v0.3.0。既存タグが v 付きなので、提案する次バージョンも v 付きに揃えます（接頭辞スタイルを既存に合わせるのも Skill のルールにしています）。
ステップ2-3: 差分収集と部品ごとのバージョン変更
$ git log v0.3.0..HEAD --no-merges --oneline
cd240e5 feat: greeting-skill を追加（時間帯に応じた挨拶を生成する Skill）
$ git diff v0.3.0..HEAD --stat
greeting-skill/SKILL.md | 14 ++++++++++++++
1 file changed, 14 insertions(+)
$ git diff v0.3.0..HEAD -- '**/SKILL.md' '**/*.json' '**/*.toml' | grep -iE '^\+.*version|^\+name:'
+name: greeting-skill
SKILL.md / *.json / *.toml の差分から name: や version 行を拾うことで、「どの部品がどう変わったか」を機械的に拾えます。今回は 🧩 Skill greeting-skill が新規追加されたことが分かります。
ステップ4: 次バージョンを提案
判断材料はこうです。
- 変更内容: 🧩 Skill
greeting-skillを新規追加（後方互換の機能追加・破壊的変更なし） - 現在版
v0.3.0は0.x系 - 後方互換の機能追加 → マイナーバージョンを上げる
よって v0.4.0 を提案します。ここで Skill は提案に留め、確定は人間に委ねます。
ステップ5: リリースノート下書きを生成
Keep a Changelog の6カテゴリ（Added / Changed / Deprecated / Removed / Fixed / Security）に振り分け、該当のないカテゴリは見出しごと削除します。
## [v0.4.0] - 2026-06-13
挨拶文を自動生成する新しい Skill を追加したマイナーアップデートです。これまでの使い方が動かなくなる変更（破壊的変更）はありません。
### Added（追加）
- 🧩 Skill `greeting-skill` — 相手の名前と現在時刻から、朝・昼・夜に応じた挨拶文（例：「おはようございます、〇〇さん。」）を生成する Skill を追加しました。「挨拶して」と頼むだけで時間帯に合った一文が返ります。
執筆方針として「誰が読んでも分かる平易な言葉で書く」「破壊的変更は冒頭サマリで必ず触れ、該当行の行頭に **破壊的:** を付ける」をルール化しています。リリースノートを読むのは必ずしも開発者だけではないので、専門用語には一言補足を添えるようにしています。
ステップ6: 停止してレビュー
ここが必須チェックポイントです。下書き全文と「提案バージョン + 根拠」を提示して、いったん止まります。バージョンや文面の修正があればここで直し、再提示します。今回はそのまま v0.4.0 で承認しました。
ステップ7: 承認後に公開
$ glab release create v0.4.0 --name "v0.4.0" --notes-file release-notes-v0.4.0.md
• Validating tag v0.4.0
• Tag does not exist.
• No ref provided. Creating the tag from the latest state of the default branch.
• using default branch "main" as ref
• Creating or updating release repo=leomarokun/demo tag=v0.4.0
✓ Release created: url=https://gitlab.com/leomarokun/demo/-/releases/v0.4.0
✓ Release succeeded after 1.14 seconds.
$ git fetch --tags origin
* [new tag] v0.4.0 -> v0.4.0
タグ v0.4.0 が作成され、リリースが公開されました。
ステップ8: 完了報告と通知
公開すると、GitLab のリリース Atom フィード経由で購読者に通知が届きます。このフィードを RSS リーダーや Slack の購読機能に登録しておけば、新バージョンが出たときに自動で気付けます。
VSCode の RSS リーダー拡張機能で購読しているとこんな感じで表示されます。
Gitlab のリリースノートからは見るとこんな感じになります。
タグからも v0.4.0 が追加されていることが確認できます。
GitLab のリリース機能・Atom フィードの詳細は公式ドキュメントを確認してください。
まとめ
定型のリリース公開作業を Claude Code の Skill にまとめてみました。
同じように「毎回やっているけど少しずつ面倒」な定型作業は、フォーマットを標準に寄せてガードレールを明文化すれば、Skill 化の良い候補になりそうです。社内ツールキットを GitLab で運用している方の参考になれば幸いです。