large-class-init-style

Enforce init_* helper patterns in Scheduler, TokenizerManager, and ModelRunner constructors.

Updated Jun 4, 2026
One-click install
npx skills add https://github.com/annealing-inversion/sglang-kimi-deferral --skill large-class-init-style
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: large-class-init-style
Source: https://github.com/annealing-inversion/sglang-kimi-deferral/tree/main/.claude/skills/large-class-init-style
Command: npx skills add https://github.com/annealing-inversion/sglang-kimi-deferral --skill large-class-init-style

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This style enforces a consistent orchestration for the initialization logic across Scheduler, TokenizerManager, and ModelRunner, reducing drift when subclassing or extending construction behavior.

Core Features & Use Cases

  • Enforces the use of dedicated init_* helpers for each overridable unit to avoid inline construction logic.
  • Establishes clear naming conventions such as init_<thing> and maybe_init_<thing> to support safe overrides.
  • Guards against silent state coupling by keeping ordering explicit in init and passing shared intermediates as arguments.

Quick Start

Apply this style when modifying the init of Scheduler, TokenizerManager, or ModelRunner to ensure changes follow the prescribed helper pattern.

Frequently Asked Questions about large-class-init-style

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

FAQPage Schema
How do I standardize __init__ logic across Scheduler, TokenizerManager, and ModelRunner?

To standardize __init__ logic, enforce consistent orchestration by using dedicated init_* helpers for each overridable unit, avoiding inline construction logic to reduce drift when subclassing or extending behavior.

What is the best way to prevent silent state coupling during class initialization?

To prevent silent state coupling, keep ordering explicit in __init__ and pass shared intermediates as arguments to dedicated init_* helpers rather than relying on implicit state.

How do I add new construction logic to ModelRunner or Scheduler without breaking existing overrides?

When adding construction logic to ModelRunner or Scheduler, create new dedicated init_<thing> or maybe_init_<thing> helpers to support safe overrides and maintain established naming conventions.

When do I need to use dedicated init helpers for class construction in SGLang?

You need dedicated init helpers when modifying or reviewing the construction logic of Scheduler, TokenizerManager, or ModelRunner to ensure each class uses dedicated init_* helpers and preserves override points.

Does this initialization style require any external dependencies or frameworks?

No, this initialization style requires no external dependencies, applying purely as a code style convention to enforce consistent __init__ orchestration across key SGLang classes.