ship-this

これをリリースする

UI の変更をリリースする前の最終レビューです。コードがコンパイルされ、リンターを通過していることを前提としているため、リンターが強制する機械的なスタイルチェックは省きますが、ロジック、正確性、セキュリティは引き続きレビューします。このスキルでは、差分を確認してリンターでは検出できないデザイン品質の低下をチェックし、その差分をもとに簡潔なコミットメッセージと PR の説明を作成します。

基本方針

変更されたコードと、変更を検証するために必要な最小限の周辺コンテキストをレビューします。コードベース内の無関係な部分は監査しません。リンターでは検出できない、アクセシビリティ、モーション、レスポンシブ対応、ビジュアルや UX の逸脱といったリグレッションを検出します。その後、開発者自身が書いたようなコミットメッセージと PR の説明を作成し、ツールによる作成だとは記載しません。

報告する結果はすべて、実行したコマンドまたは読んだソースに基づいている必要があります。スキャナーを実行せずにシークレットスキャンに合格したと主張してはいけません。git が確認していないコミットやプッシュを報告してはいけません。レビューを長くするために、所見を捏造してはいけません。検証が一部しかできない場合は、問題がないと受け取られるような表現を避け、その旨を伝えてください。

重大度

レベル	意味
ブロッキング	実際のバグ、漏えいしたシークレット、またはリリースされるアクセシビリティ上の不具合です。マージしてはいけません。
注記	確認する価値がある、リグレッションの可能性や品質上の不足です。必ずしも誤りとは限りません。

問題のない差分は、所見が空のリストであれば合格です。リストを長くするために軽微な所見を捏造してはいけません。フォーマットや命名に関する好みは対象外です。

チェックリスト

1. 差分を収集する

信頼できる結果を得られるよう、保留中の変更をすべて収集します。最初に一度だけ Git の状態、現在のブランチ、そのアップストリーム、デフォルトブランチ、git status --short を確認し、後続の手順では再度シェルコマンドを実行せず、その結果を再利用します。依頼に合った範囲を選択してください。

• コミット予定の未コミット作業。追跡対象ファイルのステージ済みおよび未ステージの編集を取得するため、git diff HEAD を実行します。
• PR に向けたブランチ全体。コミット済みの作業に対して git diff <base>...HEAD を実行し、その後、未コミットの作業があれば git diff HEAD を追加します。

git diff には未追跡ファイルが含まれないため、git status --short でそれらを検出し、新しい UI ファイルをそれぞれ直接確認します。<base> には、PR のマージ先となるブランチを指定します。通常は git symbolic-ref --short refs/remotes/origin/HEAD で得られるデフォルトブランチです。取得できない場合は origin/main または origin/master を使い、リモートがない場合に限りローカルの main または master を使います。ブランチ自身のアップストリームは使わないでください。これはリモート上の同じブランチを追跡しているため、変更の大部分が差分から除外されてしまいます。ベースブランチを確実に特定できない場合は、続行する前に確認してください。

2. UI の差分をレビューする

以下の各項目に照らして差分を確認してください。これはコードの静的レビューです。レンダリングされたページの確認、キーボード操作による確認、または視差効果を減らす設定での実行が必要な項目は未検証として扱い、「Testing」で保留中と記録してください。

• アクセシビリティ — 新しいインタラクティブ要素にキーボードハンドラーまたはネイティブのセマンティクスがあり、フォーカスのスタイルが設定されていて削除されておらず、フォーカス順序が論理的で、キーボードトラップがなく、ロールと名前が適切です。
• モーション — 新しいアニメーションすべてに適切な prefers-reduced-motion の代替手段があり、パフォーマンスに優れたアニメーションプロパティを使用し、明確な理由に基づいて適切な頻度でアニメーションします。
• レスポンシブ対応 — 固定幅によって小さなビューポートでオーバーフローせず、ブレークポイントとコンテナークエリのロジックがあり、タッチターゲットのサイズとセーフエリアの処理が適切です。
• ビジュアルおよび UX の乖離 — ハードコードされた色、スペーシング、書体の代わりにデザイントークンを使用しています。変更は周囲のシステムに適合しています。トークンがある箇所でマジックナンバーを使っていません。
• ユーザー向け文言 — 新しいラベル、エラー、空の状態、ツールチップの表現は適切です。詳細については、docs-style-guide と writing-checklist のスキルを参照してください。
• 正確性とセキュリティ — 1 つずれたエラー、null と undefined の処理、競合状態、インジェクションのリスクを確認します。
• シークレットと認証情報 — 差分にトークン、キー、パスワード、認証情報が追加されていません。以下のスキャンを参照してください。
• クリーンさ — コメントアウトされたコードブロックが残っていません。console.log と debugger はそれらを管理するリンターに任せてください。

アクセシビリティ、モーション、レスポンシブ対応の詳細なルールについては、このパッケージの keyboard-accessibility、motion-design、responsive-design の各スキルを参照してください。

シークレットと認証情報のスキャン

差分に認証情報が含まれている場合はブロッキングです。マージせず、ユーザーに認証情報のローテーションを伝えてください。コミットされたシークレットは削除後も漏えいした状態だからです。

• 目視確認より、実際のスキャナーを優先してください。gitleaks、trufflehog、git secrets、detect-secrets のいずれかを利用できる場合は、差分に対して実行し、その出力を信頼できる判定結果として扱ってください。独自のパターンを作成せず、ツール自体のルールセットから正確な照合パターンを使用してください。
• スキャナーを利用できない場合は、文書化されたパターンチェックに切り替え、差分で削除されるシークレットを誤検出しないよう、追加された行だけをスキャンしてください。検証済みの GitHub トークンのプレフィックスは、具体的な手がかりになります。ghp_ は従来型トークン、github_pat_ はきめ細かなアクセス許可のトークン、gho_ は OAuth トークン、ghu_ はユーザーからサーバーへのトークン、ghs_ はインストールトークン、ghr_ はリフレッシュトークンです。また、-----BEGIN PRIVATE KEY----- のような秘密鍵の PEM ヘッダーや、password、secret、token、api_key などの名前に割り当てられたエントロピーの高い値も確認してください。
• チェックの網羅性を正直に伝えてください。代替のチェックだけを実行した場合は、問題がないと断定せず、ヒューリスティックなスキャンとして報告してください。

3. コミットメッセージを書く

リポジトリで既に使われている規約に合わせます。Conventional Commits だと決めつけないでください。まず git log <base> -20 --pretty=format:"%s%n%b---" を確認し、規約を分類します。

• Conventional Commits（type(scope): summary）の場合は、それに従い、リポジトリで既に使われているタイプだけを使用します。一度も使われていないタイプを新たに作らないでください。
• チケット番号が先頭に付く形式（PROJ-123: summary または [PROJ-123] summary）の場合は、そのプレフィックスを使います。他の場所で明らかでない場合は、ブランチ名からチケット ID を探します。
• 動詞で始まる通常の形式（Add x、Fix y）の場合は、そのスタイルで書きます。リポジトリで使われていないタイプやスコープの体系を持ち込まないでください。
• ログが空か、規約を分類するには形式が混在しすぎている場合は、Conventional Commits を既定として使用します。

スタイルにかかわらず、以下を適用してください。

• 件名は72文字以内で、命令形（「added」ではなく「add」）にします。
• 件名だけでは変更内容を伝えきれない場合に限り、本文を付けます。
• スコープまたはプレフィックスは、変更されたパスから明らかな場合、またはリポジトリの規約で求められる場合にのみ付けます。差分が無関係な領域にまたがる場合は省略します。
• ツールのクレジットを記載しないでください。「written with an AI」や Generated-by: トレーラー、ツールの共同作成者行を追加しないでください。コミットメッセージは、ツールが忘れられた後も人々が読む永続的な記録です。

4. PR の説明文を作成する

最新のコミットだけでなく、ブランチ全体を要約します。

リポジトリの対応する場所にプルリクエストテンプレートがある場合は、以下の構成ではなく、そのテンプレートに記入します。テンプレートが複数あり、指定もない場合は、リポジトリの既定のテンプレート、または最も適切なものを使用します。それ以外の場合は、以下の既定の構成を使用します。

• ## Summary — 変更内容とその理由を2〜4文で説明します。
• ## Changes — 最終的な効果を具体的に説明する箇条書きを記載します。
• ## UI notes — 新しい状態、モーション、レスポンシブ動作など、レビュー担当者が確認すべき視覚的または操作上の変更を記載します。スクリーンショットや録画が役立つ箇所も示します。
• ## Testing — ビューポート、入力方法、モーション低減設定で変更をどう検証したか、または検証すべきかを記載します。証拠で裏付けられる確認事項だけを報告し、未実施の項目は合格したかのように示さず、保留として記載します。
• ## Notes — 破壊的変更、今後の対応、または意図的な未実装がある場合に限り記載します。

構成にかかわらず、以下を適用してください。

• 個々のコミットを列挙しないでください。 レビュー担当者はコミットタブで確認できます。コミットごとの履歴ではなく、ブランチ全体の最終的な効果を説明します。
• 根拠のないテスト実施の主張（「テストスイートを実行した」など）をしないでください。それは CI で確認できます。Testing には、レビュー担当者が他では確認できない手動検証のみを記載します。
• ツールのクレジットを記載しないでください。 コミットメッセージと同様です。

以前の PR の説明文を更新する場合は、コミットごとに行を追加するのではなく、ブランチ全体を一貫したものとして説明できるよう書き直します。実際の差分に基づいて記載し、コードから確認できない意図を推測しないでください。

5. コミットとプッシュを提案する

メッセージを書いた後、現在のブランチでの操作を提案します。ステップ 1 で確認したブランチ、上流ブランチ、デフォルトブランチの状態を再利用し、決して推測しないでください。

その状態に合った選択肢だけを提示します。

• すでにステージされた変更をメッセージとともにコミットする。
• 追跡対象の変更をすべてステージしてからコミットする。
• コミットしてから、既存の上流ブランチにプッシュする。
• 上流ブランチがない場合は、git push -u origin <branch> でコミットしてからプッシュし、上流ブランチを設定する。
• 前回のコミットがまだプッシュされていない場合に限り、直前のコミットを修正する。
• 何もせず、ユーザーが手動でコミットする。

以下の安全ルールを適用してください。

• コミットは取り消し可能なので、ユーザーが選択したら実行します。
• プッシュは共有され、取り消しが困難な操作なので、実行前に明示的な確認を求めてください。また、決して強制プッシュしないでください。
• 対象がリポジトリのデフォルトブランチの場合、直接プッシュは意図しないことが多いため、警告してから再確認を求めてください。
• 実際の git コマンドを実行し、実際の終了結果を報告してください。コマンドが出力していない成功メッセージを表示してはいけません。

文体

作成するコミット本文と PR の説明はすべて平易な文章で書き、生成する文の句読点には読点と句点のみを使ってください。ダッシュ、コロン、セミコロンは使わないでください。コロンやセミコロンが必要な文は分割し、ダッシュで挿入する補足は読点に置き換えるか、新しい文にしてください。このルールは、作成するコミット本文と PR の文章に適用されます。コミットの件名や、ツールまたは慣例で必要とされる構造的な構文には適用されないため、件名、type(scope): のコミット接頭辞、PROJ-123: のチケット接頭辞、Markdown の見出し、コードスパン内の内容はそのままにしてください。

文章が最初から最後まで自然につながるようにしてください。コミット本文や PR の説明の各段落は、途中で改行せず一続きの行にしてください。段落の間には空行を 1 行だけ入れてください。件名の長さ制限は 1 行の上限であり、折り返しではないため、引き続き適用されます。また、PR の見出し下の Markdown 箇条書きなど、構造上の構文で改行が必要な場合はそのままにしてください。

出力

次の 3 つのセクションを、この順序で、指定された見出しのとおりに返してください。## Review、次に ## Commit message、最後に ## PR description です。## Review の下には、各指摘を 重大度, パス:行, 指摘内容 の形式で 1 つずつ箇条書きにするか、差分に問題がなければ 問題は見つかりませんでした。 と記載してください。コミットメッセージは専用の text コードブロックに、PR の説明は専用のコードブロックに記載してください。その後、ステップ 5 のコミットとプッシュの提案を行ってください。

---

@planetabhi 作成