メニュー
Guides coding agents through a session-isolated install of the vllm-sr CLI. The install is scoped to a temporary directory so it does not modify the user's global PATH or system packages. Use when an agent or user wants to try vllm-sr without a permanent install.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | claude-code-install |
| category | support |
| description | Guides coding agents through a session-isolated install of the vllm-sr CLI. The install is scoped to a temporary directory so it does not modify the user's global PATH or system packages. Use when an agent or user wants to try vllm-sr without a permanent install. |
vllm-sr CLI without permanent system changescli_installbash, curl, or python3 (install.sh prerequisites)install.sh directly instead)Run the session-isolated wrapper script:
bash tools/agent/scripts/cc-install.sh
This creates a temp directory, installs the CLI there, and prints the export PATH line.
Export the PATH as printed:
export PATH="/tmp/vllm-sr-session-<tag>/bin:$PATH"
Validate the install:
vllm-sr --version
vllm-sr validate # if a config.yaml exists
When done, the session directory is cleaned up automatically on reboot, or remove it manually:
rm -rf /tmp/vllm-sr-session-<tag>
Any extra flags are forwarded to install.sh. For example:
bash tools/agent/scripts/cc-install.sh --runtime docker
The wrapper only sets defaults for --mode, --runtime, --install-root, --bin-dir, and --no-launch when they are not already present in the caller's arguments.
--mode or --runtime explicitly, the wrapper does not override them.$$) can collide if the OS reuses PIDs quickly. Set VLLM_SR_SESSION_TAG to a unique value for concurrent installs.install.sh fails mid-install, the trap automatically cleans up the session directory. Do not rely on its partial contents.bash tools/agent/scripts/cc-install.shvllm-sr --versionvllm-sr validatevllm-sr --version succeeds after running the wrapper and exporting PATHCalibrates 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.
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.
Runs an explicit structural review for boundary-sensitive edits that need dependency, module, and structure-rule scrutiny without forcing that material into every default context pack. Use when a task crosses hotspot boundaries, adds new seams, or needs a deliberate architecture pass.
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.
Maintains dashboard frontend and backend implementation slices that present, configure, or expose router behavior through the console. Use when the task changes dashboard config flows, console backend handlers, topology rendering, playground reveal flows, or other user-visible routing metadata in the dashboard.
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.