signal-end-to-end
$
npx mdskill add vllm-project/semantic-router/signal-end-to-end- Add a new signal type or signal rule shape - Change how an existing signal is configured, extracted, emitted, or displayed - Touch router signal config plus Python CLI schema in the same feature - Change router-owned routing metadata headers or topology payloads that are derived from signal behavior
SKILL.md
.github/skills/signal-end-to-endView on GitHub ↗
--- name: signal-end-to-end category: primary description: 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. --- # Signal End to End ## Trigger - Add a new signal type or signal rule shape - Change how an existing signal is configured, extracted, emitted, or displayed - Touch router signal config plus Python CLI schema in the same feature - Change router-owned routing metadata headers or topology payloads that are derived from signal behavior ## Workflow 1. Read change surfaces and module boundaries for signal context 2. Modify signal config, extraction, CLI schema, and dashboard surfaces as needed 3. Run `make agent-report ENV=cpu CHANGED_FILES="..."` to identify all impacted surfaces 4. Run `make agent-ci-gate CHANGED_FILES="..."` to validate signal contract alignment 5. When the signal becomes user-visible, verify the router-owned metadata chain stays aligned across classify or eval payloads, emitted headers or looper headers, and any dependent reveal or topology consumers 6. Verify router config, signal extraction, and CLI schema stay aligned with relevant E2E coverage ## Gotchas - Signal changes rarely stop at extraction; CLI schema, router-owned metadata headers, or bindings often need updates too. - New matched-signal families often need more than one UI touchpoint: `matched_signals` JSON, `x-vsr-matched-*` headers, `chatRequestSupport`, `HeaderDisplay`, `HeaderReveal`, topology backend conversion, and topology frontend parser or constants. - New signal semantics need explicit E2E ownership, not just unit-level classifier coverage. - If the header or topology contract originates from signal evaluation, keep it in this primary instead of inventing a header-only flow. ## Must Read - [docs/agent/change-surfaces.md](../../../../docs/agent/change-surfaces.md) - [docs/agent/module-boundaries.md](../../../../docs/agent/module-boundaries.md) - [docs/agent/testing-strategy.md](../../../../docs/agent/testing-strategy.md) ## Standard Commands - `make agent-report ENV=cpu CHANGED_FILES="..."` - `make agent-ci-gate CHANGED_FILES="..."` - `make agent-feature-gate ENV=cpu CHANGED_FILES="..."` ## Acceptance - Router config, signal extraction, and Python CLI schema stay aligned for the signal contract - Any router-owned signal metadata updates the relevant classify or eval payloads, emitted headers, and dependent reveal or topology consumers together - Relevant E2E coverage is added or updated when behavior changes
More from vllm-project/semantic-router
- config-platform-changeSynchronizes 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.
- cross-stack-bugfixDiagnoses 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.
- dashboard-platform-changeModifies 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.
- fleet-sim-changeModifies 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/.
- harness-contract-changeModifies 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.
- k8s-platform-changeModifies 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.
- maintainer-issue-pr-managementManages 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-opsMaintainer 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.
- openclaw-vsr-bridgeInstall vLLM Semantic Router in agent-safe mode, import supported OpenClaw model providers into canonical VSR config, and rewrite OpenClaw to target VSR.
- plugin-end-to-endImplements 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.