[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PXA1166NGMDKV7FKHT32W":3,"skill-same:01M71PXA1166NGMDKV7FKHT32W":125},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":66,"install":67,"resources":80},"01M71PXA1166NGMDKV7FKHT32W","tao-run-inference-service",null,"Start, query, and stop a network-specific TAO inference microservice ({network_arch}-inference-microservice) by delegating container execution to the appropriate platform skill. Handles container image resolution, job-payload JSON construction, and the service registry. Use when the user wants to run inference on a TAO model checkpoint using a microservice container, deploy a TAO inference endpoint, or stop a running inference container.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"run","tao","service","inference","tao run inference service","token","write","read","storage","dependency","arch","Bash","query","image","workflow","service registry","when","local","cloud-storage","model","2026-11-10 13:02:02",false,"---\nname: tao-run-inference-service\ndescription: >\n  Start, query, and stop a network-specific TAO inference microservice\n  ({network_arch}-inference-microservice) by delegating container execution to\n  the appropriate platform skill. Handles container image resolution,\n  job-payload JSON construction, and the service registry. Use when the user\n  wants to run inference on a TAO model checkpoint using a microservice\n  container, deploy a TAO inference endpoint, or stop a running inference\n  container.\nlicense: Apache-2.0\ncompatibility: The inference service has no cloud-storage dependency — model weights come from the HuggingFace Hub (HF_TOKEN env var for gated models) or a local container path. Platform prerequisites are checked by each platform skill.\nmetadata:\n  author: NVIDIA Corporation\n  version: \"0.1.0\"\nallowed-tools: Read Bash Write\ntags:\n- inference\n- microservice\n- workflow\n---\n\n# TAO Inference Microservice\n\n## Instructions\n\n**To start an inference service:**\n1. Collect required inputs (Section 1) and resolve the container image (Section 2).\n2. Build the job payload and inner command (Sections 3–4.1); use `references\u002Fcode-templates.yaml` → `job_payload_builder`.\n3. Read `skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md` and start the container (Section 4.2).\n4. Write the service registry and poll readiness (Section 4.3); use `references\u002Fcode-templates.yaml` → `registry_write.\u003Cplatform>` and `readiness_check`.\n\n**To send an inference request:**\n1. Resolve which service receives the request per Section 6.0 (by `job_id`, by `network_arch`, or by explicit user choice when multiple services run — **never silently default to `\"latest\"` when more than one service exists**), then read the endpoint from `references\u002Fcode-templates.yaml` → `request.registry_read` with the resolved `job_id`.\n2. **Before building the request body, prompt the user for the vLLM-style sampling parameters (Section 6.1).** Present `max_tokens`, `top_p`, `temperature` (and any per-arch extras) with their defaults; let the user override or skip each one to accept the default. Never silently use defaults.\n3. Build and send the body per Section 6.2; handle the response per Section 6.3.\n\n**To stop a service:** Read `references\u002Fcode-templates.yaml` → `stop.registry_read` to resolve the job_id, read `skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`, then follow Section 5.\n\n**Reference data** (schemas, mappings, valid values — no instructions):\n- **`references\u002Fservice.yaml`** — image mappings, valid `network_arch` names, job payload schema, env var names, secrets classification.\n- **`references\u002Frequest.yaml`** — endpoint definition, request field schema, response shapes, code examples.\n- **`references\u002Fcode-templates.yaml`** — Python templates for payload building, registry writes, readiness checks, and stop\u002Frequest flows.\n\n---\n\n## Secrets rule (applies to every generated code block in this skill)\n\n**Never ask the user to type a secret value into a prompt.** For every secret value:\n1. Tell the user which environment variable to set (e.g. `export HF_TOKEN=...`).\n2. Generate code that reads it with `os.environ[\"VAR_NAME\"]` — never hard-code, interpolate, or prompt for the value.\n\n**Secret env vars** (full list in `references\u002Fservice.yaml` → `secrets_handling`):\n`HF_TOKEN`, `WANDB_API_KEY`, `CLEARML_API_ACCESS_KEY`, `CLEARML_API_SECRET_KEY`, `TAO_API_KEY`, `TAO_USER_KEY`.\n\n**Safe to collect in the prompt:** `network_arch`, `model_path`, `num_gpus`, prompt text, `WANDB_*` config URLs, `CLEARML_*_HOST` URLs.\n\n---\n\n## 1. What to collect from the user\n\n| Input | Role |\n|--------|------|\n| **`network_arch`** | Chooses container image, the per-arch inner command shape (`references\u002Fservice.yaml` → `container_commands.\u003Cnetwork_arch>`), and `neural_network_name` in the job JSON when applicable. Must match a basename in `valid_network_arch_config_basenames` in `references\u002Fservice.yaml` (e.g. `cosmos-rl`, `cosmos-predict2.5`). |\n| **`model_path`** | The trained model checkpoint. Valid forms: `hf_model:\u002F\u002F\u003Corg>\u002F\u003Cmodel>` (HuggingFace Hub — set `HF_TOKEN` for gated models) or a local container filesystem path. Cloud URIs (`s3:\u002F\u002F`, `gs:\u002F\u002F`, `az:\u002F\u002F`) are NOT supported — the inference service has no cloud-storage dependency. Always ask the user; never substitute a placeholder. See `references\u002Fservice.yaml` → `model_path_protocols`. |\n| **`platform`** | Compute platform: `local-docker`, `brev`, `slurm`, or `kubernetes`. |\n| **`num_gpus`** | Defaults to **1**; minimum **1** for inference. |\n\n---\n\n## 2. Image resolution\n\nEach `network_arch` has a sidecar config file named `{network_arch}.config.json`. Resolve the container image as follows:\n\n1. Read `{network_arch}.config.json` and take `api_params.image` (e.g. `COSMOS_RL`). This is a key into `docker_image_defaults.mapping` in `references\u002Fservice.yaml`.\n2. Look up that key in the mapping. If the host env var `IMAGE_\u003CKEY>` is set (e.g. `IMAGE_COSMOS_RL`), it overrides the mapped default.\n3. The mapped value is normally a dotted key into the repo-root `versions.yaml` manifest (e.g. `tao_toolkit.cosmos_rl`). Resolve it to a concrete `nvcr.io\u002F...` image URI by looking up `versions.yaml` → `images.\u003Cgroup>.\u003Cname>`. Absolute URIs pass through unchanged, so an `IMAGE_\u003CKEY>` env-var override that contains a full URI still works. The Python helper for this lives in `references\u002Fcode-templates.yaml`.\n4. If the config file is missing or `api_params.image` is empty, fall back to the `COSMOS_RL` key.\n\nThe config file also has `spec_params.inference.model_path` which drives **folder vs file** path semantics: if the value contains the substring `folder`, the container treats the path as a directory.\n\n---\n\n## 3. Environment variables (no callbacks)\n\nSet these in `env_payload` before encoding `env_json`. Do **not** set `TAO_LOGGING_SERVER_URL` or `TAO_ADMIN_KEY`.\n\n**`TAO_EXECUTION_BACKEND`** — must match the platform:\n\n| Platform | `TAO_EXECUTION_BACKEND` value |\n|----------|-------------------------------|\n| local-docker | `local-docker` |\n| brev | `local-docker` |\n| slurm | `slurm` |\n| kubernetes | `local-k8s` |\n\n**`CLOUD_BASED`** — always `\"False\"` for this skill (disables callback posting to `TAO_LOGGING_SERVER_URL`).\n\n**GPU env vars** — only needed when the platform skill does not handle GPU injection automatically:\n- Tegra \u002F Jetson: `--runtime=nvidia` with `NVIDIA_DRIVER_CAPABILITIES=all` and `NVIDIA_VISIBLE_DEVICES=\u003Cids>`.\n- Standard x86 + nvidia-container-toolkit: use Docker `device_requests`. The platform skill handles this.\n\n---\n\n## 4. Executing across platforms\n\nThe job payload and inner command (Sections 1–3) are **platform-agnostic**. For each platform, read **`skills\u002Fplatform\u002F\u003Cname>\u002FSKILL.md`** for preflight checks and credentials **before** generating any execution code.\n\n### 4.1 Build the inner command (per arch)\n\nThe inner-command shape is **per `network_arch`** — there is no uniform template. Look up the per-arch entry in `references\u002Fservice.yaml` → `container_commands.\u003Cnetwork_arch>`; if not present, the arch is unsupported — stop and ask. Pick the matching sub-block in `references\u002Fcode-templates.yaml` → `job_payload_builder.\u003Cnetwork_arch>`. Prefix the command with `umask 0 &&` and keep it **identical across platforms** (local-docker, brev, slurm, kubernetes).\n\nCommon across arches:\n\n- `job_id`: fresh `uuid.uuid4()` — becomes the container name and registry key.\n- `image`: resolve per Section 2.\n- Secrets (`access_key`, `secret_key`, `HF_TOKEN`, etc.) are read from env vars at runtime — never hard-code, never log or print.\n\nArch-specific notes (full details in `references\u002Fservice.yaml` → `container_commands`):\n\n- **`cosmos-rl`** — single `--job '\u003CJOB_JSON>' --docker_env_vars '\u003CENV_JSON>'` blob; `json.dumps(...)` + `shlex.quote(...)`. `env_payload` carries `TAO_EXECUTION_BACKEND` (per Section 3 table), `TAO_API_JOB_ID`, `CLOUD_BASED=False`. The inference service has no cloud-storage dependency; `HF_TOKEN` is the only cred env var that ever applies (for gated HuggingFace models).\n- **`cosmos-predict2.5`** — flag-style `cosmos_predict inference_microservice start ... --port 8080` (no `setup.` prefix; uses `tyro.conf.OmitArgPrefixes`). `--job`\u002F`--docker_env_vars` are **not** accepted. Translate `model_path` to `--checkpoint-path` (local path) or `--model \u003Cregistered_key>` (`hf_model:\u002F\u002F`); cloud URIs are rejected. The only cred env var that ever applies is `HF_TOKEN` for gated HuggingFace models. Per-request params (prompt, inference_type, num_output_frames, guidance, seed, num_steps, negative_prompt) go in the request body, not at startup. `TAO_EXECUTION_BACKEND`\u002F`TAO_API_JOB_ID`\u002F`CLOUD_BASED` are unused and may be omitted.\n\n### 4.2 Delegate execution to the platform skill\n\nRead **`skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`** and follow it to start the container.\n\n**Base parameters (all platforms):**\n\n| Parameter | Value |\n|-----------|-------|\n| `image` | resolved container image (Section 2) |\n| `command` | `inner` — the shell string built in Section 4.1 |\n| `gpu_count` | `num_gpus` |\n| `env_vars` | `env_payload` |\n| job \u002F container name | `job_id` — must equal the UUID from 4.1 so the registry can reference it |\n| `host_port` *(local-docker, brev)* | host-side port to bind to container port 8080. Default `8080`, but **must be unique per concurrent service** — see the port-allocation rule below. |\n\n**Platform-specific additional inputs:**\n\n| Platform | Additional inputs |\n|----------|------------------|\n| **local-docker** | None beyond base |\n| **brev** | `instance_id` (optional — reuse an existing instance); on multi-credential \u002F multi-workspace accounts also `cloud_cred_id` and `workspace_group_id` for first-create — see `skills\u002Fplatform\u002Ftao-run-on-brev\u002FSKILL.md` |\n| **slurm** | `partition` and `account` — check `SLURM_PARTITION`\u002F`SLURM_ACCOUNT` env vars; ask user if unset |\n| **kubernetes** | `namespace` (default: `default`); `image_pull_secret` (required for `nvcr.io` images) |\n\n**Port binding (local-docker and brev):** use **direct docker run** (not DockerSDK) so that `-p \u003Chost_port>:8080` can be passed and the container name equals `job_id` exactly.\n\n**Port allocation rule (local-docker and brev, REQUIRED for concurrent services):** Before starting a service, read the registry (`\u002Ftmp\u002Ftao-inf-ms-state.json`) and collect the set of `host_port` values from every existing entry on the same platform (and, for brev, the same `instance_id`). Pick the **lowest free port starting from 8080** that is not in that set — e.g. `host_port = next(p for p in range(8080, 8200) if p not in used_ports)`. The default `8080` only applies when no other service is running. This is what makes \"start 3 services, each reachable at a distinct `host_url`\" work; without it, services 2 and 3 fail with `bind: address already in use`. SLURM and kubernetes get distinct endpoints from their own platform mechanisms and do not need this step.\n\n### 4.3 After start: service registry and endpoint\n\nWrite the service registry immediately after the platform confirms the container is running. The registry (`\u002Ftmp\u002Ftao-inf-ms-state.json`) is keyed by `job_id`; `\"latest\"` always points to the most recently started service.\n\nSee `references\u002Fcode-templates.yaml` → `registry_write.\u003Cplatform>` for the Python template.\n\n| Platform | `host_url` | `platform_job_id` | Extra step before writing |\n|----------|-----------|-------------------|--------------------------|\n| **local-docker** | `http:\u002F\u002Flocalhost:{host_port}` | — | None |\n| **brev** | `http:\u002F\u002F{brev_ip}:{host_port}` | — | `brev ls` → get instance IP (`localhost` is invalid on remote VM) |\n| **slurm** | `http:\u002F\u002Flocalhost:{host_port}` | SLURM scheduler job ID | Wait until Running; SSH port-forward `localhost:{host_port}→{node}:8080` |\n| **kubernetes** | `http:\u002F\u002F{external_ip}:8080` | k8s job name | `kubectl expose job … --type=LoadBalancer`; wait for external IP |\n\nAfter writing the registry, print the job_id and URL:\n\n```python\nprint(f\"Inference service started.\")\nprint(f\"  Job ID : {job_id}\")\nprint(f\"  Arch   : {network_arch}\")\nprint(f\"  URL    : {state[job_id]['host_url']}\u002Fv1\u002Fchat\u002Fcompletions\")\nprint(f\"Use this Job ID to send requests or stop the service.\")\n```\n\nThen poll for readiness — see `references\u002Fcode-templates.yaml` → `readiness_check`. The container loads the model in the background; do not send requests before it returns 200.\n\n---\n\n## 5. Stopping the inference service\n\nAsk the user for the `job_id` to stop. If they don't provide one, default to `state[\"latest\"]` and confirm which job_id is being stopped. Read the registry using `references\u002Fcode-templates.yaml` → `stop.registry_read`, then read **`skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`** and use its cancellation \u002F stop mechanism.\n\n| Platform | Identifier to pass | Extra cleanup |\n|----------|--------------------|---------------|\n| **local-docker** | `job_id_to_stop` — container name | None |\n| **brev** | `job_id_to_stop` — container name | None |\n| **slurm** | `entry[\"platform_job_id\"]` — SLURM job ID | `pkill -f \"ssh.*-L.*{entry['host_port']}\"` |\n| **kubernetes** | `entry[\"platform_job_id\"]` — k8s job name | `kubectl delete svc {entry[\"platform_job_id\"]} -n \u003Cnamespace>` |\n\nwhere `entry = state[job_id_to_stop]`. After stopping, clean up the registry: `references\u002Fcode-templates.yaml` → `stop.registry_cleanup`.\n\n---\n\n## 6. Sending inference requests\n\n### 6.0 Resolve which service receives this request (REQUIRED)\n\nEach request must be routed to the **specific** service that runs the matching model. Routing happens by `job_id` — the registry stores `network_arch` per entry, so you can resolve a target by arch when the user names a model instead of a `job_id`. Apply these rules in order:\n\n1. **User provided an explicit `job_id`** → use it. Verify it exists in `state`.\n2. **User named a `network_arch`** (e.g. \"send this to the cosmos-rl service\") → look up matching entries: `candidates = [j for j, e in state.items() if j != \"latest\" and isinstance(e, dict) and e[\"network_arch\"] == arch]`.\n   - Exactly one match → use it.\n   - Multiple matches → **prompt the user** with the candidate `job_id`s and their `started_at`; do not auto-pick.\n   - No match → stop and tell the user no service for that arch is running.\n3. **No `job_id` and no `network_arch`** → count non-`\"latest\"` entries in `state`:\n   - Exactly one running service → use it.\n   - Two or more → **do not silently default to `state[\"latest\"]`**. Prompt the user with the full list (`job_id`, `network_arch`, `host_url`) and require an explicit choice. The `\"latest\"` pointer is a convenience for single-service workflows, not a routing fallback when multiple services coexist.\n   - Zero → stop and tell the user to start a service first.\n\nAfter resolving, read the endpoint from the registry (`references\u002Fcode-templates.yaml` → `request.registry_read`), passing the resolved `job_id` as `user_provided_job_id`. Confirm to the user: \"Sending to job_id=… arch=… url=…\". If the service may still be loading, poll readiness first (`references\u002Fcode-templates.yaml` → `readiness_check`).\n\n**Cross-check before sending:** if the user-supplied request body contains arch-specific fields (e.g. `guidance` \u002F `num_steps` \u002F `seed` \u002F `negative_prompt` → cosmos-predict2.5; required `image_url`\u002F`video_url` content items → cosmos-rl), verify they are consistent with `state[job_id][\"network_arch\"]`. On mismatch, stop and ask — sending a cosmos-predict2.5 body to a cosmos-rl service will fail at the container with a 4xx\u002F5xx that is harder to diagnose than catching it here.\n\n### 6.1 Sampling parameters — REQUIRED user prompt before each request\n\nBefore constructing the request body, you **MUST** explicitly prompt the user for the vLLM-style sampling parameters. Do **not** silently apply defaults. Use a structured prompt, one question per field, that:\n\n1. Lists every applicable field with its **type** and **default value**.\n2. Lets the user skip \u002F accept any field to take that field's default — entering a value is never required.\n3. Collects all fields in one round.\n\nAfter the prompt, apply each user-entered value verbatim and substitute the default for any skipped field. Do not invent values or silently clamp.\n\n**Field list, defaults, and per-arch applicability:** `references\u002Frequest.yaml` → `chat_completions_request_body` (base sampling fields: `max_tokens`, `top_p`, `temperature`) and `network_arch_constraints.\u003Cnetwork_arch>` (per-arch overrides and extras such as `guidance`\u002F`num_steps`\u002F`seed`\u002F`negative_prompt` for `cosmos-predict2.5`). If a field is marked unsupported for the active arch, do **not** prompt for it and do **not** include it in the body.\n\n### 6.2 Request format\n\nSend a `POST` to `{BASE_URL}\u002Fv1\u002Fchat\u002Fcompletions` with `Content-Type: application\u002Fjson` and a timeout of **at least 300 s**. The body is OpenAI-compatible (vLLM chat completions); see `references\u002Frequest.yaml` → `chat_completions_request_body` for the full field schema and content-item shapes (text \u002F image_url \u002F video_url), and `code_examples` for ready-to-run Python and curl samples.\n\n**Constraints:** only the first user message is processed. No secret values in request bodies. **Per-network constraints** (e.g. cosmos-rl requires every request to include an image or video; cosmos-rl rejects `data:` URIs) are in `references\u002Frequest.yaml` → `network_arch_constraints`.\n\n### 6.3 Response handling\n\n| HTTP status | Meaning | Action |\n|-------------|---------|--------|\n| **200** | Success — `choices[0].message.content` has the generated text | Read result |\n| **202** | Server still initializing or model still loading | Retry after a delay |\n| **503** | Initialization failed, model load failed, **or model not yet ready** | Inspect `error.type`: `model_not_ready` → retry; `initialization_error` \u002F `model_load_error` → give up and check logs |\n| **400** | Missing or empty JSON body | Fix request |\n| **500** | Unhandled exception during inference | Check container logs |\n\nFor 202 and 503, the body contains `{\"error\": {\"type\": \"\u003Cerror_type>\", \"message\": \"\u003Creason>\"}}`. See `container_response_shapes` in `references\u002Frequest.yaml` for error type strings.\n","# TAO Inference Microservice\n\n## Instructions\n\n**To start an inference service:**\n1. Collect required inputs (Section 1) and resolve the container image (Section 2).\n2. Build the job payload and inner command (Sections 3–4.1); use `references\u002Fcode-templates.yaml` → `job_payload_builder`.\n3. Read `skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md` and start the container (Section 4.2).\n4. Write the service registry and poll readiness (Section 4.3); use `references\u002Fcode-templates.yaml` → `registry_write.\u003Cplatform>` and `readiness_check`.\n\n**To send an inference request:**\n1. Resolve which service receives the request per Section 6.0 (by `job_id`, by `network_arch`, or by explicit user choice when multiple services run — **never silently default to `\"latest\"` when more than one service exists**), then read the endpoint from `references\u002Fcode-templates.yaml` → `request.registry_read` with the resolved `job_id`.\n2. **Before building the request body, prompt the user for the vLLM-style sampling parameters (Section 6.1).** Present `max_tokens`, `top_p`, `temperature` (and any per-arch extras) with their defaults; let the user override or skip each one to accept the default. Never silently use defaults.\n3. Build and send the body per Section 6.2; handle the response per Section 6.3.\n\n**To stop a service:** Read `references\u002Fcode-templates.yaml` → `stop.registry_read` to resolve the job_id, read `skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`, then follow Section 5.\n\n**Reference data** (schemas, mappings, valid values — no instructions):\n- **`references\u002Fservice.yaml`** — image mappings, valid `network_arch` names, job payload schema, env var names, secrets classification.\n- **`references\u002Frequest.yaml`** — endpoint definition, request field schema, response shapes, code examples.\n- **`references\u002Fcode-templates.yaml`** — Python templates for payload building, registry writes, readiness checks, and stop\u002Frequest flows.\n\n---\n\n## Secrets rule (applies to every generated code block in this skill)\n\n**Never ask the user to type a secret value into a prompt.** For every secret value:\n1. Tell the user which environment variable to set (e.g. `export HF_TOKEN=...`).\n2. Generate code that reads it with `os.environ[\"VAR_NAME\"]` — never hard-code, interpolate, or prompt for the value.\n\n**Secret env vars** (full list in `references\u002Fservice.yaml` → `secrets_handling`):\n`HF_TOKEN`, `WANDB_API_KEY`, `CLEARML_API_ACCESS_KEY`, `CLEARML_API_SECRET_KEY`, `TAO_API_KEY`, `TAO_USER_KEY`.\n\n**Safe to collect in the prompt:** `network_arch`, `model_path`, `num_gpus`, prompt text, `WANDB_*` config URLs, `CLEARML_*_HOST` URLs.\n\n---\n\n## 1. What to collect from the user\n\n| Input | Role |\n|--------|------|\n| **`network_arch`** | Chooses container image, the per-arch inner command shape (`references\u002Fservice.yaml` → `container_commands.\u003Cnetwork_arch>`), and `neural_network_name` in the job JSON when applicable. Must match a basename in `valid_network_arch_config_basenames` in `references\u002Fservice.yaml` (e.g. `cosmos-rl`, `cosmos-predict2.5`). |\n| **`model_path`** | The trained model checkpoint. Valid forms: `hf_model:\u002F\u002F\u003Corg>\u002F\u003Cmodel>` (HuggingFace Hub — set `HF_TOKEN` for gated models) or a local container filesystem path. Cloud URIs (`s3:\u002F\u002F`, `gs:\u002F\u002F`, `az:\u002F\u002F`) are NOT supported — the inference service has no cloud-storage dependency. Always ask the user; never substitute a placeholder. See `references\u002Fservice.yaml` → `model_path_protocols`. |\n| **`platform`** | Compute platform: `local-docker`, `brev`, `slurm`, or `kubernetes`. |\n| **`num_gpus`** | Defaults to **1**; minimum **1** for inference. |\n\n---\n\n## 2. Image resolution\n\nEach `network_arch` has a sidecar config file named `{network_arch}.config.json`. Resolve the container image as follows:\n\n1. Read `{network_arch}.config.json` and take `api_params.image` (e.g. `COSMOS_RL`). This is a key into `docker_image_defaults.mapping` in `references\u002Fservice.yaml`.\n2. Look up that key in the mapping. If the host env var `IMAGE_\u003CKEY>` is set (e.g. `IMAGE_COSMOS_RL`), it overrides the mapped default.\n3. The mapped value is normally a dotted key into the repo-root `versions.yaml` manifest (e.g. `tao_toolkit.cosmos_rl`). Resolve it to a concrete `nvcr.io\u002F...` image URI by looking up `versions.yaml` → `images.\u003Cgroup>.\u003Cname>`. Absolute URIs pass through unchanged, so an `IMAGE_\u003CKEY>` env-var override that contains a full URI still works. The Python helper for this lives in `references\u002Fcode-templates.yaml`.\n4. If the config file is missing or `api_params.image` is empty, fall back to the `COSMOS_RL` key.\n\nThe config file also has `spec_params.inference.model_path` which drives **folder vs file** path semantics: if the value contains the substring `folder`, the container treats the path as a directory.\n\n---\n\n## 3. Environment variables (no callbacks)\n\nSet these in `env_payload` before encoding `env_json`. Do **not** set `TAO_LOGGING_SERVER_URL` or `TAO_ADMIN_KEY`.\n\n**`TAO_EXECUTION_BACKEND`** — must match the platform:\n\n| Platform | `TAO_EXECUTION_BACKEND` value |\n|----------|-------------------------------|\n| local-docker | `local-docker` |\n| brev | `local-docker` |\n| slurm | `slurm` |\n| kubernetes | `local-k8s` |\n\n**`CLOUD_BASED`** — always `\"False\"` for this skill (disables callback posting to `TAO_LOGGING_SERVER_URL`).\n\n**GPU env vars** — only needed when the platform skill does not handle GPU injection automatically:\n- Tegra \u002F Jetson: `--runtime=nvidia` with `NVIDIA_DRIVER_CAPABILITIES=all` and `NVIDIA_VISIBLE_DEVICES=\u003Cids>`.\n- Standard x86 + nvidia-container-toolkit: use Docker `device_requests`. The platform skill handles this.\n\n---\n\n## 4. Executing across platforms\n\nThe job payload and inner command (Sections 1–3) are **platform-agnostic**. For each platform, read **`skills\u002Fplatform\u002F\u003Cname>\u002FSKILL.md`** for preflight checks and credentials **before** generating any execution code.\n\n### 4.1 Build the inner command (per arch)\n\nThe inner-command shape is **per `network_arch`** — there is no uniform template. Look up the per-arch entry in `references\u002Fservice.yaml` → `container_commands.\u003Cnetwork_arch>`; if not present, the arch is unsupported — stop and ask. Pick the matching sub-block in `references\u002Fcode-templates.yaml` → `job_payload_builder.\u003Cnetwork_arch>`. Prefix the command with `umask 0 &&` and keep it **identical across platforms** (local-docker, brev, slurm, kubernetes).\n\nCommon across arches:\n\n- `job_id`: fresh `uuid.uuid4()` — becomes the container name and registry key.\n- `image`: resolve per Section 2.\n- Secrets (`access_key`, `secret_key`, `HF_TOKEN`, etc.) are read from env vars at runtime — never hard-code, never log or print.\n\nArch-specific notes (full details in `references\u002Fservice.yaml` → `container_commands`):\n\n- **`cosmos-rl`** — single `--job '\u003CJOB_JSON>' --docker_env_vars '\u003CENV_JSON>'` blob; `json.dumps(...)` + `shlex.quote(...)`. `env_payload` carries `TAO_EXECUTION_BACKEND` (per Section 3 table), `TAO_API_JOB_ID`, `CLOUD_BASED=False`. The inference service has no cloud-storage dependency; `HF_TOKEN` is the only cred env var that ever applies (for gated HuggingFace models).\n- **`cosmos-predict2.5`** — flag-style `cosmos_predict inference_microservice start ... --port 8080` (no `setup.` prefix; uses `tyro.conf.OmitArgPrefixes`). `--job`\u002F`--docker_env_vars` are **not** accepted. Translate `model_path` to `--checkpoint-path` (local path) or `--model \u003Cregistered_key>` (`hf_model:\u002F\u002F`); cloud URIs are rejected. The only cred env var that ever applies is `HF_TOKEN` for gated HuggingFace models. Per-request params (prompt, inference_type, num_output_frames, guidance, seed, num_steps, negative_prompt) go in the request body, not at startup. `TAO_EXECUTION_BACKEND`\u002F`TAO_API_JOB_ID`\u002F`CLOUD_BASED` are unused and may be omitted.\n\n### 4.2 Delegate execution to the platform skill\n\nRead **`skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`** and follow it to start the container.\n\n**Base parameters (all platforms):**\n\n| Parameter | Value |\n|-----------|-------|\n| `image` | resolved container image (Section 2) |\n| `command` | `inner` — the shell string built in Section 4.1 |\n| `gpu_count` | `num_gpus` |\n| `env_vars` | `env_payload` |\n| job \u002F container name | `job_id` — must equal the UUID from 4.1 so the registry can reference it |\n| `host_port` *(local-docker, brev)* | host-side port to bind to container port 8080. Default `8080`, but **must be unique per concurrent service** — see the port-allocation rule below. |\n\n**Platform-specific additional inputs:**\n\n| Platform | Additional inputs |\n|----------|------------------|\n| **local-docker** | None beyond base |\n| **brev** | `instance_id` (optional — reuse an existing instance); on multi-credential \u002F multi-workspace accounts also `cloud_cred_id` and `workspace_group_id` for first-create — see `skills\u002Fplatform\u002Ftao-run-on-brev\u002FSKILL.md` |\n| **slurm** | `partition` and `account` — check `SLURM_PARTITION`\u002F`SLURM_ACCOUNT` env vars; ask user if unset |\n| **kubernetes** | `namespace` (default: `default`); `image_pull_secret` (required for `nvcr.io` images) |\n\n**Port binding (local-docker and brev):** use **direct docker run** (not DockerSDK) so that `-p \u003Chost_port>:8080` can be passed and the container name equals `job_id` exactly.\n\n**Port allocation rule (local-docker and brev, REQUIRED for concurrent services):** Before starting a service, read the registry (`\u002Ftmp\u002Ftao-inf-ms-state.json`) and collect the set of `host_port` values from every existing entry on the same platform (and, for brev, the same `instance_id`). Pick the **lowest free port starting from 8080** that is not in that set — e.g. `host_port = next(p for p in range(8080, 8200) if p not in used_ports)`. The default `8080` only applies when no other service is running. This is what makes \"start 3 services, each reachable at a distinct `host_url`\" work; without it, services 2 and 3 fail with `bind: address already in use`. SLURM and kubernetes get distinct endpoints from their own platform mechanisms and do not need this step.\n\n### 4.3 After start: service registry and endpoint\n\nWrite the service registry immediately after the platform confirms the container is running. The registry (`\u002Ftmp\u002Ftao-inf-ms-state.json`) is keyed by `job_id`; `\"latest\"` always points to the most recently started service.\n\nSee `references\u002Fcode-templates.yaml` → `registry_write.\u003Cplatform>` for the Python template.\n\n| Platform | `host_url` | `platform_job_id` | Extra step before writing |\n|----------|-----------|-------------------|--------------------------|\n| **local-docker** | `http:\u002F\u002Flocalhost:{host_port}` | — | None |\n| **brev** | `http:\u002F\u002F{brev_ip}:{host_port}` | — | `brev ls` → get instance IP (`localhost` is invalid on remote VM) |\n| **slurm** | `http:\u002F\u002Flocalhost:{host_port}` | SLURM scheduler job ID | Wait until Running; SSH port-forward `localhost:{host_port}→{node}:8080` |\n| **kubernetes** | `http:\u002F\u002F{external_ip}:8080` | k8s job name | `kubectl expose job … --type=LoadBalancer`; wait for external IP |\n\nAfter writing the registry, print the job_id and URL:\n\n```python\nprint(f\"Inference service started.\")\nprint(f\"  Job ID : {job_id}\")\nprint(f\"  Arch   : {network_arch}\")\nprint(f\"  URL    : {state[job_id]['host_url']}\u002Fv1\u002Fchat\u002Fcompletions\")\nprint(f\"Use this Job ID to send requests or stop the service.\")\n```\n\nThen poll for readiness — see `references\u002Fcode-templates.yaml` → `readiness_check`. The container loads the model in the background; do not send requests before it returns 200.\n\n---\n\n## 5. Stopping the inference service\n\nAsk the user for the `job_id` to stop. If they don't provide one, default to `state[\"latest\"]` and confirm which job_id is being stopped. Read the registry using `references\u002Fcode-templates.yaml` → `stop.registry_read`, then read **`skills\u002Fplatform\u002F\u003Cplatform>\u002FSKILL.md`** and use its cancellation \u002F stop mechanism.\n\n| Platform | Identifier to pass | Extra cleanup |\n|----------|--------------------|---------------|\n| **local-docker** | `job_id_to_stop` — container name | None |\n| **brev** | `job_id_to_stop` — container name | None |\n| **slurm** | `entry[\"platform_job_id\"]` — SLURM job ID | `pkill -f \"ssh.*-L.*{entry['host_port']}\"` |\n| **kubernetes** | `entry[\"platform_job_id\"]` — k8s job name | `kubectl delete svc {entry[\"platform_job_id\"]} -n \u003Cnamespace>` |\n\nwhere `entry = state[job_id_to_stop]`. After stopping, clean up the registry: `references\u002Fcode-templates.yaml` → `stop.registry_cleanup`.\n\n---\n\n## 6. Sending inference requests\n\n### 6.0 Resolve which service receives this request (REQUIRED)\n\nEach request must be routed to the **specific** service that runs the matching model. Routing happens by `job_id` — the registry stores `network_arch` per entry, so you can resolve a target by arch when the user names a model instead of a `job_id`. Apply these rules in order:\n\n1. **User provided an explicit `job_id`** → use it. Verify it exists in `state`.\n2. **User named a `network_arch`** (e.g. \"send this to the cosmos-rl service\") → look up matching entries: `candidates = [j for j, e in state.items() if j != \"latest\" and isinstance(e, dict) and e[\"network_arch\"] == arch]`.\n   - Exactly one match → use it.\n   - Multiple matches → **prompt the user** with the candidate `job_id`s and their `started_at`; do not auto-pick.\n   - No match → stop and tell the user no service for that arch is running.\n3. **No `job_id` and no `network_arch`** → count non-`\"latest\"` entries in `state`:\n   - Exactly one running service → use it.\n   - Two or more → **do not silently default to `state[\"latest\"]`**. Prompt the user with the full list (`job_id`, `network_arch`, `host_url`) and require an explicit choice. The `\"latest\"` pointer is a convenience for single-service workflows, not a routing fallback when multiple services coexist.\n   - Zero → stop and tell the user to start a service first.\n\nAfter resolving, read the endpoint from the registry (`references\u002Fcode-templates.yaml` → `request.registry_read`), passing the resolved `job_id` as `user_provided_job_id`. Confirm to the user: \"Sending to job_id=… arch=… url=…\". If the service may still be loading, poll readiness first (`references\u002Fcode-templates.yaml` → `readiness_check`).\n\n**Cross-check before sending:** if the user-supplied request body contains arch-specific fields (e.g. `guidance` \u002F `num_steps` \u002F `seed` \u002F `negative_prompt` → cosmos-predict2.5; required `image_url`\u002F`video_url` content items → cosmos-rl), verify they are consistent with `state[job_id][\"network_arch\"]`. On mismatch, stop and ask — sending a cosmos-predict2.5 body to a cosmos-rl service will fail at the container with a 4xx\u002F5xx that is harder to diagnose than catching it here.\n\n### 6.1 Sampling parameters — REQUIRED user prompt before each request\n\nBefore constructing the request body, you **MUST** explicitly prompt the user for the vLLM-style sampling parameters. Do **not** silently apply defaults. Use a structured prompt, one question per field, that:\n\n1. Lists every applicable field with its **type** and **default value**.\n2. Lets the user skip \u002F accept any field to take that field's default — entering a value is never required.\n3. Collects all fields in one round.\n\nAfter the prompt, apply each user-entered value verbatim and substitute the default for any skipped field. Do not invent values or silently clamp.\n\n**Field list, defaults, and per-arch applicability:** `references\u002Frequest.yaml` → `chat_completions_request_body` (base sampling fields: `max_tokens`, `top_p`, `temperature`) and `network_arch_constraints.\u003Cnetwork_arch>` (per-arch overrides and extras such as `guidance`\u002F`num_steps`\u002F`seed`\u002F`negative_prompt` for `cosmos-predict2.5`). If a field is marked unsupported for the active arch, do **not** prompt for it and do **not** include it in the body.\n\n### 6.2 Request format\n\nSend a `POST` to `{BASE_URL}\u002Fv1\u002Fchat\u002Fcompletions` with `Content-Type: application\u002Fjson` and a timeout of **at least 300 s**. The body is OpenAI-compatible (vLLM chat completions); see `references\u002Frequest.yaml` → `chat_completions_request_body` for the full field schema and content-item shapes (text \u002F image_url \u002F video_url), and `code_examples` for ready-to-run Python and curl samples.\n\n**Constraints:** only the first user message is processed. No secret values in request bodies. **Per-network constraints** (e.g. cosmos-rl requires every request to include an image or video; cosmos-rl rejects `data:` URIs) are in `references\u002Frequest.yaml` → `network_arch_constraints`.\n\n### 6.3 Response handling\n\n| HTTP status | Meaning | Action |\n|-------------|---------|--------|\n| **200** | Success — `choices[0].message.content` has the generated text | Read result |\n| **202** | Server still initializing or model still loading | Retry after a delay |\n| **503** | Initialization failed, model load failed, **or model not yet ready** | Inspect `error.type`: `model_not_ready` → retry; `initialization_error` \u002F `model_load_error` → give up and check logs |\n| **400** | Missing or empty JSON body | Fix request |\n| **500** | Unhandled exception during inference | Check container logs |\n\nFor 202 and 503, the body contains `{\"error\": {\"type\": \"\u003Cerror_type>\", \"message\": \"\u003Creason>\"}}`. See `container_response_shapes` in `references\u002Frequest.yaml` for error type strings.\n",{"name":5,"tags":52,"license":15,"metadata":54,"description":57,"allowed-tools":58,"compatibility":59},[30,53,41],"microservice",{"author":55,"version":56},"NVIDIA Corporation","0.1.0","Start, query, and stop a network-specific TAO inference microservice ({network_arch}-inference-microservice) by delegating container execution to the appropriate platform skill. Handles container image resolution, job-payload JSON construction, and the service registry. Use when the user wants to run inference on a TAO model checkpoint using a microservice container, deploy a TAO inference endpoint, or stop a running inference container.\n","Read Bash Write","The inference service has no cloud-storage dependency — model weights come from the HuggingFace Hub (HF_TOKEN env var for gated models) or a local container path. Platform prerequisites are checked by each platform skill.","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Ftao-run-inference-service","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add pattanation\u002FNorvik --skill tao-run-inference-service",{"tool":73,"command":74},"bunx","bunx skills add pattanation\u002FNorvik --skill tao-run-inference-service",{"tool":76,"command":77},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill tao-run-inference-service","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002FSKILL.md",true,[81,87,91,95,99,103,107,111,115,119],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"BENCHMARK.md","REFERENCE","参考文档",3872,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002FBENCHMARK.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Fevals.json",804,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Fevals\u002Fevals.json",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fcode-templates.yaml",16248,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Fcode-templates.yaml",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fcosmos-predict2.5.config.json",183,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Fcosmos-predict2.5.config.json",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Frequest.yaml",11629,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Frequest.yaml",{"path":104,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fservice.yaml",11107,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Fservice.yaml",{"path":108,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fskill_info.yaml",1566,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Fskill_info.yaml",{"path":112,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Ftao-dataservices.config.json",192,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Freferences\u002Ftao-dataservices.config.json",{"path":116,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":117,"sourceHtmlUrl":118},"skill-card.md",3844,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Fskill-card.md",{"path":120,"resourceType":121,"resourceTypeDesc":122,"sizeBytes":123,"sourceHtmlUrl":124},"skill.oms.sig","OTHER","其他",6065,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftao-run-inference-service\u002Fskill.oms.sig",[126,156,182,206,228,243],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":130,"sourceHtmlUrl":131,"categories":132,"keywords":139,"publishedAt":47},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[133,136],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[140,141,142,143,144,44,145,146,147,148,149,150,151,152,153,154,155],"webapp","testing","webapp testing","for","applications","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":160,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":47},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[163],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},[165,166,167,152,168,169,170,143,171,172,145,173,174,175,176,177,178,179,180,181],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":186,"licenseFileUrl":187,"sourceHtmlUrl":188,"categories":189,"keywords":191,"publishedAt":47},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[190],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},[192,193,194,195,196,197,198,199,200,201,202,203,204,205],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":186,"licenseFileUrl":210,"sourceHtmlUrl":211,"categories":212,"keywords":215,"publishedAt":47},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[213,214],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},[216,141,217,203,218,151,219,220,221,198,222,143,223,224,225,174,226,204,227],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":186,"licenseFileUrl":232,"sourceHtmlUrl":233,"categories":234,"keywords":236,"publishedAt":47},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[235],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},[237,203,238,218,239,221,240,198,226,241,242],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":244,"name":245,"nameZh":6,"description":246,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":186,"licenseFileUrl":247,"sourceHtmlUrl":248,"categories":249,"keywords":251,"publishedAt":47},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[250],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},[252,203,218,253,195,254,255,256,237,257,258,259,260,261,262,143,263,174,264,265],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]