openclaw-vsr-bridge

Name: openclaw-vsr-bridge
Author: vllm-project/semantic-router

$npx mdskill add vllm-project/semantic-router/openclaw-vsr-bridge

Install vLLM Semantic Router in agent-safe mode and import OpenClaw models into VSR config

Ensure VSR is installed with `vllm-sr` command available.
Use installer script to safely install VSR without launching the dashboard.
Locate and import OpenClaw model providers into canonical VSR config using vLLM Semantic Router.
Report imported logical model names and success of configuration update.

SKILL.md

.github/skills/openclaw-vsr-bridgeView on GitHub ↗

---
name: openclaw-vsr-bridge
description: Install vLLM Semantic Router in agent-safe mode, import supported OpenClaw model providers into canonical VSR config, and rewrite OpenClaw to target VSR.
user-invocable: true
---

# OpenClaw VSR Bridge

## When To Use

- Use this skill when an OpenClaw agent should install VSR without auto-launching the dashboard.
- Use this skill when an existing `openclaw.json` should be moved under VSR management.
- Use this skill when you want the OpenClaw model base URL rewritten only after canonical `config.yaml` is written successfully.

## Requirements

- `curl`
- `bash`
- write access to the OpenClaw config path and the target VSR config path

## Workflow

1. Check whether VSR is already installed with `command -v vllm-sr`.
2. If VSR is missing, run the supported installer in agent-safe mode:

   ```bash
   curl -fsSL https://vllm-semantic-router.com/install.sh | bash -s -- --mode cli --runtime skip --no-launch
   ```

3. Locate the OpenClaw config in this order unless the user already gave you a path:
   - `$OPENCLAW_CONFIG_PATH`
   - `./openclaw.json`
   - `~/.openclaw/openclaw.json`
4. Import the OpenClaw model providers into canonical VSR config:

   ```bash
   vllm-sr config import --from openclaw --source <openclaw.json> --target config.yaml
   ```

5. Do not pass `--force` unless the user explicitly approves overwriting existing backup files.
6. After a successful import, report:
   - the imported logical model names
   - the canonical target config path
   - the rewritten OpenClaw config path
   - the rewritten OpenClaw base URL
   - the backup file paths, if any
7. Suggest the next validation commands:

   ```bash
   vllm-sr validate config.yaml
   vllm-sr config router --config config.yaml
   ```

8. If the user wants runtime verification after validation, suggest:

   ```bash
   vllm-sr serve --config config.yaml
   curl http://127.0.0.1:8899/v1/models
   ```

## Boundaries

- Do not invent a second installer path. Use the supported installer above.
- Do not rewrite OpenClaw before the VSR target config has been written successfully.
- Do not import OpenClaw rooms, teams, browser settings, command settings, or memory history into VSR.

More from vllm-project/semantic-router

Skill	Description
config-platform-change	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.
cross-stack-bugfix	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.
dashboard-platform-change	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.
fleet-sim-change	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/.
harness-contract-change	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.
k8s-platform-change	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.
maintainer-issue-pr-management	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-ops	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.
plugin-end-to-end	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.
router-service-platform-change	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.