sglang: Skill for Claude Code

Cookbook Review PR

Fetch the diff, run the checklist, report what you find. The cookbook is config-driven: shared engines (_deployment.jsx, _playground.jsx) with NO model-specific code; each model is a data config (+ optional benchmarks) under src/snippets/configs/<vendor>/ plus an MDX page. This checklist targets that layout. Field-schema detail lives in .claude/skills/cookbook-add-model/references/authoring-reference.md — defer to it rather than restating.

Usage

/cookbook-review-pr <PR number>

Steps

1. gh pr view <N> --repo sgl-project/sglang --json title,body,files,author,baseRefName,headRefName,commits,reviews
2. gh pr diff <N> --repo sgl-project/sglang
3. gh pr list --repo sgl-project/sglang --state open --search "<model name>" (duplicate check)
4. Run every checklist item against the diff.
5. Output per-file verdicts + overall recommendation.

Checklist

1. File hygiene

• A cookbook PR should only touch: docs/src/snippets/configs/<vendor>/*.jsx (config + benchmarks), docs/cookbook/**/*.mdx, docs/docs.json, docs/cookbook/<category>/intro.mdx (vendor card), docs/cards/logos/<vendor>.png (new vendor only). Flag stray files (settings.local.json, lockfiles, IDE configs).
• Pages must be .mdx, not .md. Files end with a trailing newline. Check commit history for unrelated commits accidentally included.
• Engines untouched: _deployment.jsx / _playground.jsx should NOT change in a model-add PR (adding a model is data-only). Engine edits = a separate axis/feature PR (see cookbook-add-model/references/engine-axis.md); review them against that checklist.

2. Config quality (the per-model config)

• Single export const config = { ... } literal — no function calls, spreads, fragment refs, or IIFE (Mintlify re-evals at hydration → ReferenceError).
• No !(x in y) anywhere (Mintlify AST walker crashes) — use obj.key === undefined.
• supportedHardware ⊆ HARDWARE_CATALOG (in _deployment.jsx) ∪ config.hardware. A model-specific GPU the shared catalog lacks must be declared in config.hardware ({id,label,vram,vendor}), not added to the engine catalog — unless the platform is genuinely shared, which is an engine change the PR body has to argue (and the cookbook-add-model hardware table moves with it). A new catalog entry is inert for other pages: each filters the catalog by its own supportedHardware.
• placeholders declares every {{KEY}} used in curl or any cell.
• modelNames covers every cell (by hw|variant|quant triple or variant|quant pair).
• strategies count matches the page's operating points — 1 recipe → a single balanced; 2 → low-latency + high-throughput; 3 → the full trio. Tiers apply per (hw × variant × quant) combination: a single-recipe combination must park under its semantically honest tier (clear slant → that tier, e.g. a workstation card under low-latency; no slant → balanced, e.g. a CPU platform) — flag a no-slant recipe parked under low-latency/high-throughput. Mixed unions like [low-latency, balanced, high-throughput] with per-selection greying are fine. Also flag model-specific ids (e.g. mtp), and flag an INVERTED speculative mapping — the deterministic default is MTP/spec-decoding ON → low-latency, OFF → high-throughput (at saturation the draft+verify overhead outweighs the speedup); the reverse needs an explicit maintainer-confirmed justification in the PR. The MDX strategy bullets describe serving semantics in the DSv4 style (single-user chat / typical multi-user / batch jobs), not internal toggles.
• dockerImages covers the hw ids that have cells (else users hit the :dev fallback); a hw|quant key (resolved before the plain hw) is valid when one quant on a shared GPU needs a different image (e.g. an FP4 dev build) — don't flag those.
• multiNodeHints present ONLY for hw whose fabric needs manual NIC env (e.g. gb200 NVL72) — NOT every multi-N hw (standard-IB DeepEP / Marlin multi-node don't need it). Hints render above BOTH run modes, so flag one that reads as docker-only ("add these docker run flags") — docker run flags belong in the hardware entry's multiNodeDockerFlags, which the engine emits into the Docker command itself.
• github.cookbookModel is set to the model's HF id (<hf-org>/<model-slug>). The issue template's model field is a free-form input prefilled from this value; if the config omits the github block, the engine falls back to deepseek-ai/deepseek-v4 and the page's submissions get mislabeled.
• playgroundFeatures is opt-OUT: the general axes ship on every cookbook by default (attention TP/CP/DP-Attn, moe backend+EP for MoE models, parsers, speculative, pdDisagg, hicache) — flag a missing general axis unless the model genuinely cannot use it. Model-specific axes only where applicable (MegaMoE backend + megamoeQuant only on Blackwell MoE, gated by requiresHw; hisparse only DSA-style). Knobs that are meaningless for a subset of variants/hw are disabled with a reason, not silently live (e.g. MoE knobs greyed on dense variants). No empty/stub axes.
• No leftover __TOKEN__ — the config was stamped from the template and every placeholder is filled (grep -rn '__[A-Z_]*__' on the new config/benchmarks/MDX returns nothing).
• All-hardware considered: every supportedHardware id (from the catalog or config.hardware) has ≥1 cell OR is a deliberate greyed "coming soon"; AMD was pruned or kept on purpose (not a leftover template family).