リリースワークフロー

このスキルは、linear-cli プロジェクトの新しいバージョンをリリースするための体系的なワークフローを提供します。チェンジログの管理、バージョンバンプ、テスト、タグ付けを処理します。

使用する時機

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

前提条件

以下のツールが利用可能であることを確認します：

• チェンジログ管理用の changelog スキル
• バージョンバンプ用の svbump（インストール済み）
• バージョン管理操作用の jj
• リリースタスク実行用の just

リリースワークフロー

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

前回のリリース以降に行われたコミットを特定します：

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

これは、最新のタグから現在のコミットまでのすべてのコミットを表示します。

ステップ 2: チェンジログエントリを追加

上で特定された各コミットについて、チェンジログエントリが必要かどうかを評価します。ユーザーに対する変更に焦点を当てます：

チェンジログに含める：

• 新機能
• バグ修正
• 破壊的変更
• 大幅な改善
• 廃止予定機能

チェンジログから除外：

• ユーザーへの影響がない内部リファクタリング
• ドキュメント専用の変更
• ビルド/CI 設定の変更
• chore コミット（重要でない場合）

changelog 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: セマンティック バージョニングバンプを決定

チェンジログの変更タイプに基づいて、適切なセマンティックバージョニングバンプを決定して推奨します：

メジャー (X.0.0):

• 破壊的変更
• 削除された機能
• 重大な API 変更

マイナー (0.X.0):

• 新機能（added）
• 廃止予定機能
• 後方互換性のある機能の追加

パッチ (0.0.X):

• バグ修正
• セキュリティ修正
• 新機能なしの軽微な改善

推奨をユーザーに提示します：

チェンジログエントリに基づいて、以下の理由で <MAJOR/MINOR/PATCH> バージョンバンプを推奨します：
- [理由 1]
- [理由 2]

現在のバージョン: <current>
提案されたバージョン: <proposed>

このバージョンバンプで進めてもよろしいでしょうか？

進める前にユーザーの確認を待ちます。

ステップ 5: チェンジログリリースを実行

ユーザーがバージョンバンプを確認したら、適切なセマンティックレベルでチェンジログリリースコマンドを実行します：

changelog release <major|minor|patch>

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

ステップ 6: タグプロセスを実行

チェンジログがリリースされた後、justfile から完全なタグプロセスを実行します。これには以下が含まれます：

1. 品質チェックを実行：

   deno check src/main.ts
   deno fmt --check
   deno lint
   deno task test
   

2. バージョンファイルを更新：

   # チェンジログから最新バージョンを取得
   LATEST_VERSION=$(changelog version latest)
   
   # バージョンを deno.json に書き込む
   svbump write "$LATEST_VERSION" version deno.json
   
   # deno.json からバージョンを読み込み、dist-workspace.toml に書き込む
   DENO_VERSION=$(svbump read version deno.json)
   svbump write "$DENO_VERSION" package.version dist-workspace.toml
   

3. スキルドキュメントを再生成：

   # 更新されたスキルドキュメントを生成（deno.json からバージョンを含む）
   deno task generate-skill-docs
   
   # Claude Code プラグインバージョンを更新
   FINAL_VERSION=$(svbump read version deno.json)
   svbump write "$FINAL_VERSION" version .claude-plugin/plugin.json
   svbump write "$FINAL_VERSION" version .claude-plugin/marketplace.json
   # marketplace.json には plugins[0] 内にもバージョンがあります — svbump はアレイパスに対応できないため、
   # jq を使用するか手動で編集して一致させてください
   

4. コミットとタグを作成：

   # 最終バージョンを取得
   FINAL_VERSION=$(svbump read version deno.json)
   
   # コミットを作成
   jj commit -m "chore: Release linear-cli version $FINAL_VERSION"
   
   # メインブックマークを親コミットに設定
   jj bookmark set main -r @-
   
   # 親コミットにタグを作成
   jj tag set "v$FINAL_VERSION" -r @-
   

5. リモートにプッシュ：

   # ブックマークをプッシュ
   jj git push --bookmark main
   
   # タグをプッシュ（git を使用）
   git push origin --tags
   

6. 完了を報告：

   v$FINAL_VERSION を正常にリリースしました！
   

エラーハンドリング

いずれかのステップが失敗した場合：

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

常に停止してエラーを明確に報告します。重大なステップが失敗した場合は、リリースプロセスを続けないでください。

重要な注記

• justfile の tag レシピはライン 5-21 から完全なプロセスを処理します
• すべてのバージョン管理操作に jj を使用します（プロジェクト CLAUDE.md に従い）
• 読み取り専用の jj 操作には常に --ignore-working-copy を使用します
• ワークフローは親（@-）にコミットを作成し、その後新しい作業コミットを作成します
• jj git push と git push origin --tags の両方が必要です（ブックマーク用に jj、タグ用に git）

リリース後

リリースが成功した後：

1. タグが GitHub に表示されることを確認
2. GitHub Actions リリースワークフローがトリガーされることを確認（設定されている場合）
3. 新しいバージョンが公開されたことを確認

参考資料

完全なタグレシピの実装については、justfile のライン 5-21 を参照してください。