large-class-style

Enforces frozen-code and init-helper conventions for SGLang's Scheduler, TokenizerManager, and ModelRunner classes.

33.0k|8.4k|Updated Jan 8, 2024
One-click install
npx skills add https://github.com/sgl-project/sglang --skill large-class-style
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: large-class-style
Source: https://github.com/sgl-project/sglang/tree/main/.claude/skills/large-class-style
Command: npx skills add https://github.com/sgl-project/sglang --skill large-class-style

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

SGLang's three largest classes (Scheduler, TokenizerManager, ModelRunner) tend to grow into unmaintainable god classes, and downstream forks are forced to copy entire __init__ bodies that rot against upstream. This Skill defines the code style rules that keep these classes as thin orchestrators and their constructors overridable.

Core Features & Use Cases

  • Frozen-code enforcement: Defines which files (e.g. model_runner.py) must remain orchestration-only, with explicit allowed statement types (construct, wire, delegate, coordinate) and rules for where domain logic must live instead.
  • __init__ orchestration style: Prescribes splitting constructors into init_<thing> / maybe_init_<thing> helpers so subclasses and downstream forks can override exactly one concern.
  • Coupling guidance: Requires passing narrow keyword arguments and returning frozen structs instead of passing or mutating the god object.
  • Use Case: When modifying Scheduler, TokenizerManager, or ModelRunner — or reviewing a PR that touches them — apply these rules to decide whether new logic belongs inline, in an init_* helper, or in a new collaborator module.

Quick Start

Review my changes to python/sglang/srt/model_executor/model_runner.py against the large-class-style conventions and tell me what to extract into collaborators.

Frequently Asked Questions about large-class-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor a large Python class into an orchestrator with collaborators?

Keep the class as a thin composition root that only constructs, wires, delegates, and coordinates collaborators. Move domain logic — config building, data transformation, algorithms — into collaborator classes in their own modules, and expose small init_<thing> helpers for construction.

Which SGLang files are considered frozen and orchestration-only?

The style guide designates python/sglang/srt/model_executor/model_runner.py as a frozen file. The conventions overall apply to three classes: Scheduler, TokenizerManager, and ModelRunner, with frozen files restricted to construct, wire, delegate, and coordinate statements.

How should I structure __init__ so subclasses can override parts of it?

Split __init__ into one init_<thing> helper per overridable concern, using maybe_init_<thing> for conditional construction. __init__ itself should only sequence these calls, so downstream forks override a single helper instead of copying the whole constructor.

Should I pass the whole ModelRunner or Scheduler object to a collaborator?

No — pass narrow keyword arguments with only the specific values the collaborator needs, and return a small frozen struct for the orchestrator to assign. If the live object is genuinely required, keep it read-only in the callee and confine that dependency to the smallest leaf.

When is it acceptable to leave coordination logic in a frozen file?

Only minimal coordination that cannot be cohesively extracted may remain — an if selecting which collaborator to call, ordering of calls, or threading one result into the next. It must stay pseudocode-readable, and you should note why it stays; if it outgrows that, extract a dedicated coordinator.