What problem does it solve?
When writing tests against the SGLang scripted runtime, engineers often add unnecessary harness wrapper APIs that grow the surface without adding isolation, or probe implementation details instead of asserting real behavior. This Skill codifies the rules for when to add a harness API versus reading scheduler state directly.
Core Features & Use Cases
- API Decision Rules: Defines the three legitimate cases for adding a harness API: control primitives driving real engine paths, hook-backed accumulators, and widely reused multi-structure derivations.
- Anti-Pattern Guardrails: Lists what never to do, including weakening assertions to fit missing probes, monkey-patching, and calling scheduler privates synchronously from tests.
- Use Case: While writing a test that checks scheduler idle behavior, use this Skill to decide whether to add an
is_idle helper or read t._scheduler state directly, and to drive engine-self-driven behavior via the real loop with yield instead of calling private methods.
Quick Start
Ask the AI to review your scripted runtime test and decide whether a new harness API is justified according to the scripted runtime notes.
