Release

リリースワークフロー

このスキルは、linear-cli プロジェクトのリリースを作成して公開するための体系的なワークフローを提供します。変更履歴の管理、バージョンの更新、テスト、タグ付けを行います。

使用するタイミング

linear-cli の新しいバージョンをリリースする準備をするときに、このスキルを使用します。このワークフローにより、すべての変更が記録され、テストに合格し、公開前にバージョンに適切なタグが付けられていることを確認できます。

前提条件

以下のツールが使用できることを確認してください。

• 変更履歴の管理に使用する changelog スキル
• バージョン更新に使用する svbump（インストール済み）
• バージョン管理操作に使用する jj
• リリースタスクの実行に使用する just
• Claude Code プラグインのバージョン更新に使用する jq

リリースワークフロー

ステップ 1：前回のリリース以降のコミットを確認する

前回のリリース以降に作成されたコミットを特定します。

jj log --ignore-working-copy --git -r 'tags()..@' --no-graph

直近のタグから現在のコミットまでのすべてのコミットが表示されます。

ステップ 2：変更履歴の項目を追加する

上記で特定した各コミットについて、変更履歴に記載する必要があるかを判断します。ユーザーに影響する変更に重点を置いてください。

変更履歴に含めるもの：

• 新機能
• バグ修正
• 破壊的変更
• 重要な改善
• 非推奨化

変更履歴から除外するもの：

• ユーザーへの影響がない内部リファクタリング
• ドキュメントのみの変更
• ビルド／CI 設定の変更
• 重要なものでない雑務的なコミット

変更履歴 CLI を使用して項目を追加します。コミット SHA を指定して --attribute-pr を使用すると、関連する PR を自動的に検索して帰属情報を追加できます。ただし、schpet と schpetbot は除外されます。

changelog add --type <type> "<description>" --attribute-pr <commit-sha> --exclude-users schpet,schpetbot

関連する PR がないコミットや、帰属情報が不要な場合は、--attribute-pr を省略してください。

種類は Keep a Changelog のカテゴリに対応します。

• added - 新機能
• changed - 既存機能の変更
• deprecated - まもなく削除される機能
• removed - 削除された機能
• fixed - バグ修正
• security - セキュリティの改善

ステップ 3：ユーザーと変更履歴を確認する

関連する変更履歴の項目をすべて追加したら、CHANGELOG.md の未リリースセクションをユーザーに表示し、確認を依頼します。

1. CHANGELOG.md ファイルを読み取る
2. [Unreleased] セクションを表示する
3. 次のように尋ねる：「これらの変更履歴の項目を確認してください。リリース前に変更が必要なものはありますか？」
4. 要望された修正を行う

ステップ 4：Semver の更新レベルを決定する

変更履歴に記載された変更の種類に基づいて、適切なセマンティックバージョンの更新レベルを決定し、提案します。

メジャー（X.0.0）：

• 破壊的変更
• 機能の削除
• 重要な API の変更

マイナー（0.X.0）：

• 新機能（追加）
• 非推奨化
• 後方互換性のある機能追加

パッチ（0.0.X）：

• バグ修正
• セキュリティ修正
• 新機能を伴わない軽微な改善

提案をユーザーに提示します。

Based on the changelog entries, I recommend a <MAJOR/MINOR/PATCH> version bump because:
- [reason 1]
- [reason 2]

Current version: <current>
Proposed version: <proposed>

Should I proceed with this version bump?

先に進む前に、ユーザーの確認を待ってください。

ステップ 5：変更履歴のリリースを実行する

ユーザーがバージョン更新レベルを確認したら、適切な semver レベルを指定して変更履歴のリリースコマンドを実行します。

changelog release <major|minor|patch>

これにより CHANGELOG.md が更新され、Unreleased セクションがバージョン付きのリリースに変換されます。

ステップ 6：タグの処理を実行する

変更履歴をリリースした後、タグのレシピを実行します。

just tag

このレシピは、最初の失敗で停止し、リリースの全手順を順番に実行します。

1. 品質チェック（just check）：cargo fmt --all --check、cargo clippy --locked --workspace --all-targets -- -D warnings、cargo test --locked --workspace
2. バージョンの更新： svbump を使って、最新の変更履歴のバージョンを Cargo.toml の workspace.package.version に書き込み、その後 cargo update --workspace で Cargo.lock を更新します
3. スキルのドキュメント（just skill-docs）：CLI のヘルプから skills/linear-cli/SKILL.md とその参照ドキュメントを再生成します
4. プラグインのバージョン（just plugin-version）：.claude-plugin/plugin.json の version と、.claude-plugin/marketplace.json の version および plugins[0].version を設定します
5. コミットとタグ： jj commit -m "chore: Release linear-cli version <version>" を実行し、その後 main ブックマークを移動して、同じコミット（@-）に v<version> タグを設定します
6. プッシュ： jj git push --bookmark main を実行し、その後 git push origin --tags を実行します

完了すると、released v<version> と表示されます。

エラー処理

いずれかの手順が失敗した場合：

• 品質チェックの失敗： 続行する前に問題を修正してください。テストが失敗している、または lint エラーがある場合は、リリースを進めないでください。
• バージョン更新の失敗： バージョンの形式とファイルが存在することを確認してください。
• プッシュの失敗： 認証とリモートへのアクセスを確認してください。

必ず停止し、エラーを明確に報告してください。重要な手順が失敗した場合は、リリース処理を続行しないでください。

重要な注意事項

• justfile の tag レシピが上記のすべての手順を実行するため、手動で実行する必要はありません
• すべてのバージョン管理操作には jj を使用してください（プロジェクトの AGENTS.md に従ってください）
• 読み取り専用の jj 操作では、必ず --ignore-working-copy を使用してください
• このワークフローは親コミット（@-）にコミットを作成し、その後新しい作業コミットを作成します
• jj git push と git push origin --tags の両方が必要です（ブックマークには jj、タグには git を使用します）

リリース後

リリースが成功した後：

1. タグが GitHub に表示されていることを確認します
2. GitHub Actions のリリースワークフロー（.github/workflows/release.yml）がバイナリをビルドし、Homebrew の formula と npm パッケージを公開することを確認します
3. 新しいバージョンが公開されていることを確認します

参考

実装については、justfile の tag および plugin-version レシピを参照してください。