sglang-humanize-review

SGLang ヒューマナイズレビュー

現在のブランチに過去の証拠を適用する際は、メンテナンスされている ソースの契約を参照してください。レビュー／履歴コーパスにはそれぞれ収集日があり、今日のディスパッチや数値のデフォルトを保証するものではありません。カーネルを置き換える場合は、エンドツーエンドテストでカバーされていると判断する前に、実際のモデルで候補が実行されることを確認してください。

概要

ユーザーがSGLangの人間らしいコードレビューを求めている場合や、一般的なリンティングではなくSGLangのメンテナーに似たレビューのフィードバックを求めている場合に、このスキルを使用してください。

すべてのレビューはPR理解パスから始めます。変更の簡潔な要約と、PRで追加／変更された手順を示したMermaid実行フローチャートを提示し、レビュー担当者が指摘事項を読む前に差分の実際の動作を把握できるようにします。PR理解図を参照してください。

同梱のコーパスは、最初の公開PRから2026-07-27までのsgl-project/sglangのPRから収集されており、ボット／エージェントによるPR作成者を除外することを意図しています。過去のスナップショットにはUserタイプのボットによる混入（sglang-botのPR 59件／インラインスレッド60件）が含まれており、その内容と件数は保持されています。今後の収集では、-bot、metamergebot、diffrayのアカウントを除外します。ミラー上の作成者情報は、人間による設計意図の証拠にはなりません。このスキルに関する公開フレームワークの知識は2026-10-05に更新されましたが、その際にgzipコーパス自体は再クロールされていません。そのため、2026-07-27以降のレビューはGitHubで直接確認してください。収集ツールはすべてのPRの会話とレビュー履歴をページネーションして取得するため、複数ラウンドにわたる長い議論も、最初の100件で切り捨てられず全体が収録されています。コーパスは個別のコメントだけでなく、レビューエピソードごとに構成されています。

• inline_review_thread：ファイル／パス固有のGitHubプルリクエストレビューコメント。diff_hunkのコンテキストを含み、返信はスレッドごとにまとめられています。
• pr_conversation：設計に関する議論、再現手順の依頼、ベンチマークの調整、作成者からのフォローアップなど、PRのトップレベルの会話コメント。
• review_submission：COMMENTやREQUEST_CHANGESなど、レビュー状態を保持したレビュー概要本文。

各エピソードには、PRメタデータ、レビュアーの識別情報、元のコメント本文、元のコメントの言語、タイムスタンプ、カテゴリー、およびGitHubで取得可能な場合は複数ラウンドにわたる返信が保持されています。カバレッジ、件数、上位パス、カテゴリーの分布については、まずreferences/corpus-summary.mdを読んでください。生のgzipコーパスをコンテキストに貼り付けないでください。メモリ使用量を抑えたセグメント単位で読み込み、ダイジェストを返すヘルパースクリプトを使用してください。

コーパスツール

ツールは2つあります。実際のPRレビューでは、以下の網羅的なスキャンが必須です（ワークフローの手順3を参照）。最初のN件を検索するツールは、追加の詳細調査にのみ使用します。

網羅的なスキャンと統合（すべてのレビューで、最初に実行）

summarize_sglang_review_corpus.pyは、メモリ使用量を抑えたセグメント単位でコーパス全体をスキャンし、関連するすべてのスレッドを集計に取り込みます（最初のN件だけではありません）。その後、関連性の高い順に上位のレビュー意見のみを保持します。変更したパスをすべて指定し、PRのリスクキーワードも渡してください。--pathと--queryは繰り返し指定でき、OR条件で組み合わせられます。

python3 skills/sglang-humanize-review/scripts/summarize_sglang_review_corpus.py \
  --path python/sglang/srt/speculative --path python/sglang/srt/managers \
  --query eagle --query "cuda graph" --query verify --query logprob \
  --top 30

Scanned N threads ... matched M threads across K PRsと表示されるため、カバレッジを明確に確認できます。集計結果と関連性の高いスレッドを読み、レビューを始める前に、繰り返し見られる過去のレビュー意見を簡潔にまとめてください。一致するスレッドをすべて読む必要がある場合は、--format jsonlを使ってストリーミングしてください。

最初のN件を検索（追加の詳細調査のみ）

トピック、パス、カテゴリー、レビュアーでコーパスを検索します。

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --query cuda --limit 5

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --path python/sglang/srt --category correctness --limit 8

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --query server_args --format jsonl --limit 3

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --kind pr_conversation --query benchmark --limit 5

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --kind review_submission --query "request changes" --limit 5

コーパス全体は次のとおりです。

references/sglang-review-corpus.jsonl.gz

ユーザーから証拠の更新を求められた場合に限り、再生成してください（--end-yearを現在の年に更新してください。収集ツールはイベント期間を「現在」までに制限し、各PRの会話／レビュー履歴全体をページネーションして取得します）。

python3 skills/sglang-humanize-review/scripts/collect_sglang_review_corpus.py \
  --repo sgl-project/sglang \
  --from-beginning \
  --end-year 2026 \
  --out-dir skills/sglang-humanize-review/references

レビューワークフロー

1. まず実際の差分を確認します。
   • git diff、gh pr diff、またはユーザーが提示したパッチを使用します。
   • 変更された SGLang のサブシステムを特定します：サーバー引数、スケジューラー、メモリ／キャッシュ、モデルランナー、アテンションバックエンド、量子化、カーネル、OpenAI API、メトリクス、ドキュメント、テスト。
2. references/corpus-summary.md を読みます。
   • 差分と重なるレビュー対象の主要領域とカテゴリを確認します。
   • エピソードの網羅性を確認します。ファイル内の調査結果にはインラインの根拠が最適です。設計、ベンチマーク、再現手順、作成者によるフォローアップには PR の会話が最適です。レビューの厳しい指摘やメンテナーによる要約にはレビュー投稿が最適です。
   • 関連するコーパスの例は元の言語のまま保持します。ユーザー向けのコメントは、ユーザーが求めない限り翻訳しないでください。
3. コーパスを徹底的に調査し、その後で過去のレビュー意見をまとめます。この手順は必須であり、調査結果を書く前に完了しなければなりません。最初に見つかった数件だけでレビューしてはいけません。
   • 変更されたすべてのパス（--path は繰り返し指定可能）と、PR のリスクを示すキーワード（--query は繰り返し指定可能。例：cuda、kv cache、server_args、openai、logprob、tp、dp、eagle、fp8、benchmark、pytest）を指定して、summarize_sglang_review_corpus.py を実行します。このスクリプトはメモリ使用量を抑えたセグメント単位で全スレッドをスキャンし、関連する一致をすべて集約します。最初の N 件だけを対象にすることはありません。
   • Scanned N ... matched M across K PRs の行で網羅性を確認します。一致が 0 件の場合は、パスやキーワードの範囲を広げて再実行します。一致が非常に多い場合は、集約結果と上位のスレッドを読み、必要に応じて --format jsonl で全件をストリーム出力します。
   • 一致したスレッドを読みます。特に、PR によって動作、テスト、ドキュメント、ベンチマーク、デプロイ時のデフォルト、モデルサポートのいずれかが変わる場合は、インライン以外の情報源（pr_conversation または review_submission）を少なくとも 1 つ確認します。そのうえで、短い統合結果をまとめます。繰り返し指摘される懸念、ブロッキングとなった指摘と細かな指摘の違い、求められた再現手順やベンチマーク、このサブシステムで一般的だった解決策を含めます。調査結果はこの統合結果に基づかせます。幅広いキーワードに一致したものより、同じサブシステムの根拠を優先してください。
   • query_sglang_review_corpus.py を使うのはその後です。全件調査で見つかった特定のスレッドやレビュアーを詳しく調べるために使用します。
4. このリポジトリ内の別のスキルが対象とする領域に差分が触れる場合は、スキル横断の根拠も追加します。
   • モデルファミリーの実装や最適化の場合：指摘の前に変更が過去の PR を繰り返しているか、矛盾しているかを確認するため、モデルのスラッグを指定して model-pr-optimization-history を検索します。
   • パフォーマンスの主張やホットパスの場合：一般的な「ベンチマーク」を求めるのではなく、llm-torch-profiler-analysis、llm-pipeline-analysis、または model-compute-simulation の根拠を使用します。
   • メモリ／KV／キャッシュ容量の変更の場合：起動ログと容量計上について、llm-serving-capacity-planner の想定を使用します。
   • サービング時のインシデント、ハング、分散処理の回帰の場合：sglang-prod-incident-triage 形式の再現要件を使用します。
5. 判断の前に PR の内容を把握します（PR 理解パス）。
   • この手順は必須で、レビューの指摘より必ず先に行います。
   • 目的は、レビュー担当者が差分全体を読まずとも、1 分以内に「何が変わったか」と「変更されたコードがどのように実行されるか」を理解できるようにすることです。
   • PR 理解図の仕様に沿って、短い説明と Mermaid 図を作成します。
   • 変更行を通る実際の実行パスをたどります。エントリーポイント、制御フロー、データフロー、変更された分岐／呼び出し、および新しい動作と従来の動作が分岐する箇所を示します。変更されたノードを強調してください。
   • フローが正確になるよう、周辺のコード（呼び出し元、呼び出し先、設定の配線）も十分に読みます。差分や対象ファイルに存在しない関数や呼び出し関係を作り出さないでください。
6. コードレビューの回答を作成します。
   • 重大度の高い順に、具体的な指摘から始めます。
   • レビューした差分のファイル名と行番号を示します。
   • 好みの問題だけでなく、障害が起きる状況を説明します。
   • 対応可能な問題については、修正案または検証手順を提案します。
   • 細かな指摘は、正確性、パフォーマンス、互換性に関わるリスクと分けて記載します。
   • 差分外のコードに依存する主張は、ローカルのチェックアウトではなく PR ブランチで検証してください。 呼び出し箇所の網羅性、メソッドのシャドーイング／MRO、「ほかに呼び出し元がない」という主張、正確な行番号はベースコミットに依存します。異なるコミットのローカルリポジトリでは、確信を持った誤った指摘が生じる可能性があります（例：PR ブランチには存在しないメソッド衝突を、古い EagleVerifyInput を grep して主張する）。gh pr diff、gh api .../contents/<path>?ref=<pr-sha>、または git show <pr-sha>:<path> で確認してください。異なるコミットのチェックアウトしか利用できない場合は、断定せず、指摘に「ブランチでの確認が必要」と明記してください。
7. 問題が見つからなかった場合は、そのことを明確に伝えます。
   • 主な残存リスクと、確信を高めるために必要なテストまたはベンチマークの範囲を記載します。

コーパスに基づく SGLang レビューのヒューリスティクス

コーパス内の人間によるレビューのやり取りで頻繁に繰り返されているため、以下のリスクを優先してください。

• モデルと量子化の動作：モデル設定のずれ、トークナイザーに関する前提、FP8／INT4 量子化の経路、MoE のルーティング、投機的デコーディング、アテンションバックエンドとの互換性。
• スタイルより正確性を優先：エッジケース、アサーションの失敗、予期しないエラーコード、形状／データ型の不一致、状態のクリーンアップ、気づきにくい動作変更。
• GPU とカーネルの経路：CUDA グラフのキャプチャ、Triton／CUDA カーネル、FlashInfer と FlashAttention の動作、起動条件、SM との互換性、フォールバックの動作。
• サーバー API との互換性：OpenAI 互換のリクエスト／レスポンス形式、server_args、CLI のデフォルト、エンドポイントの動作、ストリーミング、後方互換性。
• メモリとキャッシュのライフサイクル：KV キャッシュの計上、radix キャッシュのリセット、メモリプールの所有権、エビクション、断片化、OOM の動作。
• 分散ランタイム：TP／DP／PP／EP のランクに関する前提、NCCL の経路、同期、ワーカーの状態、競合状態、ハングのリスク。
• テストとベンチマーク：動作が変わる場合は対象を絞ったテストを求め、パフォーマンスをうたう変更やホットパスに触れる変更には、ワークロード、モデル、ハードウェア、精度、フレームワークのコミット、変更前後のコマンドを含むベンチマークの根拠を求めてください。
• ドキュメントとサンプル：ドキュメントを CLI のデフォルト、エンドポイント名、モデルのサポート状況、インストール手順、バージョン固有の動作に合わせてください。
• 可観測性：運用時の動作が変わる場合は、メトリクス、ログ、警告レベル、トレーサビリティ、エラーメッセージをレビューしてください。

PR の理解図

指摘事項の前に、レビュー担当者が PR の要点をひと目で理解できるよう、理解ブロックを出力してください。次の 2 つのパートで構成します。

1. 変更の概要（2～6 個の箇条書き）。 平易な言葉で、変更対象のサブシステム、PR が変更する中核的な仕組み、実際の動作変更を担う 1～2 行を説明します。エントリーポイントと変更対象ファイルを明記してください。
2. PR に関連する実行経路の Mermaid フローチャート。変更されたステップを視覚的に示し、各図の直後に、その詳細を説明する文章を記載してください。

図のルール：

• ```mermaid のコードフェンスと flowchart TD（または短い線形フローの場合は LR）を使ってください。GitHub の PR コメントやほとんどの Markdown ビューアーでレンダリングされます。
• ファイルツリーではなく、実行時の処理経路をモデル化してください。エントリーポイント → 制御フロー（分岐／ループ）→ PR が追加または変更する呼び出しとデータ変換 → 戻り値／副作用、の順に示します。リクエスト／テンソル／バッチが変更されたコードをどのように流れるか、読み手が把握できるようにしてください。
• PR で追加または変更されたノードには changed クラスを付け、変更されていない文脈ノードはそのままにして、旧動作と新動作が明確に分かるようにしてください。凡例ノードは必ず含めてください。
• 分岐によって動作が変わる場合は、条件や受け渡されるデータをエッジに注記してください（-->|fp8 path|、-->|cache miss| など）。
• ノード数はおよそ 6～14 個にしてください。PR が互いに独立したコード経路にまたがる場合は、経路ごとに小さなフローチャートを 別々の ```mermaid ブロックで出力し、縦に並べてください（横並びにはしないでください）。2 つの subgraph を 1 つのブロックに詰め込まないでください。横並びに配置され、各図が読めないほど小さくなるためです。制御フローに変更のない純粋なリファクタリングの場合は、旧版と新版を 2 つの短い分岐で示し、その旨を説明してください。
• 上から下に伸びて読みやすい flowchart TD を優先してください。LR は、本当に短い線形の流れに限って使ってください。
• 各図の直後に、その図の簡潔な解説を追加してください。エントリーポイント、各分岐／条件の意味、PR が変更したノードとその理由を説明します。図は全体像を示し、解説はレビュー担当者が読む内容です。説明なしに図だけを置かないでください。
• 図のノードラベルには、差分と照合できる実際のシンボル（function、ClassName.method、file:line）を記載してください。エッジを捏造しないでください。
• 構文上の安全性を確保し、最新の CLI だけでなく、GitHub に固定されている Mermaid でもブロックがレンダリングされるようにしてください。()、,、:、=、>、&、/ を含むノードまたはエッジのラベルは、二重引用符で囲んでください。例：C["down_proj(x, skip_all_reduce=rs)"]、B -->|"id < 0 or id >= vocab"| N。ラベル内の改行には実際の \n ではなく <br/> を使ってください。末尾には classDef changed stroke-dasharray:5 5,stroke-width:2px; を 1 回記載してください。迷った場合は、すべてのラベルを引用符で囲むのが安全です。

適宜書き換えるスケルトン（ラベルを PR の実際のシンボルやパスに置き換えてください）：

flowchart TD
    A["Entry: forward / handler / scheduler step"] --> B{"Branch the PR changes"}
    B -->|"new condition"| C["New/changed call or transform"]:::changed
    B -->|"existing path"| D["Unchanged path"]
    C --> E["Downstream effect: KV write / output / metric"]:::changed
    D --> E
    E --> F["Return / response / side effect"]

    L["Legend: dashed border = added or modified by this PR"]:::changed
    classDef changed stroke-dasharray:5 5,stroke-width:2px;

この理解ブロックを回答の最初に置き、その後に指摘事項を記載してください。簡潔にまとめてください。これはレビューそのものではなく、読み手に全体像を示すものです。

レビューのスタイル

人間による SGLang のレビュー習慣に合わせてください。

• 簡潔かつ具体的にしてください。
• 意図が曖昧な場合は、質問する形を優先してください。
• 本番環境に影響する動作変更を明示してください。
• 根拠としてコーパスを使う場合は、過去の例をでっち上げず、コーパスを照会してください。
• 現在の差分を読む代わりに過去の例を使うのではなく、レビュー時の観点やリスク領域を把握するためにコーパスの例を使ってください。
• 多言語のコメントはそのまま残してください。関連するスレッドが中国語など別の言語の場合は、根拠として原文をそのまま使い、ユーザーから別の指定がなければ、ユーザーの言語で回答してください。
• 過去のコメントを盲目的に踏襲しないでください。過去のパッチの型に現在のパッチを無理に当てはめるのではなく、コーパスの例を参考にして現在のレビューをより的確にしてください。

出力契約

通常のレビューでは、次の内容を返します。

• 最初に PR の理解ブロックを記載します。変更の概要と、変更されたノードを明示した Mermaid の実行フローチャートを含めます。各図の直後には、その詳細を文章で説明します（PR 理解図を参照）。
• 次に、短い過去のレビューの統合結果を記載します。網羅的なコーパス調査（ワークフローのステップ 3）の対象範囲（scanned / matched / PRs）を示し、このサブシステムに関する繰り返し見られるレビュー意見を要約します。以降の指摘はこの調査結果に基づきます。
• 次に、重要度の高い順に、ファイル／行番号の参照を付けた指摘を記載します。該当する先例がある場合は、その統合結果に明示的に基づいてください。
• 未解決の質問または前提事項。
• テストまたはベンチマークの不足。
• 指摘の後にのみ、短い要約を記載します。

ユーザーが PR を開く前のレビュー準備では、次の内容を返します。

• PR の理解ブロック（変更の概要と Mermaid の実行フローチャート）
• レビュアーが懸念しそうな点
• 不足しているテストまたはベンチマークの根拠
• 推奨するパッチの整理
• 使用したコーパス検索クエリ
• 該当する場合は、関連スキルから得た根拠

コーパスに基づく説明では、検索語句を含め、コメント本文を長々と転載せずに、該当するレビューの傾向を要約してください。

パスのエイリアスとコーパスのカットオフ

コーパスは現在のパス変更より前のものです。変更対象のパスを検索する場合は、過去の担当パスも含めてください。

現在の差分対象	追加の --path クエリ
python/sglang/srt/arg_groups/**	python/sglang/srt/server_args.py
python/sglang/kernels/**	python/sglang/jit_kernel/, sgl-kernel/
.agents/skills/**	.claude/skills/

コレクターには増分／再開モードがなく、3 つの出力ファイルをすべて上書きします。--end-year の既定値は 2025 です。将来、全件を再クロールする場合は 2026 を明示的に指定してください。この更新では、2026-07-27 のコーパスを再クロールも再ラベル付けもしていません。 保存済みの収集ポリシーには、ログイン除外パターンが記録されるようになりました。