semantic-router

Bridges native skill discovery into the vLLM Semantic Router repository harness, routing tasks through the canonical agent-report flow, repo-local skill registry, and validation commands. Use when starting any task inside the vLLM Semantic Router repository to resolve the correct primary skill, read canonical docs, and run harness validation.

Install vLLM Semantic Router in agent-safe mode, import supported OpenClaw model providers into canonical VSR config, and rewrite OpenClaw to target VSR.

Synchronizes config representations across router config, Python CLI schema, and dashboard config UI. Use when adding or changing a config concept that spans those surfaces or addressing config representation debt before Kubernetes-facing translation.

Diagnoses and fixes bugs that span multiple layers (runtime, CLI, UI, platform, tests) requiring coordinated changes across surfaces. Use when a bug does not map cleanly to a narrower skill, the fix touches more than one surface, or changes need cross-cutting validation.

Modifies dashboard frontend or backend surfaces that present, configure, or manage router behavior through the console UI. Use when changing dashboard pages or components, backend handlers, console persistence, auth or session flows, or user-visible routing metadata in the dashboard.

Modifies the fleet simulator package, API service, release wiring, or simulator-owned docs and assets as one maintained subsystem. Use when changing src/fleet-sim, simulator release workflow, or fleet-sim-owned docs and assets under website/.

Modifies the repository's agent contract including AGENTS.md, docs index, manifests, validation scripts, and contributor-facing harness wrappers. Use when updating agent documentation, changing repo manifests, editing validation scripts, modifying CI/workflow classification, or updating contributor-facing guides like README.md, CONTRIBUTING.md, or the PR template.

Modifies Kubernetes-facing operator, CRD, deployment-profile, or DSL translation behavior for semantic-router platform integration. Use when changing operator APIs or controllers, deployment stack manifests, profile-owned platform wiring, or router-to-Kubernetes translation layers.

Manages GitHub issue and pull-request lifecycle including creation, updates, triage labelling, and closeout metadata using canonical templates and repository taxonomy. Use when a maintainer asks to create, update, close, or triage GitHub issues or PRs, or when issue creation requires codebase analysis for scope, labels, or acceptance criteria.

Maintainer release and milestone operating workflow. Use when a maintainer wants to plan a release, create milestone issues, sync GitHub issue or PR state, generate a daily review brief, or manage stale PRs and backlog routing.

Calibrates routing changes against a live router endpoint with executable probes, local DSL validation, versioned deploys, and structured failure review. Use when tuning signals, projections, decisions, or maintained route examples against a real apiserver.

Implements end-to-end plugin changes spanning router config, post-decision processing, optional CLI/UI exposure, and E2E test coverage. Use when adding a new plugin type, changing plugin config schema or execution semantics, updating plugin chain behavior, or modifying plugin-exposed metadata across surfaces.

Modifies router-side API, authz, memory, provider, storage, or runtime service modules outside config, decision, selection, and extproc plugin chains. Use when changing apiserver endpoints, authz or rate-limit policy code, memory or response storage flows, provider adapters, or other router service-platform modules.

Modifies routing policy after signal extraction, including matched-decision logic, candidate-model selection, and downstream looper behavior. Use when changing decision predicates, thresholds, priorities, model ranking, cost or latency routing, or other post-signal routing policy.

Implements end-to-end signal changes spanning router config, signal extraction, CLI schema, optional bindings, router-owned metadata headers, and E2E test coverage. Use when adding a new signal type, changing signal configuration or extraction logic, updating CLI schema for signal parameters, or modifying router-owned signal metadata contracts.

Modifies the local startup chain including image build, container serve/bootstrap logic, and canonical smoke test behavior. Use when changing `vllm-sr serve` behavior, image selection or pull policy, container startup sequences, local Docker/Make bootstrap, or canonical smoke config.

Modifies training-stack workflows, selector or embedding pipelines, evaluation artifacts, or runtime-facing outputs under src/training. Use when changing model selection training, embedding pipelines, evaluation scripts, experiments, or other training outputs that feed runtime behavior.