ship

リリース

このスキルは、作業ツリー内の完成した変更を本番環境へリリースします。変更を小さく分けてコミットし、プッシュし、マージし、チェックの結果を監視して、変更が公開されたことを確認します。

プッシュするなら最後までプッシュ

ユーザーが「プッシュ」「リリース」または「マージ」と言ったら、最後までの手順をすべて実行してください。ユーザーの認証情報や承認が必要な場合を除き、コマンドをユーザーに渡すのは不備です。コミットに含まれたシークレットは常に HIGH です。

変更自体の確認は、このスキルを開始する前に verify で実行します。

1. ツリーを確認する

git status を実行し、変更されたファイルをすべて読みます。このタスクで変更していないファイルがあれば名前を挙げ、コミットする前に確認を求めます。無関係なファイルのコミットは ship-flag-stray-files です。差分をスキャンして、キー、トークン、パスワード、.env ファイルを確認します。シークレットのコミットは ship-no-secrets です。

2. 変更ごとにコミットする

論理的な変更ごとにコミットを1つ作成します。機能、修正、名前変更を1つのコミットにまとめるのは ship-commit-per-change です。各メッセージは Conventional Commit の形式で記述します。形式は type(scope): summary とし、命令形、小文字、ピリオドなしにします。feat、fix、docs、refactor、chore またはその他の標準的なタイプを使い、破壊的変更にはタイプの後に ! を付けます。「Remove the archive.」のようなメッセージは ship-conventional-commits です。リリースを公開するパッケージでは、変更と一緒に changeset を追加します。リリース対象の変更に changeset がない場合は ship-changeset-for-packages です。

3. プッシュ、マージ、整理

ブランチをプッシュします。マージを依頼された場合は、マージしてブランチを削除し、デフォルトブランチに戻ります。マージ後もブランチが残っているのは ship-merge-and-tidy です。バグまたは機能ごとにプルリクエストを1つ作成します。修正を3つまとめたプルリクエストは ship-one-pr-per-bug です。UIを変更するプルリクエストにはスクリーンショットを添付します。これは ship-screenshot-ui-prs です。

4. チェックを監視する

CIを待ち、失敗した項目を修正します。チェックが赤または実行中の状態で「プッシュしました」と報告するのは ship-watch-checks です。

5. 最後まで対応する

変更でイシューを修正した場合は、イシューへのリンクを追加し、クローズして、報告された場所で返信します。修正済みのバグのイシューが未解決のままなのは ship-close-the-loop です。変更がデプロイされたら、本番URLまたは公開済みバージョンを開いて確認します。本番環境を確認せずに「デプロイしました」と報告するのは ship-confirm-live です。

6. ユーザーが行う必要のあることだけを引き継ぐ

自分で実行できる手順はすべて実行します。ログイン、2要素認証コード、または承認だけを求めます。必要なものを具体的に伝えます。ユーザーが実行するコマンドの一覧を渡すのは ship-do-the-steps です。

対比

すべてのチェックは対になっています。問題のある行の隣に、それを置き換える行があります。

ルール	問題のある例	置き換え
ship-flag-stray-files	他の人のファイルがツリーにある状態での git add -A	ファイル名を挙げてから確認する
ship-no-secrets	.env.local をコミットする	.env.local を無視し、シークレットのローテーションが必要だと伝える
ship-commit-per-change	機能、修正、名前変更を1つのコミットにまとめる	変更ごとに1つ、計3つのコミット
ship-conventional-commits	Remove the archive.	chore: remove the archive
ship-changeset-for-packages	changeset のないパッケージ修正	同じコミットに changeset を含める
ship-merge-and-tidy	マージしたが、ブランチをチェックアウトしたまま	マージし、ブランチを削除して main に戻る
ship-one-pr-per-bug	バグ3件に対してプルリクエストを1つ作成する	プルリクエストを3つ作成する
ship-screenshot-ui-prs	画像のないUI変更のプルリクエスト	説明にスクリーンショットを添付する
ship-watch-checks	CIの実行中に「プッシュしました」と報告する	「プッシュしました。すべてのチェックに合格しています」
ship-close-the-loop	修正をマージしたが、イシューは未解決	イシューにリンクし、クローズして返信する
ship-confirm-live	「デプロイしました」	「本番URLで公開されていることを確認しました」
ship-do-the-steps	「準備ができたら npm publish を実行してください」	公開するか、「2要素認証コードが必要です」と伝える

報告

重大度。 HIGH は、コミットされたシークレット、誤ってコミットされたファイル、またはチェックに失敗したリリースです。MEDIUM は、まとめて作成されたコミットまたはプルリクエスト、修正後も未解決の課題、または実行できたはずの手順を差し戻したものです。LOW は、Conventional Commit ではないメッセージ、スクリーンショットの欠落、またはマージ後に残されたブランチです。

形式。 根本原因ごとに1件の指摘を記載し、該当するファイルがない場合は手順を示します。

file:line - [rule-id] what is wrong
step 3 - [rule-id] what is wrong

続いて Rule | Count | Severity の概要を記載します。HIGH が1件でも残っている場合は Block、それ以外は Approve とします。最後まで確認できなかったチェックはすべて Not verified と記載します。