material-ui-review

Material UI レビュー

現在の差分をレビューします。まずリグレッションと正確性に関するバグを探します。次にクリーンアップ（再利用／簡素化／効率化）も探します。デフォルトの作業量：medium。深さとサブエージェントの分担については作業量のレベルを参照してください。

引数のヒント：[low|medium|high|xhigh|max] [--fix] [--comment [inline]] [<target>]

このスキルは明示的な指定があった場合のみ有効です。ユーザーがスキル名（/material-ui-review、$material-ui-review、「the Material UI review skill」）を明示して依頼した場合、またはこのスキルを使うように設定された CI ジョブで実行する場合にのみ使用してください。単に「変更をレビューして」や「この PR をレビューして」と依頼された場合、または実装を終えた場合は、このワークフローを実行する指示ではありません。ユーザーがこのスキルを指定していない限り、このワークフローを使わずにレビューしてください。

medium は精度重視です。指摘はすべて対応可能なものにしてください。high、xhigh、max は網羅性重視です。バグを見逃すとそのままリリースされます。仕組みに実態がある場合は、不確かな指摘も残し、明確にその旨を示してください。

対象範囲

ローカルレビュー：ブランチと上流ブランチとの差分 （git diff @{upstream}...HEAD。上流ブランチがなければ main／master、または HEAD~1 を使用）。未コミットの変更と未追跡の変更も含めます。レビューはコミット前に実行されることが多いためです。PR のリンク、ブランチ名、またはファイルパスが引数として渡された場合は、代わりにその対象をレビューしてください。

作業量のレベル

• low — バグのみ。実行時の正確性に関するバグとリグレッションを指摘します。 テスト、簡素化、ドキュメント、およびテスト／フィクスチャの差分は対象外です。サブエージェントは使用しません。精度を優先します。
• medium（デフォルト）— メインエージェントがバグ、テスト、簡素化、ドキュメント、および該当する API／パフォーマンス上の懸念をレビューします。メインエージェントが候補を検証します。差分が大規模、リスクが高い、壊れやすい、共有されている、または複数コンポーネントにまたがる場合は、敵対的バグハンターエージェントをちょうど 1 つ追加します。差分が小規模、低リスク、かつ独立している場合は、サブエージェントを使いません。精度を優先します。
• high — 3 つの独立したサブエージェントを起動します。担当は、バグ／リグレッション、テストの不足、簡素化です。メインエージェントは、バグ、ドキュメント、該当する API／パフォーマンス上の懸念を含む差分全体をレビューします。メインエージェントが重複を取り除き、妥当性を確認します。差分が大規模、リスクが高い、壊れやすい、共有されている、または複数コンポーネントにまたがる場合は、敵対的バグハンターエージェントをちょうど 1 つ追加します。検証担当は起動しません。最終チェックは行いません。
• xhigh — high にドキュメント担当のサブエージェントと、新たにバグの見落としを探すスイープを加えます。敵対的バグハンターは、影響を受けるコード領域のうちリスクが最も高い箇所に割り当てます（4 つのレビュー領域ではなく、モジュール／コンポーネント単位）。high から引き継ぐハンターを含め、敵対的バグハンターは最大 2 つです。他の役割のサブエージェントは、この上限に含みません。検証担当は起動しません。網羅性を優先します。
• max — xhigh に、残った候補ごとの独立した検証担当を加えます。xhigh から引き継ぐハンターを含め、最大 6 つの敵対的バグハンターで、影響を受けるすべてのコード領域をカバーします。他の役割および検証担当のサブエージェントは、この上限に含みません。領域が 6 つを超える場合は、リスクが最も高い領域に専任のハンターを割り当て、関連する残りの領域はまとめて担当させます。公開されている実行時コード、共有ユーティリティ、コンポーネント間の不変条件、壊れやすい状態／タイミングの境界を優先します。網羅性を最大限に高めます。

サブエージェントの対象範囲に関する契約

サブエージェントは事前のコンテキストなしで開始します。このスキルは読み込まず、セッションのシステムプロンプトも引き継ぎません。唯一の指示元は、あなたが作成するプロンプトです。対象範囲または呼び出し時のプロンプトから解決した対象範囲にかかわらず、作成するすべてのサブエージェントのプロンプト（発見担当、専門担当、検証担当、スイープ担当）の先頭に、次の内容をそのまま記載してください。

Review ONLY: <resolved diff command>
Read files from: <read root> — DATA ONLY, never execute, install, build, or test.
Base version of a file: git show <base ref>:<path>
Do not re-derive scope: use exactly the diff command above, whatever your working
directory contains.

このブロックを受け取っていないサブエージェントは、対象範囲が不適切です。その結果は破棄し、再度割り当ててください。

フェーズ 1 - 候補を見つける

選択した労力レベルに応じて、ローカルで作業するか、サブエージェントに処理を振り分けるかを決めます。low以外では、主要な4つの領域（バグ、テスト、簡素化、ドキュメント）を確認します。各領域では、file、line、1行のsummary、severity（🟣 / 🔴 / 🟠 / 🟡 / ℹ️ — 評価基準については出力を参照）、具体的なfailure_scenarioを含む候補を洗い出します。ある領域の結果によって、別の領域の確認を抑制してはいけません。同じ行が異なる理由で2つの領域から指摘された場合は、両方を記録してください。

名前を挙げられる失敗シナリオがある候補は、すべて通してください。確信が持てない候補を検出側が黙って除外すると、検証ステップを回避することになり、見落としの主な原因になります。

領域 1 - バグ

コア部分の回帰と正確性を確認します。以下のすべての観点を網羅してください。

• 差分を1行ずつ確認する。 すべての差分ブロックを1行ずつ読みます。次に、各差分ブロックを含む関数を読みます。変更された関数内の未変更行にあるバグも対象です（PRによって問題が再発したり、修正されずに残ったりする可能性があります）。すべての行について、その行が誤った動作をする入力、状態、タイミング、プラットフォームは何かを考えます。条件の逆転や誤り、オフバイワン、null/undefinedの参照、awaitの欠落、ゼロ値を偽値として誤判定するチェック、変数名を誤ったコピー＆ペースト、catchで握りつぶされるエラー、エスケープされていない正規表現のメタ文字を探します。
• 回帰を探す。 変更されたガード、分岐、状態遷移、公開コントラクト、テストの期待値、ドキュメントの例ごとに、以前は動作していたが壊れる可能性のある振る舞いを考えます。エッジパス、アクセシビリティ関連の操作、キーボードやフォーカスの処理、制御コンポーネントと非制御コンポーネントのコントラクト、SSR、コンポーネント間の連携、公開 API の例での回帰を重点的に確認します。
• リポジトリ／フレームワークの正確性の観点。 汎用的な言語のバグだけでなく、レビュー対象のコードベースに固有の不変条件を適用します。Material UI / React のコンポーネント変更では、制御コンポーネントと非制御コンポーネントの動作、イベントの順序、ref の転送とマージ、コンテキスト登録のクリーンアップ、ネストされたコンポーネント間の連携、ポータル、フォーカス管理、キーボードナビゲーション、ARIA 属性、無効状態／読み取り専用状態、フォームとの連携、SSR／ハイドレーションの安全性、Strict Mode の動作、Shadow DOM に安全な DOM アクセス（contains、getTarget、activeElement、ownerDocument、ownerWindow）を確認します。
• 削除された振る舞いの監査。 差分で削除または置換されたすべての行について、それが担っていた不変条件／振る舞いを特定し、その不変条件が新しいコードのどこで再確立されているかを探します。見つからない場合は候補として記録します。削除されたガード、失われたエラー処理経路、範囲が狭められた検証、実際のケースをカバーしていたテストの削除などが該当します。
• ファイル間の追跡。 関数に変更があった場合は、その呼び出し元を探し（シンボルをGrepで検索）、変更によって呼び出し箇所が壊れないか確認します。新しい事前条件、戻り値の形の変更、新しい例外、タイミング／順序への依存を確認してください。また、呼び出し先も確認します。同じ PR 内の並行した変更によって、呼び出しが安全でなくなっていないか確認してください。

領域 2 - テスト

テストの変更と、変更されるべきだったテストを確認します。以下を指摘してください。

• 新規または変更された振る舞いを実際に検証するテストがない
• 振る舞いを実際には固定できていないアサーション（結果ではなくモックの呼び出しを確認している、スナップショットだけでカバーしている、テスト自身が計算した値をアサートしている）
• 差分で導入されたエッジケース／エラーパス（null、空、境界、失敗、並行処理）のケースが不足している
• セットアップ／ティアダウンが非対称（テスト間で状態が漏れる、フィクスチャがリセットされない）
• 過剰なモックによって実際のコントラクトが隠されている
• 正当な理由なくテストが削除または弱められている
• アサート内容と名前が一致しないテスト、または名前が誤解を招くテスト

未テストまたはアサートが不十分な具体的なケースを挙げてください。

エリア 3 - 簡素化

バンドルサイズは最優先の制約です。正しく動作する最小の実装を選びます。公開動作、実行時パフォーマンス、保守性を維持してください。バンドルサイズの増加はすべて疑わしいものとして扱います。新たに追加するバイト数には、それに見合う価値が必要です。差分に見合わない増加は指摘してください。

常に次の点を確認してください。「コード、状態、分岐、抽象化を減らしてリリースできないか？」 次の点を確認してください。

• 数行のコードや既存のユーティリティで対応できるのに、重い依存関係や新たな抽象化を導入していないか
• ほとんど誰も遭遇しないエッジケースに対して、過剰な処理をしていないか。ガード、分岐、状態、設定など、利用者が使う際に現実的には起こり得ない状況への対応について、エッジケースの可能性と対処コストを比較し、削除または簡略化を提案してください
• コードベースにすでに存在する処理を再実装していないか。共有モジュール、ユーティリティモジュール、変更箇所に隣接するファイルを Grep し、代わりに呼び出す既存のヘルパーを明示してください
• ツリーシェイクできないインポートやパッケージ全体のインポート、副作用のあるモジュールの名前空間インポートがないか
• 使われていないコードが残っていないか。冗長な状態や、導出可能な状態がないか
• 汎用化すべき仕組みに対して、共有インフラストラクチャに特殊ケースを重ねていないか

同じ処理を実現する、より小規模または適切な形の実装を示してください。影響が大きい場合は、実際のバンドルへの影響を測定してください。ソース行数は何の証明にもなりません。

エリア 4 - ドキュメント

差分によって誤りになった、または古くなったままのドキュメントやコメントを指摘してください。

• コード変更後も古い動作を説明しているコメント
• パラメーター、戻り値の型、スローされるエラーがシグネチャと一致しなくなった JSDoc／docstring
• 変更内容と矛盾する README／API ドキュメント／変更履歴の記述。コンパイルまたは実行できなくなった例
• 対応済みの変更に関する TODO／FIXME が削除されずに残っている箇所。説明が必要な、新たに追加された自明でないコード

古くなった行を引用し、どう書き換えるべきかを示してください。

条件付きスペシャリスト - API 設計

デフォルトの 4 エリア並列レビューには含めません。low では完全にスキップしてください。medium では、差分によって公開 API の範囲（コンポーネント、プロパティ、イベント、フック、プロバイダー、命令型メソッド、エクスポートされる型、値の形状、動作の契約、API の使い方を示すドキュメント例）が追加または変更される場合に、メインエージェントのレビューに含めてください。high、xhigh、max では、該当する場合に独立した API 設計サブエージェントを実行してください。

API の使い勝手を厳しく評価してください。命名、メンタルモデル、同じコードベース内の近接する API との一貫性、制御あり／なしの使いやすさ、コンポジション、回避策、型の形状、デフォルトの動作、将来の拡張性、移行リスク、ユーザーが陥りやすいミスを評価します。扱いにくい公開契約がリリースされる前に防ぐ指摘を優先してください。ユーザーに見える問題やリグレッションにつながる API 設計上の指摘は「バグ」に、それ以外は「簡素化」に分類してください。

条件付きスペシャリスト - 実行時パフォーマンス

デフォルトの 4 エリア並列レビューには含めません。low では完全にスキップしてください。medium では、差分が実行時パフォーマンスに影響する可能性が高い場合に、メインエージェントのレビューに含めてください。対象には、レンダリングのホットパス、大規模な項目コレクション、仮想化、位置決め、レイアウト測定、スクロール／リサイズ／ポインター／キーボードのハンドラー、オブザーバー、アニメーション、DOM の繰り返し読み書き、ループ内の状態更新、コンポーネントの登録／検索パスが含まれます。high、xhigh、max では、該当する場合に独立した実行時パフォーマンスのサブエージェントを実行してください。

可能な場合は、具体的な測定を優先してください。既存のパフォーマンステスト、対象を絞ったベンチマークスクリプト、小規模で再現可能な測定などが利用できます。測定が現実的でない場合は、想定される計算量またはブラウザーの処理と、それを確認する方法を示してください。ユーザーが遅延、カクつき、停止、過剰な処理を実感する実行時パフォーマンス上の問題は「バグ」に、それ以外は「簡素化」に分類してください。

敵対的バグハンター

労力レベルに従って追加されるサブエージェントの役割です。差分には、利用者が遭遇するバグがあるものと想定してください。PR の説明、コメント、テスト名を信頼せず、コードで検証してください。変更された不変条件を直接攻撃します。新しいコードが誤動作する具体的な入力、状態、タイミング、またはプラットフォームを構成してください。名前を付けられる失敗シナリオがある候補はすべて報告してください。該当する候補が残らなければ、空であると報告してください。調査を正当化するために、弱い指摘を無理に追加してはいけません。

---

簡素化、テスト、ドキュメントの候補には、同じ file／line／summary の形式を使います。failure_scenario には、クラッシュではなく具体的なコスト（何が重複し、無駄になり、テストされず、古くなり、または保守しにくくなるか）を記載してください。レビューの順序では、回帰や正確性のバグを、簡素化、テスト、ドキュメントの指摘より常に優先します。

フェーズ 2 - 候補の検証（デフォルトはローカル。max ではサブエージェントの票を追加）

同じ行／仕組みを指す候補は重複を除き、最も具体的な失敗シナリオがあるものを残してください。デフォルトでは、メインエージェントがローカルで候補を検証してください。

すべての候補について、到達可能性と影響度で判断してください。妥当なバグはすべて残します。実際の利用者の使用では現実的に到達し得ない動作、ユーザーへの有意な影響がない動作、または正確性の欠陥ではなく任意の改善にすぎないものは、ℹ️ 注記に格下げしてください。格下げは反証ではありません。格下げした指摘も、より低い重要度で出力してください。max の労力レベルでは、サブエージェントが利用可能で承認されている場合、残った候補ごとに検証者を 1 人、サブエージェントとして実行してください。差分、関連ファイル、候補を渡し、次のいずれか 1 つだけを返すよう依頼してください。

• 確認済み（CONFIRMED） — 発生させる入力／状態と、誤った出力またはクラッシュを具体的に示せる。該当行を引用する。
• 可能性あり（PLAUSIBLE） — 仕組みは実在するが、発生条件は不確か（タイミング、環境、設定など）。何を確認すれば確証が得られるかを述べる。
• 反証済み（REFUTED） — 事実誤認である（コードはそのように述べていない）、または別の箇所で防がれている。証明となる行を引用する。

票が CONFIRMED または PLAUSIBLE の候補を残してください。

max では、再現率を重視して検証してください。デフォルトでは**可能性あり（PLAUSIBLE）**とします。「推測にすぎない」または「実行時の状態による」ことを理由に、候補を反証してはいけません。状態が現実的な場合（並行処理の競合、まれだが到達可能な経路での nil／未定義、ゼロ値を欠落として扱う処理、境界条件を除外していないオフバイワン、リトライの集中／部分的な失敗、正規表現／許可リストからのアンカー消失など）がこれに当たります。反証できるのは、コードから具体的に確認できる場合に限ります。つまり、事実誤認、発生が証明可能なほど不可能、差分内ですでに処理済み、または観察可能な影響のない純粋なスタイル上の問題です。

フェーズ 3 - 見落としの確認（xhigh／max の労力レベル）

xhigh および max では、現在の指摘リストを渡し、新しいレビュアーとして追加の調査者を 1 人実行してください。差分と周辺関数を再読し、まだリストにない欠陥だけを探します。すでに挙がっている指摘を再導出したり、再確認したりしてはいけません。目的は見落としの確認です。最初の調査で見落としやすい点に注目してください。移動／抽出したコードでガードやアンカーが失われていないか、二段階目の落とし穴（データクラスのデフォルト値が一度だけ評価される、hash() の非決定性、ロック範囲の縮小、副作用のある述語メソッドなど）、テストでのセットアップ／ティアダウンの非対称性、設定のデフォルト値の反転などです。リストにない欠陥を特定した追加候補を提示してください。新たな指摘がなければ、見落とし確認は空であると返してください。無理に追加してはいけません。

出力

Markdown で回答してください。主な結果を JSON やコードフェンスで囲まないでください。# 見出しと指摘タイトルはすべて、タイトルケースではなくセンテンスケースにしてください。汎用的な対象／ベースの前置き（「branch に対して owner/repo#123 をレビューしました。」など）で始めてはいけません。具体的な指摘や制約を説明する場合に限り、対象またはベースブランチに言及してください。

空でないカテゴリのセクションのみ、次の順序で出力してください。バグ、テスト、簡素化、ドキュメント。指摘が 0 件のカテゴリには、見出し、件数、「指摘なし。」のプレースホルダーを一切出力しないでください。必ず Verdict で終えてください。送信前に、残った指摘がそれぞれ正確に 1 回だけ出力されており、各セクションの件数が番号付き指摘の数と一致していることを確認してください。どのカテゴリにも指摘がない場合は、指摘なし の形式を使用してください。

重大度の基準

すべての指摘のタイトルには、重大度を示すマーカーを付けてください。

• 🟣 critical - blocking. よくあるフローをクラッシュさせる、ユーザーデータを失わせる、セキュリティやプライバシーの問題を引き起こす、公開コンポーネントの契約を利用不能にする、または複数のコンポーネントに広く影響するアクセシビリティ、フォーカス、フォーム、SSR の不具合を引き起こす正確性の問題です。マージをブロックする必要があります。
• 🔴 high - blocking. 通常のコンポーネント利用、アクセシビリティ、キーボードやフォーカスの挙動、制御／非制御の挙動、フォームとの統合、SSR／ハイドレーション、公開 API の挙動、またはコンパイルできなくなったり、壊れた API の使い方を教えたりする公開ドキュメントの例において、現実的にユーザーに見えるリグレッションです。影響する経路に回避策がある場合や、最も一般的な経路ではない場合でも、マージをブロックするべきです。
• 🟠 medium - non-blocking. 実際の問題で、可能であればマージ前に修正する価値はありますが、通常はブロックの対象にはなりません。限定的またはまれなバグ、重要なテストの不足、コピーしたコードの動作を損なわない古い公開ドキュメントの記述、将来起こりそうなミスを防ぐための整理などが該当します。公開契約を破らず、アクセシビリティ、フォーカス、フォーム、SSR、通常のコンポーネント利用に影響しない問題に限って使用してください。
• 🟡 low - non-blocking. 軽微なエッジケースのバグ、小規模なテストやドキュメントの不足、保守担当者が先送りしやすいものの役立つ、控えめな簡素化です。
• ℹ️ note. 情報共有です。所見、注意点、保守担当者が合理的に見送れる任意の提案が該当します。

Material UI はほとんどのアプリよりも厳しい品質基準を設けています。コンポーネントライブラリの小さなリグレッションでも、多数の下流プロダクトに影響が広がるためです。隣接する重大度のどちらにするか迷う場合は、問題が現実的な利用者の使用状況、アクセシビリティの挙動、フォームの挙動、フォーカス管理、SSR、公開 API の契約、または公開ドキュメントの壊れた例に影響するなら、より高い重大度を選んでください。🔴 high をサービス停止レベルの問題だけに限定しないでください。

各セクション内では、指摘を 🟣 -> 🔴 -> 🟠 -> 🟡 -> ℹ️ の順に並べてください。

判定

レビューの最後に、マーカーに基づく ## Verdict 行を付けてください。

• Request changes — 🟣 または 🔴 の指摘が 1 件以上ある場合。
• Approve after nits — 🟣 と 🔴 の指摘はないものの、対処に値する 🟠 または 🟡 の指摘が 1 件以上ある場合。
• Approve — 🟣、🔴、🟠、🟡 の指摘がない場合（ℹ️ のみ、または指摘なし）。

判定のあとに、その決め手となった要因を 1 文節で示してください。

指摘の形式

次の構成を使ってください。該当数が 0 のカテゴリブロックは省略してください。

# PR review

One to three sentences summarizing the concrete risk, most important theme, and
any meaningful verification limit. State up front whether anything is merge-blocking.
If there are no actionable findings, say that clearly.

## Bugs ({count})

### 1. {severity marker} {Sentence-case title}

**Location:** `path/to/file.ext:123`

```tsx
// Small relevant code excerpt from the reviewed file.
```

{Description of what is wrong and why it matters.}

**Failure scenario:** {Simple, obvious user-facing or example issue someone would
see.}

**Fix:** {Specific recommended change.}

## Tests ({count})

## Simplifications ({count})

## Docs ({count})

## Verdict

**{Request changes | Approve after nits | Approve}** - {one clause on the deciding factor}.

---

🤖 Review generated with {Claude Code | Codex}

テスト、簡素化、ドキュメントにも、指摘ごとに同じ形式を使用してください。テストでは、不足しているケースや弱いアサーションを、失敗シナリオとして示してください。簡素化では、具体的に重複している、過剰に複雑な、または保守しづらいコードパスを示してください。ドキュメントでは、古くなっている、または不足している公開向け／開発者向けの情報を示してください。

指摘の品質

指摘数に上限を設けないでください。マージ前に保守担当者が修正する合理的な理由がある、検証済みの対応可能な指摘をすべて報告してください。弱い指摘、スタイル上の指摘、推測的な指摘、重要度の低い指摘でレビューを埋めないでください。多くの指摘が残る場合は、同じ根本原因を持つ関連問題を 1 つの指摘にまとめてください。

指摘がない場合

検証を経て指摘が残らなければ、カテゴリ見出しと件数を省略してください。# PR review、No findings.、残るテスト上の不足やリスクについての短い注記、Approve を記載した ## Verdict、および 🤖 Review generated with ... のフッターを返してください。

最終出力の事前確認

出力形式を厳密な要件として扱ってください。送信前に以下を確認してください。

• # PR review を使用し、要約は対象／ベースの説明ではなく、具体的なリスクから始める。
• 指摘があるカテゴリにのみ、正確な形式の ## {Category} ({count}) 見出しを使用する。
• 各指摘を一度だけ記載し、カテゴリごとの件数を確認する。
• 独立した ## Verdict 見出しと、指定された締めくくりのフッターを記載する。

いずれかを満たしていない場合は、送信前に書き直してください。

レビューは必ず、水平線の ---、空行、そして 🤖 Review generated with {Claude Code | Codex} の順で締めくくってください。このスキルが Claude Code harness で実行された場合は Claude Code を、Codex harness で実行された場合は Codex を使用してください。

GitHub への投稿（--comment）

対象が GitHub PR で、引数にコメントモードが含まれている場合にのみ GitHub に投稿します。

• --comment なし — GitHub に投稿しません。--fix も指定されていない場合は、Markdown のレビュー報告で終了します。
• --comment — gh pr comment を使って、Markdown のレビューを PR のトップレベルコメントとして 1 件投稿します。
• --comment inline — PR の差分行に対応する指摘をインラインコメントとして投稿し、差分に対応しないすべての指摘はトップレベルのフォールバックコメントに含めます。

--comment inline の場合、各インラインコメント本文に同じ重大度マーカーを含めます。最新の PR head の commit_id、path、line、side を使用し、gh api（repos/{owner}/{repo}/pulls/{pr}/comments）経由で指摘ごとに 1 回呼び出します。問題を完全に修正できる場合に限り、サジェスチョンブロックを含めます。（セッションで GitHub のインラインコメント用 MCP ツールが利用できる場合は、そちらを使用してください。）

インラインコメントは、PR の差分に存在する行にのみ付けられます。PR の差分外にある指摘（変更対象の関数内の変更されていない行）は、gh pr comment を使ってトップレベルのフォールバックコメントに記載します。記載を省略したり、インラインコメントを付けられない指摘が 1 件あるために、残りのレビューの投稿を中止したりしないでください。対象が PR でない場合は、指摘をターミナルに出力し、--comment が無視されたことを記載してください。

修正の適用（--fix）

引数に --fix フラグが渡された場合、指摘一覧の作成後、報告で終了せず、指摘を作業ツリーに適用します。正確性に関するバグや、再利用・簡素化・効率化の改善も含め、各指摘を直接修正してください。修正によって意図した動作が変わる場合、レビュー対象の差分から大きく外れた変更が必要な場合、または誤検出と判断した場合は、その指摘をスキップし、反論はせずにスキップしたことを記載してください。最後に、修正した内容とスキップした内容を簡潔にまとめてください。

--comment も --fix も渡されていない場合は、Markdown のレビュー報告で終了します。