Skill.md検索

バージョン番号を指定するだけで、CHANGELOGの更新、Cargo.tomlのバージョン変更、Gitタグ作成をまとめて自動実行できます。 GitHub Actionsが自動的にテスト実行、クロスプラットフォームビルド（Linux/macOS、x86_64/arm64）、GitHubリリース作成を行います。 Semantic Versioning（メジャー・マイナー・パッチ）のルールに基づいた適切なバージョン番号選定をガイドします。 Homebrewへの公開も自動化できるため、複数プラットフォームでのリリース管理が簡単になります。 Rustプロジェクトを定期的にリリースしている開発者・チーム リリース作業のミスを減らしたいメインテナー クロスプラットフォーム対応のコマンドラインツール開発者 自動化を通じてリリース頻度を高めたいプロダクトマネージャー /release vで呼び出します。mainブランチにいること、未コミット変更がないこと、CIが通っていることが前提条件です。最新タグと前回リリース以降のコミット一覧を確認し、Semantic Versioningガイド（BREAKING CHANGEでメジャー更新、feat:でマイナー更新、fix:でパッチ更新）に従ってバージョンを決定します。cargo fmt・cargo clippy・cargo testで品質チェック後、CHANGELOG.mdの[Unreleased]を[] - に変更、Cargo.tomlの[workspace.package]versionを更新し、コミット・タグ作成・プッシュします。GitHub Actionsが自動実行してテスト、Linux/macOS各アーキテクチャ用ビルド、GitHubリリース作成を行い、その後Homebrewフォーミュラの更新も可能です。

Conventional Commits 規約に基づいたコミットメッセージの書き方を確認できます。 feat:（新機能）、fix:（バグ修正）、chore:（内部改善）、ci:（CI設定）など、適切なプレフィックスを状況に応じて選べるようになります。 正しいプレフィックスでコミットするだけで、自動生成される CHANGELOG（変更履歴）に機能や修正が自動で掲載される仕組みになり、リリース時の情報整理が楽になります。 スコープ（例：feat(logs):）を追加して、変更箇所をより詳しく伝えられます。 プロジェクトで統一されたコミットメッセージルールを守りたい開発者 CHANGELOG を自動生成する仕組みを構築しているプロジェクトチーム ユーザー向けリリースノートを効率的に作成したい開発リード コミット履歴から機能変更と内部改善を明確に区分したい組織 本プロジェクトでは Conventional Commits を採用し、GoReleaser による自動 CHANGELOG 生成に対応しています。ユーザー向けプレフィックスは feat:（新しいCLIコマンドや機能）、fix:（ユーザーが遭遇するバグ）、BREAKING CHANGE: （既存動作の変更）で CHANGELOG に含まれ、内部向けは ci:（CI設定・linter）、chore:（開発ツール・依存更新）、docs:、refactor:、test:、style:、perf:、build: で CHANGELOG に含まれません。判定基準として feat と chore は「ユーザー向け機能か開発者向けツールか」、fix と ci は「ユーザーが遭遇するバグか CI パイプライン問題か」で区別します。スコープはオプションで追加可能（例：feat(logs):）です。

最新のGitタグから現在までのコミット履歴を自動で分析できます。 feat・fix・docs など Conventional Commits プレフィックスに基づいて変更内容を自動分類できます。 破壊的変更（BREAKING CHANGE）を検出し、メジャーバージョン更新を提案できます。 セマンティックバージョニング（v1.2.3 形式）に従ったバージョン番号を自動提案できます。 リリースノート（Changelog）の案を自動生成し、GitHub のコンパリソンリンクも含められます。 ライブラリ・パッケージを管理し、定期的にリリースするエンジニア チーム開発でバージョン管理を統一したいプロジェクトリード Conventional Commits ワークフローを導入しているチーム リリース作業の属人化を減らし、標準化したい組織 本スキルは git タグからの変更分析とバージョン提案の標準プロセス を提供します。手順1：現状取得ではgit tag -l 'v*.*.*' | sort -V | tail -1で最新セマンティックタグ取得（v1 等メジャータグ除外）、タグがない場合は初期コミットから分析。git log ${LATEST_TAG}..HEAD --oneline --no-mergesでコミット一覧取得、git diff --statで変更ファイル一覧確認、git tag -lで全タグ表示。手順2：変更分析でコミットを分類（feat:新機能→マイナー↑、fix:修正→パッチ↑、docs・refactor・perf・test・chore→パッチ↑、BREAKING CHANGE→メジャー↑）。手順3：出力形式は、現在バージョン・提案バージョン・変更タイプ（patch/minor/major）、新機能・バグ修正・その他カテゴリに分類した変更一覧、破壊的変更記載、リリースノート案（What's Changed + Full Changelog リンク）、次ステップ（/release-version {VERSION} コマンド）を提示。バージョン決定ルール：v1.2.3 現在で①破壊的変更あり→v2.0.0、②feat あり→v1.3.0、③修正のみ→v1.2.4、初回リリースは v1.0.0 提案。