Check: リリース前のレビュー

最初の行の前に 🥷 をインライン付与してください。段落として単独では配置しないでください。

注：/review は Anthropic の組み込みプラグインコマンドで PR レビュー用です。Waza では /check（またはエイリアス code-review）を使用します。このスキル内から /review を再度実行しないでください。

差分を読み、問題を見つけ、安全に修正できることを修正し、その他については相談してください。完了とは検証がこのセッション内で実行され、合格したことを意味します。

プラン実行モード

ユーザーのメッセージが「Implement the following plan」「按计划实施」「按照计划」「整」「可以干」「直接改」で始まる場合、またはプラン本体が続く場合、あるいは /think 出力へのリンクがある場合に有効にします。

このモードではコードレビューを実行しません。代わりに以下を実行します：

1. 実行されるプランを表示します（最初の見出しまたはサマリー行）。
2. 明らかなリポジトリドリフトをチェックします：git status を実行し、プランと矛盾する変更されたファイルを確認します。ドリフトがプランを安全でなくする場合は、具体的な矛盾を名指しして停止します。
3. 各プラン項目を to-do として処理します。進行に従い各項目を完了としてマークします。
4. すべての項目が完了したら、プロジェクトの検証コマンドを実行します。
5. プロジェクトコンテキストまたは現在のスレッドがレビュー後のシップを示す場合は、自動的に Ship モードに移行します。

デフォルト継続（review-then-ship）

プロジェクトの AGENTS.md または現在のスレッドが明示的に「commit after review」「ship if green」またはそれに相当する内容を要求する場合、クリーンなレビュー後に直接 Ship フローに移行します。再度確認しません。行動前に「proceeding to ship」を表示します。

プロジェクトコンテキスト抽出

これは Waza のパブリック、スタンドアロンなコードレビュー機能です。非公開のマシンパスまたは公開されていないプロジェクト指示に依存してはいけません。

レビュー前に、リポジトリコンテキストからプロジェクト制約を抽出します：

1. 差分を読み、変更された言語、フレームワーク、マニフェスト、生成されたアウトプット、リリースファイル、CI ワークフローを特定します。
2. 必要に応じてのみパブリックプロジェクトファイルを検査します：README、AGENTS/CLAUDE 指示（存在する場合）、パッケージマニフェスト、ロックファイル、ビルド設定、テスト設定、ワークフローファイル、リリースノート。
3. 検出結果をレビューコンテキストに圧縮します：検証コマンド、保護または生成されたファイル、リリースアーティファクト、ドメインリスク、パブリック返信ルール。
4. プロジェクトコンテキストとこのスキルが重複する場合は、より厳密なルールを適用します。
5. プロジェクトドキュメントまたは CI が検証コマンドを指定している場合は、自動検出よりそれを優先します。

コンテキスト形状については references/project-context.md を参照してください。

リリースまたはメンテナ作業の場合、references/project-context.md から Release Gate 2.0 マトリックスも入力します。レビューベース、ダーティ/ステージド/未追跡状態、最新タグ、オリジン同期、バージョンフィールド、生成されたアーティファクト、パッケージ/アーカイブコンテンツ、リリースアセット、レジストリ/appcast/CI、およびパブリック issue/PR 状態をカバーしています。マトリックス証拠が欠落している場合は「リリース準備完了」の主張のブロッカーです。

耐久的コンテキストプリフライト

ユーザーがメモリ、プレビュー、以前の決定、または以前の結論に言及する場合、メモリパスを提供する場合、または現在のプロジェクトが明らかなローカルメモリサマリーを公開する場合にのみこれを実行します。マシン固有のメモリルートをハードコードしたり、生のトランスクリプトを読んだりしないでください。

耐久的コンテキストをこの順序で読みます：ユーザー提供パス、現在のプロジェクトスコープ、グローバル設定。最初にタイトルを列挙し、最大 1-2 個の関連サマリーを開きます。クロスプロジェクトエントリは転送可能なパターンのみとして扱います。

使用前にメモリタイプをマップします：decision、preference、および principle はプライベートなタスク制約です；pattern と learning はレビューチェックリストです；fact は現在の状態に対して検証してからレビューに影響させる必要があります。現在のコード、差分、パブリックドキュメント、CI、テスト、およびリモート状態がメモリをオーバーライドします。

/check の場合、耐久的メモリはユーザーインテントと優先フォローアップを説明できますが、パブリックプロジェクトルールは依然として README ファイル、マニフェスト、CI ワークフロー、リリースドキュメント、差分、および現在のスレッドの明示的な指示から来ます。プライベートメモリをパブリックプロジェクト要件として引用しないでください。

差分を取得

現在のブランチとベースブランチ間の完全な差分を取得します。不明な場合は尋ねます。既にベースブランチにある場合は、どのコミットをレビューするかを尋ねます。

トリアージモード

ユーザーが以下に言及する場合にアクティブにします：issue、PR、「すべてをレビュー」、triage、「batch」、または「批量处理」。差分フローをスキップして、代わりにこれを実行します。

アクション優先ルール： 明確な処理方法を持つアイテム（既に修正済み、重複、既にリリース済み）は分析段落なしで即座に処理されます。スクリーンショットまたは画像を分析する場合は、見たものと推奨アクションを 1 つのメッセージで述べます。処理方法が真に曖昧な場合のみユーザーに尋ねます。

フロー： gh issue list -R <repo> --state open --limit 20 と gh pr list -R <repo> --state open でオープンアイテムをプル取得します。各アイテムについて、修正が既にシップされているかを確認します：git log --oneline <latest-tag>..HEAD | grep -i "<keyword>"。シップ済みの場合：メモ付きで閉じます。マージされたがリリース未提供の場合：「已修复，等下一个版本 release」と返信して閉じます。修正がない場合：分析して行動します。可能であれば今すぐ修正します（fix: closes #N コミット）；Mole の夜間修正アイテムの場合は @<user>, this is already fixed in the latest nightly. Upgrade: mo update --nightly と返信して閉じます；有効だがリリース未提供のアイテムの場合は認識して開いたままにします；無効なアイテムの場合は 1-2 文の理由を示して閉じます。

ライブキューでの最終結論前に、issue/PR リストをもう一度リフレッシュし、実行中に変更されたアイテムを再読します。証拠が不完全な場合は、推測で閉じるのではなくアイテムを保留にします。

PR 処理： PR の方向が受け入れられているが、パッチが変更を必要とする場合は、メンテナの修正をコントリビューターの PR ブランチにプッシュしてから PR をマージすることを優先します。最初に maintainerCanModify を確認します。ブランチ編集が許可されていない場合は、コントリビューターにメンテナ編集を有効にするか必要な改版をプッシュするよう依頼します；タイミングやリリース安全性が必要とする場合のみ別のメンテナコミットにフォールバックし、PR で述べます。方向が拒否された場合、安全でない場合、不要な場合、または明示的にプロジェクトのスコープに含まれていない場合にのみマージなしで閉じます。受け入れられた PR をサイレントに main に吸収して閉じないでください。

パブリック返信形状（メンテナ、issue または PR）：

1. gh issue view / gh pr view --json author から @<login> を解決します。
2. 言語： オープナーが中国語または英語を使用した場合、オープナーの言語に合わせます。オープナーが日本語または韓国語を使用した場合、プロジェクトドキュメントが上書きしない限りメンテナ返信には英語を使用します。
3. @<login> で開き、最大 1 つの短い謝意（感谢反馈、thank you for the report など）を含めます。閉じる謝意スタック（再次感谢、Thanks again、長い丁寧な終了）を追加しないでください。
4. 1-2 短い段落：事実上の理由、シップされたもの、またはブロックされているもの、儀式なし。
5. 常にリリースまたは検証に結びついた次のステップを提供します：次の App Store または GitHub リリース、夜間アップグレードコマンド、一度クリアするキャッシュパス、または正確に必要な情報。
6. 表現を更新する場合、既存のメンテナコメント（PATCH /repos/{owner}/{repo}/issues/comments/{comment_id}）を編集することを優先します；古いテキストが履歴から消えなければならない場合を除き、削除と再投稿を避けます。

リポジトリの AGENTS.md または CLAUDE.md が矛盾しない限り、この形状をデフォルトにします。

署名行（標準署名に追加）：

triage:           N reviewed, N closed, N deferred

リリース価値分析

ユーザーが「深入分析 X 是不是值得发新版本」「is this worth a new release」「值不值得发版」または類似の質問をしたときにアクティブにします。

1. git log <last-tag>..HEAD --oneline を実行します（git tag --sort=-version:refname | head -1 で最後のタグを見つけます）。
2. コミットをカウントして分類します：feat（新機能）、fix（バグ修正）、chore/docs/refactor（内部）。
3. 出力：
   • コミットサマリー：最後のリリース以降 N feat、N fix、N chore
   • 判定：release / skip（1 行）
   • 推奨バージョンバンプ：patch（修正のみ）、minor（feat 存在）、major（破壊的変更）
   • キーリスク：このバッチの最大リスクについて 1 文
4. 判定が「release」の場合は、Ship モードへの移行を提供します。

Ship / リリースフォローアップ

ユーザーが変更がリディに準備できた後、コミット、タグ、リリース、パブリッシュ、プッシュ、issue/PR への返信、または issue を閉じるよう依頼する場合にアクティブにします。

このモードはレビューを拡張します；レビューをスキップしません。パブリックまたは不可逆的なアクション前に：

1. パブリックプロジェクトコンテキストからリリースルールを抽出します：README、マニフェスト、CI ワークフロー、リリースノート、パッケージスクリプト、チェンジログ、および現在のスレッドの明示的なユーザー指示。
2. references/project-context.md から Release Gate 2.0 マトリックスを入力します：レビューベース、ダーティ/ステージド/未追跡状態、最新タグ、オリジン同期、バージョンフィールド、生成されたアーティファクト、パッケージ/アーカイブコンテンツ、リリースアセット、レジストリ/appcast/CI、およびパブリック issue/PR 状態。
3. 生成または バンドルされたアウトプット、バージョンフィールド、リリースノート、パッケージコンテンツ、および必要なアーティファクトが同期していることを検証します。エコシステムが提供する場合はドライラン コマンドを優先します。
4. 意図したファイルのみをコミットします。関連のないダーティ作業を保持し、git 操作をシリアル化して、インデックスロックまたはオーバーラップ追加がワークフローを破損しないようにします。
5. ユーザーが明示的にアクションを承認した場合のみプッシュ、パブリッシュ、タグ、またはリリースを作成します。auth、OTP、CI、レジストリ、またはネットワーク状態が操作をブロックする場合は、一時停止して正確なブロッカーをレポートします。
6. issue/PR フォローアップについては、行動前に gh issue view または gh pr view でアイテムアイデンティティを確認します。トリアージモードのパブリック返信形状を使用します（言及、単一の謝意、事実、明示的な次のリリースまたは検証ステップ）。修正がシップされた場合、既に利用可能な場合、無効な場合、重複の場合、またはメンテナが明示的に閉じるよう依頼した場合のみ閉じます。
7. GitHub リリース反応フォローアップについては、プロジェクトコンテキストまたは現在のスレッドがそれを要求する場合のみそれを実行します。リリースが存在し、必要なアセットが検証された後、タグからリリース ID を解決し、gh api を使用して repos/<owner>/<repo>/releases/<id>/reactions にすべてのポジティブなリリース反応を POST し、反応を再読します。ポジティブなリリース反応は +1、laugh、heart、hooray、rocket、および eyes です。
8. ネットワークまたは API の失敗後、成功または失敗を想定する代わりに最終状態を再読します。

具体的なシップ状態で終了します：コミットハッシュ、タグ、リリース URL、レジストリ/バージョン結果、プッシュされたブランチ、リリースアセット状態、リリース反応状態、issue/PR 状態、および残っているブロッカー。適用しないフィールドは省略します。

スコープ

差分を測定し、深さを分類します：

深さ	基準	レビュアー
Quick	100 行未満、1-5 ファイル	ベースレビューのみ
Standard	100-500 行、または 6-10 ファイル	ベース + 条件付きスペシャリスト
Deep	500+ 行、10+ ファイル、または auth/payments/データミューテーションに触れる	ベース + すべてのスペシャリスト + 対抗的パス

進行前に深さを述べます。

要求されたものを構築しましたか？

コードを読む前に、スコープドリフトをチェックします：差分と述べられた目標は一致していますか？ラベル：on target / drift / incomplete。

ドリフト信号（例、網羅的ではなく -- 任意の 1 つで十分：

• 変更されたファイルは述べられた目標と関連がない
• 差分に純粋なリファクタリング（リネーム、フォーマット、リストラクチャリング）が含まれている一方で、目標はバグ修正または機能だった
• 新しい依存関係が現れており、目標はそれを述べなかった
• 目標に関連のないコードが削除またはコメントアウトされた
• 新しい抽象化またはヘルパーが導入されており、目標に必要ではない

ハード停止（マージ前に修正）

例、網羅的ではなく -- マージされずにレビューされた場合に不可逆的な害を引き起こす可能性がある任意の差分にフラグを立てます。

• 未検証の主張なし。 「I verified X」「I ran Y」「tests pass」または「this fixes Z」と書かないでください。このターンのトランスクリプトにシェル出力がない限り。コードを読まずに動作について推論する場合は、「I verified」の代わりに「based on reading the code」と言います。署名の各検証主張は、このセッションで実際に実行されたコマンドを指さす必要があります。
• 破壊的な自動実行：「安全」または「自動実行」としてマークされたタスクで、ユーザー表示状態（履歴ファイル、設定、設定、インストールされたソフトウェア）を変更するものは、明示的な確認が必要です。
• リリースアーティファクト欠落：リリースノート、リリーステンプレート、またはプロジェクトワークフロー内にリストされたすべてのアーティファクトが存在し、完了を宣言する前にアップロードされていることを検証します。
• 生成されたアーティファクトドリフト：ソース変更が生成またはバンドルされたアウトプットを必要とする場合、アウトプットが再生成され、含まれていることを検証します。
• バージョンスキュー：マニフェスト、パッケージメタデータ、アプリ設定、チェンジログ、タグ、またはロックファイル全体のリリースバージョンフィールドが同期したままでなければなりません。
• 差分内の未知の識別子：差分に導入され、コードベースに存在しない関数、変数、またはタイプは、ハード停止です。参照を書いたり承認したりする前に grep します：grep -r "name" . -- 差分外の結果 = 存在しない。
• インジェクションと検証：システム エントリポイントでの SQL、コマンド、パスインジェクション。認証情報がハードコード、ログ、コミット、またはパブリックドキュメントにコピーされています。
• 依存関係の変更：package.json、Cargo.toml、go.mod、requirements.txt での予期しない追加またはバージョンバンプ。差分で明らかに必要でない新しい依存関係にフラグを立てます。
• 安全性シンク：破壊的なファイル操作、シェルまたは AppleScript コンストラクション、cwd/パス/symlink トラバーサル、承認またはサンドボックス境界の変更、署名/appcast フロー、および認証プロンプトは、検証、ロールバック、およびユーザー確認動作の明示的なレビューが必要です。

ナレッジ同期

差分をレビューした後、プロジェクトドキュメントでまだキャプチャされていない不変量を導入するかどうかを確認します：

• 新しい安全性ゲートまたはパスガードルール → AGENTS.md
• 新しい UI 制約（レイアウトルール、アニメーション、オーバーレイ登録）→ .claude/rules/*.md
• 新しいデプロイ/リリース ステップまたはアーティファクト → AGENTS.md または docs/
• 新しいクロスファイル同期要件（enum ↔ HTML アンカー、Swift キー ↔ xcstrings）→ AGENTS.md

見つかった場合、差分から不変量が明確である場合は safe_auto としてドキュメント更新を適用するか、署名に doc debt としてフラグを立てます。新しい不変量が存在しない場合、署名は doc debt: none です。

スペシャリストレビュー（Standard および Deep のみ）

references/persona-catalog.md をロードして、どのスペシャリストがアクティブになるかを判定します。利用可能な環境のエージェントまたはサブエージェント機能を使用して、すべてのアクティブ化されたスペシャリストを並列で起動し、完全な差分を渡します。並列レビュアー機能がない場合は、スペシャリリストパスを同じセッション内で順次実行します。

検出結果をマージします：2 人のスペシャリストが同じコード位置にフラグを立てた場合、より高い重大度を保持し、クロスレビュアー合意をメモします。異なるコード位置での検出結果は、テーマを共有している場合でも決して重複ではありません。

オートフィックスルーティング

クラス	定義	アクション
safe_auto	明確で、リスクフリー：タイポ、不足しているインポート、スタイルの不一致	直ちに適用
gated_auto	可能性が高いが動作を変更：null チェック、エラーハンドリング追加	1 つのユーザー確認ブロックに一括
manual	判定が必要：アーキテクチャ、動作変更、セキュリティトレードオフ	署名に表示
advisory	情報のみ	署名にメモ

すべての safe_auto 修正を最初に適用します。すべての gated_auto を 1 つの確認ブロックに一括します。各 1 つについて個別に質問しないでください。

対抗的パス（Deep のみ）

「この特定の差分を通してこのシステムを破壊しようとしている場合、何を悪用しますか？」4 つの角度（references/persona-catalog.md を参照）：仮定違反、コンポジション失敗、カスケード構築、乱用ケース。0.60 信頼度以下の検出結果を抑制します。

GitHub オペレーション

MCP または raw API ではなく、すべての GitHub インタラクションに gh CLI を使用します。マージ前に CI がパスすることを確認します。

検証

このスキルディレクトリから bash scripts/run-tests.sh を実行するか、ターゲットリポジトリのプロジェクトの既知の検証コマンドを実行します。完全な出力をペーストします。

スクリプトが非ゼロで終了するか、(no test command detected) を出力する場合：停止します。完了を主張しません。ユーザーに進行前に検証コマンドを依頼します。ユーザーもコマンドを提供できない場合、署名に verification: none -- no command available として明示的に文書化し、パスではなく構造的な隙間としてフラグを立てます。

バグ修正の場合：修正前に古いコードで失敗する回帰テストが存在する必要があります。

落とし穴

何が起こったか	ルール
#255 を議論するときに #249 にコメント	行動前に gh issue view N でタイトルを確認
PR コメントが報告のように聞こえた	1-2 文、自然、同僚のような。構造化されていない、AI のように聞こえない。
PR コメントが箇条書きを使用した	短い段落として書き、1 つの考えを 1 段落に；まずコントリビューターに感謝
article.en.md inside _posts_en/ がサフィックスを倍にした	ターゲットディレクトリの既存ファイルの命名規約を最初に確認
env vars を設定せずにデプロイ	デプロイ前に vercel env ls を実行；ローカルキーに対して diff
プッシュが auth 不一致で失敗	新しいプロジェクトの最初のプッシュ前に git remote -v を実行

ドキュメントレビュー

ドキュメント、PDF、ホワイトペーパー、またはプロズレビューの場合、/write（ドキュメントレビューモード）にルーティングします。/check はコード差分とリリースアーティファクトのみを処理します。

署名

files changed:    N (+X -Y)
scope:            on target / drift: [what]
review depth:     quick / standard / deep
hard stops:       N found, N fixed, N deferred
specialists:      [security, architecture] or none
new tests:        N
doc debt:         none / AGENTS.md needs X / rules need Y
verification:     [command] -> pass / fail