release

fromargs をリリースする

これは skillz-that-grillz のリポジトリ内にあるスキルです。.agents/skills/release/ に配置され、Claude Code 用に .claude/skills/ からシンボリックリンクされています。metadata.internal: true により、npx skills add から非表示になります。公開用の skills/ ツリーには移動しないでください。

タグをプッシュすると、1 回の承認後に PyPI へ公開されます。PyPI では同じバージョンを二度登録できません。タグのプッシュと承認は取り消せないものとして扱ってください。

リリースの条件

• リリースノートの唯一の情報源は packages/fromargs/CHANGELOG.md です。just fromargs-release-notes は 1 つのセクションを出力し、そのセクションが存在しないか空の場合は失敗します。
• .github/workflows/publish-fromargs.yml は fromargs-v* タグで実行されます。ビルドジョブでは、タグのコミットが main に含まれていることと、タグのバージョンが packages/fromargs/pyproject.toml と一致することが必須です。
• publish ジョブは pypi 環境での承認を待ってから、信頼済み公開を使用してアップロードします。
• github-release ジョブは --latest=false を指定して GitHub リリースを作成します。ビルド後にタグが移動していた場合は失敗します。
• wedge のバンドルと cheese-cave のサンプルロックファイルには fromargs のソースが埋め込まれているため、バージョン変更時には再ビルドが必要です。

1. 事前確認

1. main に切り替え、--ff-only でプルし、ワーキングツリーがクリーンであることを確認します。
2. packages/fromargs/CHANGELOG.md の ## [Unreleased] セクションを読みます。空の場合は中止します。
3. バージョンを決めます。ユーザーが指定した場合は、その値を使用します。それ以外の場合、Breaking の項目がある 0.x リリースでは次のマイナーバージョンを、その他の変更では次のパッチバージョンを提案します。提案したバージョンをユーザーに確認します。
4. origin に fromargs-v タグが存在する場合、または https://pypi.org/pypi/fromargs//json が 200 を返す場合は中止します。

2. リリース PR の準備

1. chore/fromargs-release- ブランチを作成します。

2. packages/fromargs/CHANGELOG.md で、Unreleased の項目を今日の日付の ## [] - の下に移動します。空の ## [Unreleased] 見出しは残します。

3. CHANGELOG の末尾にあるリンク参照を更新します。[Unreleased] は fromargs-v...HEAD を比較するようにします。[] を追加し、前のタグと fromargs-v を比較するようにします。

4. packages/fromargs/pyproject.toml の version = "" を設定します。

5. マイナーバージョンが変わる場合は、pyproject.toml と packages/wedge/pyproject.toml の fromargs の範囲を >=..0,<. に設定します。

6. ワークフローの setup-uv ステップで固定されている uv のバージョンを使用して、ワークスペースのロックファイルを再生成します。これにより、ロックファイルの revision が CI と互換性を保ちます。

   uvx uv@<ci-uv-version> lock
   

7. fromargs を埋め込んでいる成果物を再ビルドします。

   uv run --locked --project packages/wedge wedge lock --root packages/wedge/examples/skills
   uv run --locked --project packages/wedge wedge bundle skills/skillz
   

8. just fromargs-release-notes を実行し、出力を読みます。新しいセクション全体が表示されている必要があります。

9. uv build --package fromargs --no-sources --out-dir と uvx twine check /* を実行します。

10. just build を実行します。新たな失敗があれば中止します。失敗をベースラインの失敗と判断する前に、クリーンな main のチェックアウトで同じ失敗が起きるか比較します。

11. 指定されたファイルを chore(fromargs): release としてコミットします。ブランチをプッシュし、main に対する PR を作成します。PR 本文にリリースノートとマージ後の手順を記載します。

3. マージ

1. PR のすべてのチェックが通るまで待ちます。すべてのレビューコメントに対応するか、回答します。
2. このセッション中にリリース全体を行うようユーザーから依頼されていない限り、マージについてユーザーの明示的な承認を得ます。
3. gh pr merge --squash --match-head-commit でスカッシュマージします。マージコミットの SHA を記録します。
4. マージ日が CHANGELOG の日付と異なる場合は、タグを付ける前に新しい PR で日付を修正します。

4. タグ付けと承認

1. main をフェッチします。マージコミットが origin/main に含まれており、新しいバージョンと CHANGELOG セクションがあることを確認します。

2. マージコミットに注釈付きタグを作成してプッシュします。

   git tag -a fromargs-v<version> <merge-sha> -m "Release fromargs <version>"
   git push origin fromargs-v<version>
   

3. タグに対応する publish fromargs の実行を見つけます。ビルドジョブが成功し、実行が pypi 環境での承認待ちになるまで待ちます。

4. このセッション中にリリース全体を行うようユーザーから依頼されていない限り、ユーザーの承認を得てからデプロイを承認します。

   gh api repos/<owner>/<repo>/actions/runs/<run-id>/pending_deployments \
     -X POST -F "environment_ids[]=<pypi-env-id>" -f state=approved \
     -f comment="Approve fromargs <version>"
   

5. 検証

1. 実行が完了するまで監視します。すべてのジョブが成功する必要があります。
2. https://pypi.org/pypi/fromargs/<version>/json を読み込みます。バージョン、依存関係の範囲、wheel と sdist がそれぞれ 1 つあることを確認します。
3. gh release view fromargs-v<version> を読み込みます。ドラフトではないこと、本文が CHANGELOG セクションから始まっていること、両方の配布ファイルが添付されていることを確認します。
4. リポジトリの最新リリースに変更がないことを確認します。

失敗時のルール

• 公開済みのタグを移動、削除、再プッシュしてはいけません。新たな修正には新しいパッチバージョンが必要です。
• ビルドジョブが失敗した場合、アップロードは行われていません。main で原因を修正し、ユーザーの承認を得た場合に限り未公開のタグを削除して、再度タグを付けます。
• PyPI にバージョンが存在するものの github-release ジョブが失敗した場合は、gh run rerun <run-id> --failed を使って失敗したジョブのみを再実行します。
• タグがレビュー済みのマージコミットを指していない実行について、デプロイを承認してはいけません。

報告

PR、マージコミット、タグ、ワークフローの実行、PyPI の URL、GitHub リリースの URL を報告します。実行されなかったチェックはすべて明記します。