Agent skill

Write Sglang Test

by sgl-project in sgl-project/sglang

Guide for writing SGLang CI/UT tests. An agent skill from sgl-project/sglang.

Apache-2.0Auto-check passedTesting & QA

Install Write Sglang Test

skills CLI
$ npx skills add sgl-project/sglang --skill write-sglang-test -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install sgl-project/sglang write-sglang-test --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/sgl-project/sglang.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/write-sglang-test .claude/skills/write-sglang-test && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
write-sglang-test
GitHub stars
37k
Used in
2 other repos
Token cost
~5.2k tokens
SKILL.md length
1,400 words
Files
1
Skills in repo
32
Repo updated
First seen
Licence
Apache-2.0

At a glance

Guide for writing SGLang CI/UT tests. An agent skill from sgl-project/sglang.

  • Works in 5 steps: Always use CustomTestCase — never raw… → tearDownClass must shut the server down… → Place non-kernel tests in… → …
  • Creating new tests
  • SKILL.md covers Core Rules, Model & Backend Selection, Test File Templates and Server Fixture Reuse, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Write Sglang Test is an agent skill from sgl-project/sglang. Guide for writing SGLang CI/UT tests. Covers CustomTestCase, CI registration, server fixtures, model selection, mock testing, and test placement. Always read test/README.md for the full CI layout, how to run tests, and extra tips. Use when creating new tests, adding CI test cases, writing unit tests, or when the user asks to add tests for SGLang features.

Its SKILL.md is about 5.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Unit testing and Test generation. It works with SGLang. The repository describes itself as: SGLang is a high-performance serving framework for large language models and multimodal models. The licence is Apache-2.0.

When your agent uses it

  • Creating new tests
  • Adding CI test cases
  • Writing unit tests
  • The user asks to add tests for SGLang features

Example prompts

  • “/write-sglang-test”

Requirements

  • Python 3

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Always use CustomTestCase — never raw unittest.TestCase. It ensures tearDownClass runs even when setUpClass fails, preventing resource…
  2. tearDownClass must shut the server down gracefully — call terminate_and_kill_process_tree(cls.process), never a bare kill_process_tree…
  3. Place non-kernel tests in test/registered/// — is unit, e2e, accuracy, perf, or stress; kernel tests use…
  4. Reuse server fixtures — inherit from DefaultServerBase or write setUpClass/tearDownClass with popen_launch_server
  5. Mock boundaries, not SGLang behavior — mock slow or external dependencies only when the assertion still checks an observable result, state…

What it can do on your machine

Read from SKILL.md and the folder at commit f620d73. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are python and bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Write Sglang Test loads about 5.2k tokens when it runs. Until then it costs about 94 tokens; SKILL.md has 1,400 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~94
When it runs · the whole SKILL.md, loaded when a task matches
~5.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from sgl-project/sglang at commit f620d73, republished under its Apache-2.0 licence (© sgl-project). 1,400 words, ~5,164 tokens.

Download SKILL.mdSave it as .claude/skills/write-sglang-test/SKILL.md (or your agent's skills folder).
name
write-sglang-test
description
Guide for writing SGLang CI/UT tests. Covers CustomTestCase, CI registration, server fixtures, model selection, mock testing, and test placement. Always read test/README.md for the full CI layout, how to run tests, and extra tips. Use when creating new tests, adding CI test cases, writing unit tests, or when the user asks to add tests for SGLang features.

Writing SGLang CI / UT Tests

Apply kernel-organization for the public operator namespace, logical grouping, lazy registry metadata, and test placement. The implementation tutorial below does not replace that API contract.

This skill covers how to write and register tests. For CI pipeline internals (stage ordering, fail-fast, gating, partitioning, debugging CI failures), see the CI workflow guide. Whether a case is worth adding at all is decided by unit-test-admission — read it before writing the case, not after.

Core Rules

  1. Always use CustomTestCase — never raw unittest.TestCase. It ensures tearDownClass runs even when setUpClass fails, preventing resource leaks in CI.
  2. tearDownClass must shut the server down gracefully — call terminate_and_kill_process_tree(cls.process), never a bare kill_process_tree. SIGKILL alone skips the server's userspace cleanup and leaves its GPU memory charged to the dead process; the next class then OOMs while loading weights. Keep it defensive too: hasattr/null checks before accessing resources (e.g. cls.process) that setUpClass may not have finished allocating.
  3. Place non-kernel tests in test/registered/<kind>/<subsystem>/ — <kind> is unit, e2e, accuracy, perf, or stress; kernel tests use test/registered/kernels/{ops,benchmark}/<group>/; hardware belongs in registrations, not directory names
  4. Reuse server fixtures — inherit from DefaultServerBase or write setUpClass/tearDownClass with popen_launch_server
  5. Mock boundaries, not SGLang behavior — mock slow or external dependencies only when the assertion still checks an observable result, state transition, or error. A test whose evidence is only assert_called* mirrors its mock and is not admissible. Launch a real server only when inference results or lifecycle behavior are the contract under test.

Existing files are not the reference. About 290 test files still call the bare kill_process_tree(cls.process.pid), against 43 on the current helper. They predate rule 2 and are being migrated, so grepping the repo for a teardown pattern finds the wrong one roughly seven times out of eight. The same goes for register_cuda_ci(suite=...): four files still pass it, all of them under test/registered/stress/.

python
# Bad:  kill_process_tree(cls.process.pid)           # SIGKILL only; GPU memory lingers
# Good: terminate_and_kill_process_tree(cls.process)

# Bad:  register_cuda_ci(est_time=80, suite="base-b-test-1-gpu-small")
# Good: register_cuda_ci(est_time=80, stage="base-b", runner_config="1-gpu-small")

JIT kernel notes:

  • If the task is adding or updating code under python/sglang/kernels/jit/, prefer the add-jit-kernel skill first.
  • JIT kernel correctness tests use test/registered/kernels/ops/<group>/test_*.py.
  • JIT kernel benchmarks use test/registered/kernels/benchmark/<group>/bench_*.py.
  • Those files are executed by test/run_suite.py through dedicated kernel suites (base-b-kernel-*); a register_*_ci(...) call placed under python/sglang/ is rejected by the check-no-registered-tests-in-package pre-commit hook.

Model & Backend Selection

ScenarioModelCI RegistrationSuite
Unit tests (no server / engine launch)Noneregister_cpu_cibase-a-test-cpu
Common / backend-independent (middleware, abort, routing, config, arg parsing)DEFAULT_SMALL_MODEL_NAME_FOR_TEST (1B)register_cuda_ci onlybase-b-test-1-gpu-small
Model-agnostic functionality (sampling, session, OpenAI API features)DEFAULT_SMALL_MODEL_NAME_FOR_TEST (1B)register_cuda_ci (+ AMD if relevant)base-b-test-1-gpu-small
General performance (single node, no spec/DP/parallelism)DEFAULT_MODEL_NAME_FOR_TEST (8B)register_cuda_cibase-b-test-1-gpu-large
Bigger features (spec, DP, TP, disaggregation)Case by caseCase by caseSee Choosing a Suite below

Key principle for E2E tests: Do NOT add register_amd_ci unless the test specifically exercises AMD/ROCm code paths. Common E2E tests just need any GPU to run — duplicating across backends wastes CI time with no extra coverage.

All model constants

Defined in python/sglang/test/test_utils.py:

ConstantModelWhen to use
DEFAULT_SMALL_MODEL_NAME_FOR_TESTLlama-3.2-1B-InstructCommon features, model-agnostic tests
DEFAULT_SMALL_MODEL_NAME_FOR_TEST_BASELlama-3.2-1BBase (non-instruct) model tests
DEFAULT_MODEL_NAME_FOR_TESTLlama-3.1-8B-InstructGeneral performance (single node)
DEFAULT_MOE_MODEL_NAME_FOR_TESTMixtral-8x7B-InstructMoE-specific tests
DEFAULT_SMALL_EMBEDDING_MODEL_NAME_FOR_TEST—Embedding tests
DEFAULT_SMALL_VLM_MODEL_NAME_FOR_TEST—Vision-language tests
Naming Conventions

A per-commit suite name is generated from registration metadata as {stage}-test-{runner_config} — you don't hand-write it:

  • stage — the CI stage (e.g. base-b, base-b-kernel-unit, base-c).
  • runner_config — a runner-pool key from scripts/ci/runner_configs.yml, which maps it to the physical runner label (so 1-gpu-large runs on 1-gpu-h100). AMD/NPU use their own keys (e.g. amd).
  • Suite — register_cuda_ci(stage="base-b", runner_config="1-gpu-small") → base-b-test-1-gpu-small, the name you pass to run_suite.py --suite. The -test- is just the connector; never put it in register_*_ci.

CUDA nightly uses the same shape with stage="nightly" (e.g. stage="nightly", runner_config="1-gpu-large" → nightly-test-1-gpu-large) and no nightly=True — the stage name carries the cadence, and setting the flag makes the test silently never run. Legacy single-string suite= is left only for stress and some AMD/CPU/NPU pools.

All CI Suites

Do not work from a list copied into this file; it goes stale silently. Read the current one:

bash
grep -n "_SUITES = {" test/run_suite.py   # PER_COMMIT_SUITES, NIGHTLY_SUITES, OTHER_SUITES
cat scripts/ci/runner_configs.yml         # runner_config -> physical runner label

scripts/ci/runner_configs.yml calls itself the single source of truth for the runner_config field, and run_suite.py is what actually dispatches, so those two files settle any disagreement with prose anywhere else.

Nightly suites live in NIGHTLY_SUITES and run via nightly-test-nvidia.yml, nightly-test-amd.yml, and nightly-test-npu.yml, not pr-test.yml. CUDA nightly is named nightly-test-{runner_config} — one suite per machine type, holding everything that runs nightly on it, with auto_partition splitting the work. There is no per-purpose split; kernel, eval, perf, and precision all share their machine's suite.

Note: Multimodal diffusion uses python/sglang/multimodal_gen/test/run_suite.py, not test/run_suite.py.

Choosing a Suite

Use the lightest suite that meets your test's needs:

  • No GPU required → base-a-test-cpu
  • Most small GPU tests → base-b-test-1-gpu-small (default choice)
  • Need H100 memory or Hopper features → base-b-test-1-gpu-large
  • JIT kernel correctness → base-b-kernel-unit-test-1-gpu-large
  • JIT kernel correctness for B200 / SM100 paths → base-b-kernel-unit-test-4-gpu-b200
  • JIT kernel benchmarks → base-b-kernel-benchmark-test-1-gpu-large
  • Multi-GPU → only when the test actually needs multiple GPUs

Test File Templates

Show full SKILL.md (611 more words)Show less
Unit Tests (no server / engine launch)

See test/registered/unit/README.md for quick-start and rules. Unit tests live in test/registered/unit/, mirroring python/sglang/srt/:

python
"""Unit tests for srt/<module>"""

import unittest
from unittest.mock import MagicMock, patch

from sglang.srt.<module> import TargetClass
from sglang.test.ci.ci_register import register_cpu_ci
from sglang.test.test_utils import CustomTestCase

register_cpu_ci(est_time=5, suite="base-a-test-cpu")
# Unit tests are CPU-only. GPU operator tests belong under `kernel/`.

class TestTargetClass(CustomTestCase):
    def test_basic_behavior(self):
        obj = TargetClass(...)
        self.assertEqual(obj.method(), expected)

    @patch("sglang.srt.<module>.some_dependency")
    def test_with_mock(self, mock_dep):
        mock_dep.return_value = MagicMock()
        # test logic with dependency mocked
        ...


if __name__ == "__main__":
    unittest.main()

Use unittest.mock.patch / MagicMock only at dependency boundaries. Assert the resulting value, state, protocol output, or error—not merely that the mock was called. If the module transitively imports GPU-only packages (e.g. sgl_kernel), they can be stubbed so the test runs on CPU CI. Do not modify sys.modules at module level—use patch.dict (as a class decorator or with start/stop) to ensure cleanup and avoid cross-test pollution. See test/registered/unit/README.md for details and examples.

Quality bar — test real logic (validation boundaries, state transitions, error paths, branching, etc.). Skip tests that just verify Python itself works (e.g., "does calling an abstract method raise NotImplementedError?", "does a dataclass store the field I assigned?"). Consolidate repetitive patterns into parameterized tests. No production code changes in test PRs.

E2E test (small model, server needed)
python
import unittest

import requests

from sglang.test.ci.ci_register import register_cuda_ci
from sglang.test.test_utils import (
    DEFAULT_SMALL_MODEL_NAME_FOR_TEST,
    DEFAULT_TIMEOUT_FOR_SERVER_LAUNCH,
    DEFAULT_URL_FOR_TEST,
    CustomTestCase,
    popen_launch_server,
    terminate_and_kill_process_tree,
)

register_cuda_ci(est_time=60, stage="base-b", runner_config="1-gpu-small")


class TestMyFeature(CustomTestCase):
    @classmethod
    def setUpClass(cls):
        cls.model = DEFAULT_SMALL_MODEL_NAME_FOR_TEST
        cls.base_url = DEFAULT_URL_FOR_TEST
        cls.process = popen_launch_server(
            cls.model,
            cls.base_url,
            timeout=DEFAULT_TIMEOUT_FOR_SERVER_LAUNCH,
            other_args=["--arg1", "value1"],  # feature-specific args
        )

    @classmethod
    def tearDownClass(cls):
        if hasattr(cls, "process") and cls.process:
            terminate_and_kill_process_tree(cls.process)

    def test_basic_functionality(self):
        response = requests.post(
            self.base_url + "/generate",
            json={"text": "Hello", "sampling_params": {"max_new_tokens": 32}},
        )
        self.assertEqual(response.status_code, 200)


if __name__ == "__main__":
    unittest.main(verbosity=3)

Copy the tearDownClass above verbatim. Most existing E2E files still show the bare kill_process_tree; that form is being migrated out and must not be reproduced.

E2E test (8B model, server needed, performance)
python
import time
import unittest

import requests

from sglang.test.ci.ci_register import register_cuda_ci
from sglang.test.test_utils import (
    DEFAULT_MODEL_NAME_FOR_TEST,
    DEFAULT_TIMEOUT_FOR_SERVER_LAUNCH,
    DEFAULT_URL_FOR_TEST,
    CustomTestCase,
    popen_launch_server,
    terminate_and_kill_process_tree,
)

register_cuda_ci(est_time=300, stage="base-b", runner_config="1-gpu-large")


class TestMyFeaturePerf(CustomTestCase):
    @classmethod
    def setUpClass(cls):
        cls.model = DEFAULT_MODEL_NAME_FOR_TEST
        cls.base_url = DEFAULT_URL_FOR_TEST
        cls.process = popen_launch_server(
            cls.model,
            cls.base_url,
            timeout=DEFAULT_TIMEOUT_FOR_SERVER_LAUNCH,
        )

    @classmethod
    def tearDownClass(cls):
        if hasattr(cls, "process") and cls.process:
            terminate_and_kill_process_tree(cls.process)

    def test_latency(self):
        start = time.perf_counter()
        response = requests.post(
            self.base_url + "/generate",
            json={"text": "Hello", "sampling_params": {"max_new_tokens": 128}},
        )
        elapsed = time.perf_counter() - start
        self.assertEqual(response.status_code, 200)
        self.assertLess(elapsed, 5.0, "Latency exceeded threshold")


if __name__ == "__main__":
    unittest.main(verbosity=3)

Server Fixture Reuse

For tests that only need a standard server, inherit from DefaultServerBase and override class attributes:

python
from sglang.test.server_fixtures.default_fixture import DefaultServerBase

class TestMyFeature(DefaultServerBase):
    model = DEFAULT_SMALL_MODEL_NAME_FOR_TEST
    other_args = ["--enable-my-feature"]

    def test_something(self):
        ...

Available fixtures in python/sglang/test/server_fixtures/:

FixtureUse case
DefaultServerBaseStandard single-server tests
EagleServerBaseEAGLE speculative decoding
PDDisaggregationServerBaseDisaggregated prefill/decode
MMMUServerBaseMultimodal VLM tests

CI Registration

Every CI-discovered test file must call a registration function at module level:

python
from sglang.test.ci.ci_register import (
    register_cuda_ci,
    register_amd_ci,
    register_cpu_ci,
    register_npu_ci,
)

# Per-commit test (small 1-gpu, runs on 5090)
register_cuda_ci(est_time=80, stage="base-b", runner_config="1-gpu-small")

# Per-commit test (large 1-gpu, runs on H100)
register_cuda_ci(est_time=120, stage="base-b", runner_config="1-gpu-large")

# Nightly-only test (same shape as per-commit, stage is just "nightly")
register_cuda_ci(est_time=200, stage="nightly", runner_config="1-gpu-large")

# Multi-backend test (only when testing backend-specific code paths)
register_cuda_ci(est_time=80, stage="base-a", runner_config="1-gpu-small")
register_amd_ci(est_time=120, suite="stage-a-test-1-gpu-small-amd")
register_npu_ci(est_time=400, suite="nightly-8-npu-a3", nightly=True)

# Temporarily disabled test
register_cuda_ci(
    est_time=80, stage="base-b", runner_config="1-gpu-small", disabled="flaky - see #12345"
)

Parameters:

  • est_time: estimated runtime in seconds (used for CI partitioning)
  • stage + runner_config: the canonical pair for CUDA; the suite name is generated from them (see Naming Conventions)
  • suite: legacy single-string form. Only stress and some AMD/CPU/NPU pools still take it; register_cpu_ci(suite="base-a-test-cpu") is correct and is not being migrated
  • nightly=True: legacy cadence flag, for non-CUDA nightly suites only. CUDA nightly uses stage="nightly" and must leave this unset
  • disabled="reason": temporarily disable with explanation

Key principle: Only add register_amd_ci / register_npu_ci when the test exercises backend-specific code paths. Common E2E tests just need register_cuda_ci — duplicating across backends wastes CI time.

JIT Kernel Registration

run_suite.py discovers every test/registered/**/*.py, JIT kernel files included. They are ordinary registered tests; only their stage differs:

python
from sglang.test.ci.ci_register import register_cuda_ci

# Correctness tests in test/registered/kernels/ops/<group>/
register_cuda_ci(est_time=30, stage="base-b-kernel-unit", runner_config="1-gpu-large")
register_cuda_ci(est_time=30, stage="base-b-kernel-unit", runner_config="4-gpu-b200")
register_cuda_ci(est_time=120, stage="base-b-kernel-unit", runner_config="8-gpu-h200")

# Benchmarks in test/registered/kernels/benchmark/<group>/
register_cuda_ci(est_time=6, stage="base-b-kernel-benchmark", runner_config="1-gpu-large")

# Optional nightly registration — same form, stage is just "nightly"
register_cuda_ci(est_time=120, stage="nightly", runner_config="1-gpu-large")
register_cuda_ci(est_time=120, stage="nightly", runner_config="8-gpu-h200")

Every call generates a suite named {stage}-test-{runner_config}, e.g. base-b-kernel-unit-test-1-gpu-large and nightly-test-1-gpu-large. Keep est_time, stage, runner_config, and suite as literal values — run_suite.py collects them by AST parsing.


Test Placement

test/
├── registered/          # CI tests (auto-discovered by run_suite.py)
│   ├── unit/<subsystem>/      # CPU-only; no server or model weights
│   ├── kernel/<group>/        # accelerator operator correctness/benchmarks
│   ├── e2e/<subsystem>/       # engine/server integration
│   ├── accuracy/<family>/     # scheduled eval floors
│   ├── perf/<family>/         # scheduled latency/throughput contracts
│   └── stress/<subsystem>/    # stress/weekly coverage
├── manual/              # Non-CI: debugging, one-off, manual verification
└── run_suite.py         # CI runner (globs test/registered/**/*.py; nothing outside it)

python/sglang/kernels/jit/   # implementation + test-only helpers, never registered tests

A register_*_ci(...) under python/sglang/ is rejected by the check-no-registered-tests-in-package pre-commit hook.

Decision rule (see also test/registered/README.md):

  • CPU component logic, no server → registered/unit/<subsystem>/
  • JIT kernel correctness → registered/kernels/ops/<group>/
  • JIT kernel benchmarks → registered/kernels/benchmark/<group>/
  • Other accelerator operator correctness → registered/kernels/ops/<group>/
  • Server needed → registered/e2e/<subsystem>/
  • Eval floor / performance contract → registered/{accuracy,perf}/<family>/
  • Local debugging → manual/

Eval Accuracy Mixins

Design philosophy: Most test files don't care about eval logic — they only need a "does this feature break model output quality?" sanity check. The mixin pattern separates what to test (threshold) from how to test (run_eval, assertions, CI summary). Test classes declare thresholds as class attributes; the mixin provides the test_* method. Override when you need extra assertions (e.g. EAGLE accept length).

Available mixins in python/sglang/test/kits/eval_accuracy_kit.py: MMLUMixin, HumanEvalMixin, MGSMEnMixin, GSM8KMixin. Can be combined freely. Read the source for attrs and defaults.

python
class TestMyFeature(CustomTestCase, MMLUMixin):
    mmlu_score_threshold = 0.65
    mmlu_num_examples = 64
    mmlu_num_threads = 32
    # test_mmlu is inherited — no code needed

Key Utilities

python
from sglang.test.test_utils import (
    CustomTestCase,              # base class with retry logic
    popen_launch_server,         # launch server subprocess
    terminate_and_kill_process_tree,    # SIGTERM, then SIGKILL, then wait for
                                        # the GPU memory to come back
    DEFAULT_URL_FOR_TEST,        # auto-configured base URL
    DEFAULT_TIMEOUT_FOR_SERVER_LAUNCH,  # 600s default
    run_bench_serving,           # benchmark helper (launch + bench)
)

Checklist

Before submitting a test:

  • Inherits from CustomTestCase (not unittest.TestCase)
  • Has register_*_ci(...) call at module level
  • Placed in test/registered/<kind>/<subsystem>/
  • JIT kernel work: correctness tests live in test/registered/kernels/ops/<group>/, benchmarks live in test/registered/kernels/benchmark/<group>/, and only test-only helpers stay under python/sglang/kernels/jit/
  • Backend-independent tests: register_cuda_ci only + smallest model
  • Logic that doesn't need a server / engine launch → unit test in registered/unit/ (see Unit Tests section)
  • tearDownClass is defensive — uses hasattr/null checks before accessing resources that may not have been allocated
  • Every case answers "what future diff turns this red?" — see unit-test-admission
  • est_time is reasonable (measure locally)

Run these against the new file and paste the output rather than self-attesting:

bash
f=<your new test file>
grep -n "kill_process_tree" $f          # every hit must be terminate_and_kill_process_tree
grep -n "register_.*_ci(" $f            # CUDA: stage= + runner_config=, never suite=
grep -n "CustomTestCase\|unittest.main" $f   # both must appear

© sgl-project, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/write-sglang-test of sgl-project/sglang.

Open the folder on GitHubat commit f620d73

Used in 2 other repositories

We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 2 other GitHub owners. This page covers the copy in sgl-project/sglang, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Write Sglang Test next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Write Sglang Test compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Write Sglang Test this skillsgl-project/sglang37k2 repos~5.2kAutomated safety check: PassApache-2.0
Adk Verify Snippetsgoogle/adk-python22k—~1.4kAutomated safety check: PassApache-2.0
Hermetic Python Unit TestsdimensionalOS/dimos4.6k—~1.4kAutomated safety check: PassCustom licence
OpenROAD Module Test AdderThe-OpenROAD-Project/OpenROAD3.2k—~1.8kAutomated safety check: PassBSD-3-Clause
Concept Page Test Writerleonardomso/33-js-concepts67k—~5.5kAutomated safety check: PassMIT
ScottPlot Test RunnerScottPlot/ScottPlot6.8k—~308Automated safety check: PassMIT

Similar skills

  • Adk Verify Snippets

    google/adk-python

    Official

    Checks that every Python code block in a Markdown file actually compiles and runs, by extracting each block to a temporary file, executing it in an isolated subprocess, and writing a pass/fail…

    22k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed
  • Hermetic Python Unit Tests

    dimensionalOS/dimos

    Rules for writing, fixing and reviewing pytest unit tests that are hermetic: behavior-focused, deterministic, isolated and cheap to run.

    4.6k GitHub stars~1.4k tokensUpdated today
    Testing & QAAuto-check passed
  • OpenROAD Module Test Adder

    The-OpenROAD-Project/OpenROAD

    Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel.

    3.2k GitHub stars~1.8k tokensUpdated today
    Testing & QAAuto-check passed
  • Concept Page Test Writer

    leonardomso/33-js-concepts

    Generates Vitest tests for every runnable code example on a JavaScript concept documentation page, following a four-phase extraction and conversion process.

    67k GitHub stars~5.5k tokensUpdated 28 days ago
    Testing & QAAuto-check passed
  • ScottPlot Test Runner

    ScottPlot/ScottPlot

    Run or add ScottPlot 5 tests. Use for unit-test and cookbook-test work; unless explicitly asked otherwise, restrict manual test execution to the Unit Tests…

    6.8k GitHub stars~308 tokensUpdated 1 mo ago
    Testing & QAAuto-check passed
  • Testing iOS Code

    bitwarden/ios

    Official

    Write tests, add test coverage, unit test, or add missing tests for Bitwarden iOS.

    696 GitHub stars~1.8k tokensUpdated today
    Testing & QAAuto-check passed

More from sgl-project/sglang

All 32 skills in this repo
  • Sglang Prod Incident Triage

    sgl-project/sglang

    Replay-first debug flow for SGLang serving problems. An agent skill from sgl-project/sglang.

    37k GitHub starsUsed in 3 repos~2.1k tokens
    Auto-check passed
  • LLM Torch Profiler Analysis

    sgl-project/sglang

    Unified LLM torch-profiler triage skill for sglang, vllm, TensorRT-LLM, and TokenSpeed.

    37k GitHub starsUsed in 2 repos~6.4k tokens
    Auto-check passed
  • Babysit PR To Pass CI

    sgl-project/sglang

    Start and persistently pursue a goal to babysit an SGLang pull request until selected GitHub Actions workflows pass on the latest PR head.

    37k GitHub starsUsed in 2 repos~3k tokens
    Auto-check passed
  • Compute Mamba Ratio

    sgl-project/sglang

    Compute the optimal --mamba-full-memory-ratio (or --max-mamba-cache-size pin) for a hybrid attention + linear-attention (Mamba / GDN / KDA) model's two serving memory pools, from the workload and…

    37k GitHub starsUsed in 2 repos~2.9k tokens
    Auto-check passed
  • Debug Distributed Hang

    sgl-project/sglang

    Debug hanging issues in SGLang distributed inference (TP/PP/DP/EP).

    37k GitHub starsUsed in 2 repos~2.4k tokens
    Auto-check passed
  • Env Var Conventions

    sgl-project/sglang

    Conventions for SGLang environment variables — where to define, how to access, how to name, and how to deprecate.

    37k GitHub starsUsed in 2 repos~2.9k tokens
    Auto-check passed

Works with

Categories

Questions about Write Sglang Test

What does Write Sglang Test do?

Guide for writing SGLang CI/UT tests. An agent skill from sgl-project/sglang. Write Sglang Test is an agent skill from sgl-project/sglang. Guide for writing SGLang CI/UT tests.

When should I use Write Sglang Test?

Write Sglang Test fits situations like: creating new tests; adding CI test cases; writing unit tests; the user asks to add tests for SGLang features.

How do I install Write Sglang Test in Claude Code?

Run `npx skills add sgl-project/sglang --skill write-sglang-test -a claude-code`. Or copy the skill folder (.agents/skills/write-sglang-test in sgl-project/sglang) into .claude/skills/write-sglang-test in your project. Claude Code loads it when a task matches its description.

How do I install Write Sglang Test in Codex?

Run `npx skills add sgl-project/sglang --skill write-sglang-test -a codex`. Or copy the skill folder (.agents/skills/write-sglang-test in sgl-project/sglang) into .agents/skills/write-sglang-test in your project. Codex loads it when a task matches its description.

Can I use Write Sglang Test in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add sgl-project/sglang --skill write-sglang-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/write-sglang-test, .gemini/skills/write-sglang-test, .github/skills/write-sglang-test and .opencode/skills/write-sglang-test in your project.

What does Write Sglang Test need to run?

SKILL.md names no scripts, command-line tools or credentials: Write Sglang Test is instructions for the agent only. Our summary lists: Python 3.

Does Write Sglang Test access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Write Sglang Test safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Write Sglang Test use?

Write Sglang Test is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Write Sglang Test use?

About 5.2k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Write Sglang Test?

Skills that share tags, products or a category with Write Sglang Test: Adk Verify Snippets (google/adk-python, 22k stars), Hermetic Python Unit Tests (dimensionalOS/dimos, 4.6k stars), OpenROAD Module Test Adder (The-OpenROAD-Project/OpenROAD, 3.2k stars) and Concept Page Test Writer (leonardomso/33-js-concepts, 67k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Write Sglang Test?

sgl-project (a GitHub organization) maintains it in sgl-project/sglang, which has 36,907 GitHub stars. The repository holds 32 skills in this directory. The repository was last updated on October 9, 2026.

Source: sgl-project/sglang on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.