release

brooks-lint — リリース

対象バージョンはユーザーのリクエストから取得します（例：1.4.0）。空の場合は、何も行う前にメンテナーにセマンティックバージョンの更新内容を確認してください。

そのバージョンを受け入れる前に、バックログを確認してください。 npm run changelog:audit を実行し、実際に未リリースの変更を確認します。バージョンの更新内容は、リリースのきっかけとなった変更ではなく、全範囲に基づいて決定します。範囲内に機能追加や新しいプラットフォームが含まれているのにメンテナーがパッチリリースを求めた場合は、作業を中断してその旨を伝えてください。未リリースの20件のコミット（新しいプラットフォームを含む）をパッチリリースにまとめてしまったため、v1.5.1を公開後に削除し、v1.6.0として再リリースしたことがあります。

以下の手順を順番に実行してください。bump-version.mjs は package.json からバージョンを読み取り、変更履歴には手を加えません。そのため、バージョンの編集とCHANGELOGの項目追加は手動で行います。このスクリプトは、マニフェストとバージョンを含むすべてのテキストファイルにバージョンを反映するだけです。

1. 信頼できる唯一の情報源を設定します。 npm version <version> --no-git-tag-version を実行します（--no-git-tag-version フラグは必須です。通常の npm version は独自のコミットとタグを作成し、手順5で行う手動コミットと衝突します）。

2. バージョンを反映します。 npm run bump を実行します。バージョンは .claude-plugin/plugin.json、.claude-plugin/marketplace.json、.codex-plugin/plugin.json、gemini-extension.json と、scripts/version-refs.mjs によって検出されるバージョンを含むすべてのテキストファイルに書き込まれます（READMEの6つすべてのバッジとアクションの uses: ピン、ドキュメントのランディングページにあるJSON-LDの softwareVersion、および docs/github-action-example.yml）。ここに一覧を記載して管理しないでください。正式な一覧はスクリプト内のものです。

3. 変更履歴を記述します。 CHANGELOG.md の先頭に、最後のリリースタグ以降のコミットを要約したカテゴリ別の注記（Added / Fixed / Changed）を含む新しいセクションを追加します。見出しは必ず ## [<version>] - YYYY-MM-DD にしてください。npm run validate はこの正確な形式を解析するため、## <version> のような日付のない形式では失敗します。 3a. 全範囲を監査します。抜き取りではなく、すべてのコミットを確認してください。 次を実行します。

   npm run changelog:audit
   

   最後のリリースタグから範囲を特定し、3つの例外のみを適用して（リリースバンプ、ブランチ上のコミットが個別に一覧表示されているマージコミット、star-historyの更新――チャート専用の2ファイルのみを変更するボットのコミット）、残りをチェックリストとして出力します。 全項目を確認してください。各行には、今記述した項目を対応させるか、項目が不要な理由を示します。 それ以外に例外はありません。 ユーザーに見える変更のない内部的な強化にも項目が必要です。また、外部のコントリビューターによるメンテナー向けの修正にも項目が必要で、その場合は @handle のクレジットも記載します。コミットの Changelog: トレーラーはフラグとして表示されます。そのコミットの項目は、今記述しているものです。

   スクリプトは、範囲内のプルリクエストの #N がセクションに一度も記載されていないことを検出できる場合、ゼロ以外の値で終了します。この同じチェックはリリース作業中に npm run validate 内でも実行されるため、省略できません。また、validateは停止するたびに1行出力します。チェックリストのそれ以外の項目は判断に委ねられ、強制されません。監査が成功しても、変更履歴が完全であるとは限りません。セクション内のどこかに単独の #N があればゲートを通過し、リベースマージされたPRは照合対象を残さず、リリースバンプ自体にステージされた変更は監査されません。AGENTS.mdのRelease Processを参照してください。

4. 検証します。 npm run validate を実行します。マニフェスト、バージョンを含むテキストファイル、または CHANGELOG の項目に不整合がある場合は失敗します。修正して、問題がなくなるまで再実行します。その後、npm test を実行します。

5. コミットしてプッシュします。 npm run bump によって書き換えられたファイルと CHANGELOG.md をすべてステージングします。バージョンを含むファイルの対象はディスクから検出され、README は1つではないため、ファイル名を指定せず git status を確認します。chore(release): bump version to <version> のような規約に従ったメッセージでコミットし、main にプッシュします（main に直接プッシュするリポジトリのため、PR はありません）。 5a. リリースに関わる各所を同期し、承認を確認します。 6つすべての README 翻訳、CHANGELOG、プラグインのマニフェスト、ウェブサイト、インストールガイドがリリースの状態と一致していることを確認します。npm run github:metadata -- --apply を実行し、続けて --check を実行して、About、ホームページ、トピック、管理対象ラベルを同期します。無関係なラベルは保持します。明示的な公開保留に従ってください。準備が完了していて CI が成功していても、承認されたことにはなりません。npm から取り下げられたバージョンは、GitHub のタグを削除していても再利用できません。 5b. 対象のリリースコミットに対するリモート CI の完了を待ちます。 プッシュ後、git rev-parse HEAD でコミットを特定し、そのコミットと headSha が一致する Validate ワークフローの実行を探して、gh run watch <run-id> --exit-status で完了を待ちます。すべてのマトリックスジョブを確認します。実行が存在しない、キューに入っている、キャンセルされた、または失敗した場合は成功ではありません。ローカルのチェックではこのゲートを代替できません。この対象コミットの実行が正常に完了するまで、GitHub リリースを作成したり npm に公開したりしないでください。CI が失敗した場合は原因を調査して修正をコミットし、その新しいコミットの CI が完了するまで待ちます。

6. タグを付けて公開します。 リモートゲートの通過後に限り、GitHub リリースを作成します。 gh release create v<version> --title "v<version>" --notes "<changelog section>"

完了したら、リリースしたバージョンと GitHub リリースの URL を報告してください。