[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PGM90YJP0GF4TYDVBYPWPC":3,"skill-same:01M6PGM90YJP0GF4TYDVBYPWPC":100},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":14,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6PGM90YJP0GF4TYDVBYPWPC","launch-nemo-rl",null,"Playbook for launching, monitoring, stopping, and debugging NeMo-RL recipes on a Kubernetes cluster via the nrl-k8s CLI. Covers ephemeral vs long-lived RayCluster modes, iterating on runs, and debugging hung or failed training jobs.","headmktlucca-ui\u002Fneuroads-lp","headmktlucca-ui","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F247379838?v=4","01M6PDVAV6M1W96D1SR1PDF8CS","NeuroAds","01M6PDVAZ4P281GNDKD45CYTF5",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"launch","launch nemo rl","rl","NeMo","run","logs","monitoring","debugging","how","why","Bash","read","write","up","training","back","get","submit","recipe","cli","2026-11-10 10:12:30",false,"---\nname: launch-nemo-rl\nlicense: Apache-2.0\ndescription: Playbook for launching, monitoring, stopping, and debugging NeMo-RL recipes on a Kubernetes cluster via the nrl-k8s CLI. Covers ephemeral vs long-lived RayCluster modes, iterating on runs, and debugging hung or failed training jobs.\nwhen_to_use:\n  - \"run this recipe on k8s\"\n  - \"launch on the cluster\"\n  - \"submit a training job\"\n  - \"tear down the cluster\"\n  - \"resubmit as rayjob\"\n  - \"why is the run stuck\"\n  - \"how do I get logs for job X\"\n  - \"bring the cluster back up\"\nallowed-tools: Bash Read Grep Glob Edit Write\n---\n\n# launch-nemo-rl — running NeMo-RL recipes on Kubernetes via nrl-k8s\n\nThis is the playbook for the `nrl-k8s` CLI at `infra\u002Fnrl_k8s\u002F`. Follow it when the user asks to launch \u002F iterate \u002F debug a NeMo-RL recipe on a Kubernetes cluster. Verify current state (`kubectl`, `git log`, the recipe + infra files) before acting — the cluster is shared and the cost of a wrong action is high.\n\n## 1. One command, two modes\n\nThere is a single top-level submission command: **`nrl-k8s run`**. It has two lifecycle modes.\n\n| Mode               | Invocation        | When to use                                                                                                                                                                   | Cluster after? |\n| :----------------- | :---------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------- |\n| Ephemeral (default)  | `nrl-k8s run`              | One-shot. KubeRay applies a RayJob, runs, tears the cluster down. Best for most runs.                                                                                          | No (auto)      |\n| Long-lived           | `nrl-k8s run --raycluster` | Dev loop. Reuses a matching live cluster, applies if absent, warns + reuses on drift (pass `--recreate` to replace). Then submits daemons and training. First-choice for iteration. | Yes            |\n\nAsk: *Do I need this cluster after the run?* If yes, use `--raycluster`. Otherwise use the default (ephemeral).\n\nThe rest of the CLI is observability \u002F stage-by-stage control:\n\n| Command                 | Purpose                                                                                         |\n| :---------------------- | :---------------------------------------------------------------------------------------------- |\n| `nrl-k8s check`         | Validate a recipe + infra pair; optionally write the fully-resolved manifests (`-o`).           |\n| `nrl-k8s status`        | Per-role RayCluster state, head pod phase, worker pod phases, daemon job status.                |\n| `nrl-k8s cluster up\u002Fdown\u002Flist\u002Fdashboard` | Manage RayClusters independently of a run (e.g. render a manifest with `--dry-run`). |\n| `nrl-k8s job list\u002Flogs\u002Fstop` | Observability over Ray Jobs already submitted to a role's cluster.                         |\n| `nrl-k8s logs`          | Tail a role's pod \u002F daemon logs without needing a submission id.                                |\n\n## 2. Recipe + infra pair\n\nEvery launch takes two files. Pass the infra with `--infra`, not merged inline:\n\n```\nnrl-k8s run infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.yaml \\\n  --infra infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.\u003Cprofile>.infra.yaml\n```\n\n- **Recipe** (e.g. `qwen3_30b_math_8n_4gpu.yaml`) — NeMo-RL config: model, GRPO\u002FSFT knobs, `cluster.{gpus_per_node,num_nodes}`. Uses `defaults:` to inherit from `examples\u002Fconfigs\u002Frecipes\u002Fllm\u002F...`.\n- **Infra** (e.g. `*.\u003Cprofile>.infra.yaml`) — K8s\u002FRay shape: namespace, image, service account, RayCluster spec under `kuberay:`, optional Deployments under `deployments:`, `submit.submitter`, `launch.{mode,codeSource,codePath,entrypoint}`. Pair names follow `\u003Crecipe>.\u003Cprofile>[.prod].infra.yaml` where `\u003Cprofile>` names the hardware target (e.g. `gb300`).\n\nExample pairs in `infra\u002Fnrl_k8s\u002Fexamples\u002F` — read the neighbouring files to see the current conventions for the target profile.\n\n## 3. Long-lived mode flags\n\nThree independent dimensions. `--mode` is a macro that picks defaults; individual flags override it.\n\n```\n--mode interactive   → --submitter portForward  --code-source upload  (tails logs)\n--mode batch         → --submitter exec         --code-source image   (returns after nohup)\n```\n\n- **Submitter**: `portForward` uses `kubectl port-forward` + Ray Job SDK (gets a `submission_id` the dashboard tracks). `exec` uses `kubectl exec` + `nohup` on the head pod (no submission_id; driver appears as `type=DRIVER` in the dashboard).\n- **Code source**: `upload` stages a working_dir from the laptop (Ray 100 MiB cap). `image` \u002F `lustre` expect code on the pod's filesystem — paired with `--code-path` (typically `\u002Fopt\u002Fnemo-rl`), which is a subPath of the shared-filesystem PVC mount in the standard infra examples.\n- **Wait**: `--wait` tails logs until terminal; `--no-wait` returns as soon as the driver is running.\n\nOther long-lived-only flags:\n\n- `--replace` — stop any running training \u002F daemon job before submitting new ones (suffixes daemon submissionIds with a timestamp so Ray accepts the resubmit).\n- `--recreate` — delete + re-apply a RayCluster whose live spec has drifted from the rendered manifest (default is warn + reuse).\n- `--skip-daemons` — bring up all declared clusters but only submit training. Use on disagg recipes where gym\u002Fgeneration are already healthy.\n\nGotcha: on infra where the entrypoint does `cd \u002Fopt\u002Fnemo-rl` (or another in-image \u002F Lustre path) and loads the recipe from there, **`--code-source upload` does NOT override the recipe on the pod** — the uploaded working_dir sits in `\u002Ftmp\u002Fray\u002F...` but the entrypoint `cd`s away from it. To actually test a local recipe change, either sync your edits to the shared filesystem mounted into the pods or flip the Hydra overrides in the entrypoint.\n\n## 4. Ephemeral mode flags (`--rayjob`)\n\nWhen `--rayjob` is set, `run` branches into the RayJob code path. Relevant flags:\n\n- `--rayjob-name NAME` — RayJob metadata name (defaults to the training cluster name).\n- `--shutdown \u002F --no-shutdown` — default `true`: KubeRay deletes the RayCluster once the Ray Job reaches a terminal state.\n- `--ttl SECONDS` — default 3600s: keep the RayJob object around after the run finishes for post-mortem log access.\n- `--wait \u002F --no-wait` — default `wait`: poll `jobDeploymentStatus` until Complete\u002FFailed. `--no-wait` returns as soon as the RayJob is applied.\n- `--timeout SECONDS` — default 86400s (24h): bound the `--wait` poll.\n- `--dry-run` — render the RayJob manifest and print it; do not apply.\n\n`--replace` \u002F `--recreate` \u002F `--skip-daemons` are silently ignored in `--rayjob` mode (KubeRay owns lifecycle).\n\n## 5. Iterating on a config without touching the shared filesystem\n\nWhen the recipe on the pod filesystem has the wrong value for your experiment, use Hydra overrides on the entrypoint instead of forking the recipe. Pattern:\n\n```yaml\nentrypoint: |\n  set -eu\n  cd \u002Fopt\u002Fnemo-rl\n  RUN_ID=\"\\${RAY_JOB_SUBMISSION_ID:-\\${NRL_K8S_RUN_ID:-$(date -u +%Y%m%d-%H%M%S)}}\"\n  python -u examples\u002Frun_grpo.py \\\n    --config infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.yaml \\\n    logger.wandb_enabled=true \\\n    logger.wandb.project=\u003Cproject> \\\n    \"logger.wandb.name=\u003Crun-name>-\\${RUN_ID}\"\n```\n\n**Escape `${…}`** with a backslash. OmegaConf otherwise interprets it as interpolation and errors on shell-style `${VAR:-default}`. `RUN_ID` resolves to `RAY_JOB_SUBMISSION_ID` (injected by KubeRay in rayjob mode) → `NRL_K8S_RUN_ID` (injected by the CLI in long-lived mode) → local timestamp — so the name is unique across either path.\n\n## 6. Per-profile concerns (hardware + scheduler + DRA)\n\nEvery infra YAML encodes a hardware\u002Fscheduler profile. The concrete examples in `infra\u002Fnrl_k8s\u002Fexamples\u002F` are authoritative for the profiles they target — read the neighbouring infra file before writing a new one. Things that commonly vary:\n\n- **Per-node GPUs** (e.g. 4 vs 8) — must match `cluster.gpus_per_node` in the recipe, otherwise workers stay `Pending`.\n- **Node selectors** — head pods usually land on a CPU-only node pool; GPU workers match on `nvidia.com\u002Fgpu.product` or a node-group label.\n- **Scheduler** — KAI (`schedulerName: kai-scheduler` + `kai.scheduler\u002Fqueue` label) with topology annotations (`kai.scheduler\u002Ftopology`, `kai.scheduler\u002Ftopology-required-placement`) gang-schedules workers into one clique. Without it, pods may land on different racks and NVLink\u002FRoCE won't span them.\n- **DRA claims** — ComputeDomain + RoCE are attached via `resourceClaims` referencing `ResourceClaimTemplate`s. The CLI auto-creates\u002Fdeletes these when the worker pod spec contains DRA claim references — no manual setup needed.\n- **Secrets** — always via `secretKeyRef` (`wandb-api-key`, image pull secret). Never embed.\n- **Shared filesystem mounts** — typically a Lustre PVC mounted twice: once at the code path (e.g. `\u002Fopt\u002Fnemo-rl` with a user-scoped `subPath`) and once at a workspace root (e.g. `\u002Fmnt\u002Frl-workspace`) for datasets, HF cache, and checkpoints.\n\nBefore applying an infra, verify prereqs exist in the target namespace:\n\n```bash\nkubectl get pvc \u003Cworkspace-pvc>\nkubectl get secret \u003Cwandb-secret> \u003Cimage-pull-secret>\nkubectl get sa \u003Cservice-account>\n```\n\n## 7. End-to-end workflows\n\n### 7a. Fresh one-shot run (rayjob)\n```bash\n# From the NeMo-RL repo root:\nnrl-k8s check \u003Crecipe> --infra \u003Cinfra>                               # validate first\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --rayjob --dry-run              # render RayJob manifest\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --rayjob --no-wait              # apply, returns fast\n```\n\nWatch status + teardown (works even after your laptop disconnects because KubeRay owns the lifecycle):\n```bash\nkubectl get rayjob -n default \u003Cname> -w\nkubectl get raycluster -n default                                    # empty = teardown succeeded\n```\n\n### 7b. Dev loop (long-lived)\n```bash\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --run-id $(date +%Y%m%d-%H%M%S)\n# Edits in the recipe? Just re-run — reuses the live cluster.\n# Pod spec changed? Add --recreate to delete + re-apply.\n# Disagg recipe with gym\u002Fgen already healthy? --skip-daemons.\n```\n\n### 7c. First-time disaggregated bring-up\n```bash\nnrl-k8s run \u003Crecipe> --infra \u003Cdisagg-infra> --mode batch --code-source image\n```\n\n### 7d. Cluster-only lifecycle\n```bash\nnrl-k8s cluster up   \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait\nnrl-k8s cluster up   \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --dry-run   # render manifest\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra>                                       # tear down all\nnrl-k8s cluster list -n default\nnrl-k8s cluster dashboard \u003Ccluster-name>                                  # port-forward + browser\n```\n\n### 7e. Deployments (e.g. nemo-skills sandbox)\n```bash\n# Bring up just the deployment\nnrl-k8s cluster up \u003Crecipe> --infra \u003Cinfra> --target deployments.nemo_skills\n# Tear down just the deployment\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target deployments.nemo_skills\n# Tear down everything (RayClusters + Deployments)\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra>\n```\n\nThe `deployments:` section in infra YAML declares Kubernetes Deployments managed alongside RayClusters. The CLI patches image, imagePullSecrets, and serviceAccountName from the top-level infra keys (same as RayClusters). Deployments start in parallel with cluster bring-up — no ordering dependency.\n\n## 8. Monitoring a run\n\n```bash\n# Status\nnrl-k8s status \u003Crecipe> --infra \u003Cinfra>\nkubectl get rayjob,raycluster -n default\n\n# Follow the driver\nnrl-k8s job list \u003Crecipe> --infra \u003Cinfra> --role training\nnrl-k8s job logs \u003Crun-id> \u003Crecipe> --infra \u003Cinfra> --role training -f\n```\n\nWhen the `nrl-k8s job logs -f` subprocess dies (`kubectl port-forward` i\u002Fo timeout after ~15 min idle), just re-run it. The training job keeps going.\n\nTo fetch driver logs for a terminal job (SUCCEEDED\u002FFAILED) or a RayJob via the dashboard API:\n```bash\nRC=$(kubectl get rayjob -n default \u003Crayjob-name> -o jsonpath='{.status.rayClusterName}')\nkubectl port-forward -n default svc\u002F${RC}-head-svc 18266:8265 &\ncurl -s http:\u002F\u002Flocalhost:18266\u002Fapi\u002Fjobs\u002F                              # lists jobs, find submission_id\ncurl -s \"http:\u002F\u002Flocalhost:18266\u002Fapi\u002Fjobs\u002F\u003Csubmission_id>\u002Flogs\"        # full driver log\n```\n\n`type=DRIVER` with `submission_id=null` means an exec-submitter run (no dashboard log endpoint — use `nrl-k8s job logs` instead). `type=SUBMISSION` has `submission_id` set and `\u002Fapi\u002Fjobs\u002F\u003Cid>\u002Flogs` works.\n\nWandb URL appears in the driver log on the first `wandb.init` call; grep `grep -oE 'https:\u002F\u002Fwandb\\.ai\u002F[A-Za-z0-9_.\u002F-]+'`.\n\n## 9. Stopping things\n\n| What to stop                     | Command                                                                              |\n| :------------------------------- | :----------------------------------------------------------------------------------- |\n| One training run                 | `nrl-k8s job stop \u003Crun-id> \u003Crecipe> --infra \u003Cinfra> --role training`                 |\n| All running Ray jobs on a cluster (+ submit new) | `nrl-k8s run \u003Crecipe> --infra \u003Cinfra> --replace`                         |\n| A long-lived RayCluster          | `nrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait`     |\n| A RayJob (ephemeral)             | `kubectl delete rayjob \u003Cname> -n default` — only if `shutdownAfterJobFinishes` didn't fire |\n\nConfirm before deleting shared infra. The cost of `cluster down` on someone else's cluster is high.\n\n## 10. Verifying RayJob teardown\n\nAfter a `run --rayjob` completes with `--shutdown` (default), KubeRay should delete the RayCluster:\n\n```bash\nkubectl get rayjob   -n default \u003Crayjob-name>                        # jobDeploymentStatus = Complete\nkubectl get raycluster -n default | grep \u003Crayjob-name>               # no output = torn down\n```\n\nThe RayJob object itself sticks around for `--ttl` seconds (default 3600s) so you can still fetch logs.\n\n## 11. Common gotchas\n\n- **OmegaConf interpolation** eats `${VAR}` in recipe\u002Finfra YAML. Escape shell variables with `\\${VAR}` so OmegaConf passes them through to the pod shell verbatim.\n- **Megatron optimizer configs** don't carry `foreach` \u002F `fused`. Overrides like `~policy.optimizer.kwargs.foreach ~policy.optimizer.kwargs.fused` (valid for DTensor configs) break on Megatron recipes. Omit them for Megatron.\n- **DTensor vs Megatron** — MoE recipes typically use `megatron_cfg.enabled=true`; ensure `dtensor_cfg.enabled=false` in inherited defaults.\n- **Shared filesystem vs git divergence** — `codeSource: image|lustre` reads from the pod filesystem. If your local edits aren't on the shared filesystem the pods mount, the run is testing the on-disk version, not yours. Either sync via a helper pod (head pod exec is often blocked) or override via Hydra flags.\n- **Ephemeral-storage + readinessProbe** are injected by kuberay\u002FCDI webhooks at pod-apply time. Do NOT add them to the inline RayCluster spec.\n- **Node taints** vary per cluster. `tolerations: [{operator: Exists}]` on workers is defensive and worth keeping.\n- **Dashboard blank page** — Ray 2.52 installs dashboard assets as symlinks by default; `nrl-k8s cluster dashboard \u003Cname>` auto-reinstalls `ray[default] --link-mode=copy` to fix it. Bake `ENV UV_LINK_MODE=copy` in the image to avoid this entirely.\n- **`kubectl exec` is usually blocked** in automation — route around with `kubectl get ... -o yaml`, `kubectl logs`, and `kubectl port-forward` + Ray dashboard APIs.\n\n## 12. Checklist before calling a run \"done\"\n\nBefore reporting a launch as successful, verify:\n\n1. `kubectl get rayjob\u002Fraycluster -n default` shows the expected objects.\n2. `nrl-k8s job list` (or `curl \u002Fapi\u002Fjobs\u002F`) shows the job in `RUNNING` \u002F `SUCCEEDED`.\n3. Driver log contains `wandb.ai\u002F\u003Cproject>\u002Fruns\u002F\u003Cid>` (if wandb is enabled) — share the URL with the user.\n4. At least one `Processed prompts: 100%` line appears (confirms generation is wired).\n5. For `--rayjob` mode only: after `jobDeploymentStatus=Complete`, confirm `kubectl get raycluster | grep \u003Cname>` is empty (teardown worked).\n\n## 13. Dev pod\n\n`nrl-k8s dev` manages a lightweight CPU pod on the cluster for code syncing, debugging, and running `kubectl`\u002F`nrl-k8s` from within the cluster.\n\n```bash\n# One-time: set up secrets (HF token, wandb, SSH key, rclone)\nnrl-k8s dev setup-secrets --ssh-key ~\u002F.ssh\u002Fid_rsa --add-rclone\n\n# Create pod and exec in (idempotent — reuses existing pod)\nnrl-k8s dev connect\n\n# Switch image (must stop first — image change is warned but not auto-applied)\nnrl-k8s dev stop\nnrl-k8s dev connect --image nvcr.io\u002Fnvidian\u002Fnemo-rl:v0.7.0\n\n# Tear down\nnrl-k8s dev stop\n```\n\nThe dev pod:\n- Runs on a CPU-only node (anti-affinity to GPU nodes)\n- Mounts the shared `rl-workspace` PVC at `\u002Fmnt\u002Frl-workspace`\n- Sets `USER` env var to the `nrl-k8s` username (so `$USER` and `getpass.getuser()` work correctly despite running as root)\n- Installs `kubectl`, `rclone` (if configured) on first boot\n- Injects SSH keys and tokens via `envFrom` on a per-user K8s Secret\n\nThe pod's `default` service account needs an `edit` RoleBinding in the namespace for `kubectl` to work inside. `dev connect` checks this and prints the required YAML if missing.\n\n## 14. Where things live in the repo\n\n- CLI code: `infra\u002Fnrl_k8s\u002Fsrc\u002Fnrl_k8s\u002F` (`cli.py`, `orchestrate.py`, `manifest.py`, `rayjob.py`, `k8s.py`, `submitters\u002F`, `schema.py`).\n- Tests: `infra\u002Fnrl_k8s\u002Ftests\u002Funit\u002F` — run with `uv run --extra test pytest -x -q` from `infra\u002Fnrl_k8s\u002F`.\n- Recipe + infra examples: `infra\u002Fnrl_k8s\u002Fexamples\u002F`.\n- Base recipes this tool wraps: `examples\u002Fconfigs\u002Frecipes\u002Fllm\u002F…` and `examples\u002Fnemo_gym\u002F…`.\n","# launch-nemo-rl — running NeMo-RL recipes on Kubernetes via nrl-k8s\n\nThis is the playbook for the `nrl-k8s` CLI at `infra\u002Fnrl_k8s\u002F`. Follow it when the user asks to launch \u002F iterate \u002F debug a NeMo-RL recipe on a Kubernetes cluster. Verify current state (`kubectl`, `git log`, the recipe + infra files) before acting — the cluster is shared and the cost of a wrong action is high.\n\n## 1. One command, two modes\n\nThere is a single top-level submission command: **`nrl-k8s run`**. It has two lifecycle modes.\n\n| Mode               | Invocation        | When to use                                                                                                                                                                   | Cluster after? |\n| :----------------- | :---------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------- |\n| Ephemeral (default)  | `nrl-k8s run`              | One-shot. KubeRay applies a RayJob, runs, tears the cluster down. Best for most runs.                                                                                          | No (auto)      |\n| Long-lived           | `nrl-k8s run --raycluster` | Dev loop. Reuses a matching live cluster, applies if absent, warns + reuses on drift (pass `--recreate` to replace). Then submits daemons and training. First-choice for iteration. | Yes            |\n\nAsk: *Do I need this cluster after the run?* If yes, use `--raycluster`. Otherwise use the default (ephemeral).\n\nThe rest of the CLI is observability \u002F stage-by-stage control:\n\n| Command                 | Purpose                                                                                         |\n| :---------------------- | :---------------------------------------------------------------------------------------------- |\n| `nrl-k8s check`         | Validate a recipe + infra pair; optionally write the fully-resolved manifests (`-o`).           |\n| `nrl-k8s status`        | Per-role RayCluster state, head pod phase, worker pod phases, daemon job status.                |\n| `nrl-k8s cluster up\u002Fdown\u002Flist\u002Fdashboard` | Manage RayClusters independently of a run (e.g. render a manifest with `--dry-run`). |\n| `nrl-k8s job list\u002Flogs\u002Fstop` | Observability over Ray Jobs already submitted to a role's cluster.                         |\n| `nrl-k8s logs`          | Tail a role's pod \u002F daemon logs without needing a submission id.                                |\n\n## 2. Recipe + infra pair\n\nEvery launch takes two files. Pass the infra with `--infra`, not merged inline:\n\n```\nnrl-k8s run infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.yaml \\\n  --infra infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.\u003Cprofile>.infra.yaml\n```\n\n- **Recipe** (e.g. `qwen3_30b_math_8n_4gpu.yaml`) — NeMo-RL config: model, GRPO\u002FSFT knobs, `cluster.{gpus_per_node,num_nodes}`. Uses `defaults:` to inherit from `examples\u002Fconfigs\u002Frecipes\u002Fllm\u002F...`.\n- **Infra** (e.g. `*.\u003Cprofile>.infra.yaml`) — K8s\u002FRay shape: namespace, image, service account, RayCluster spec under `kuberay:`, optional Deployments under `deployments:`, `submit.submitter`, `launch.{mode,codeSource,codePath,entrypoint}`. Pair names follow `\u003Crecipe>.\u003Cprofile>[.prod].infra.yaml` where `\u003Cprofile>` names the hardware target (e.g. `gb300`).\n\nExample pairs in `infra\u002Fnrl_k8s\u002Fexamples\u002F` — read the neighbouring files to see the current conventions for the target profile.\n\n## 3. Long-lived mode flags\n\nThree independent dimensions. `--mode` is a macro that picks defaults; individual flags override it.\n\n```\n--mode interactive   → --submitter portForward  --code-source upload  (tails logs)\n--mode batch         → --submitter exec         --code-source image   (returns after nohup)\n```\n\n- **Submitter**: `portForward` uses `kubectl port-forward` + Ray Job SDK (gets a `submission_id` the dashboard tracks). `exec` uses `kubectl exec` + `nohup` on the head pod (no submission_id; driver appears as `type=DRIVER` in the dashboard).\n- **Code source**: `upload` stages a working_dir from the laptop (Ray 100 MiB cap). `image` \u002F `lustre` expect code on the pod's filesystem — paired with `--code-path` (typically `\u002Fopt\u002Fnemo-rl`), which is a subPath of the shared-filesystem PVC mount in the standard infra examples.\n- **Wait**: `--wait` tails logs until terminal; `--no-wait` returns as soon as the driver is running.\n\nOther long-lived-only flags:\n\n- `--replace` — stop any running training \u002F daemon job before submitting new ones (suffixes daemon submissionIds with a timestamp so Ray accepts the resubmit).\n- `--recreate` — delete + re-apply a RayCluster whose live spec has drifted from the rendered manifest (default is warn + reuse).\n- `--skip-daemons` — bring up all declared clusters but only submit training. Use on disagg recipes where gym\u002Fgeneration are already healthy.\n\nGotcha: on infra where the entrypoint does `cd \u002Fopt\u002Fnemo-rl` (or another in-image \u002F Lustre path) and loads the recipe from there, **`--code-source upload` does NOT override the recipe on the pod** — the uploaded working_dir sits in `\u002Ftmp\u002Fray\u002F...` but the entrypoint `cd`s away from it. To actually test a local recipe change, either sync your edits to the shared filesystem mounted into the pods or flip the Hydra overrides in the entrypoint.\n\n## 4. Ephemeral mode flags (`--rayjob`)\n\nWhen `--rayjob` is set, `run` branches into the RayJob code path. Relevant flags:\n\n- `--rayjob-name NAME` — RayJob metadata name (defaults to the training cluster name).\n- `--shutdown \u002F --no-shutdown` — default `true`: KubeRay deletes the RayCluster once the Ray Job reaches a terminal state.\n- `--ttl SECONDS` — default 3600s: keep the RayJob object around after the run finishes for post-mortem log access.\n- `--wait \u002F --no-wait` — default `wait`: poll `jobDeploymentStatus` until Complete\u002FFailed. `--no-wait` returns as soon as the RayJob is applied.\n- `--timeout SECONDS` — default 86400s (24h): bound the `--wait` poll.\n- `--dry-run` — render the RayJob manifest and print it; do not apply.\n\n`--replace` \u002F `--recreate` \u002F `--skip-daemons` are silently ignored in `--rayjob` mode (KubeRay owns lifecycle).\n\n## 5. Iterating on a config without touching the shared filesystem\n\nWhen the recipe on the pod filesystem has the wrong value for your experiment, use Hydra overrides on the entrypoint instead of forking the recipe. Pattern:\n\n```yaml\nentrypoint: |\n  set -eu\n  cd \u002Fopt\u002Fnemo-rl\n  RUN_ID=\"\\${RAY_JOB_SUBMISSION_ID:-\\${NRL_K8S_RUN_ID:-$(date -u +%Y%m%d-%H%M%S)}}\"\n  python -u examples\u002Frun_grpo.py \\\n    --config infra\u002Fnrl_k8s\u002Fexamples\u002F\u003Crecipe>.yaml \\\n    logger.wandb_enabled=true \\\n    logger.wandb.project=\u003Cproject> \\\n    \"logger.wandb.name=\u003Crun-name>-\\${RUN_ID}\"\n```\n\n**Escape `${…}`** with a backslash. OmegaConf otherwise interprets it as interpolation and errors on shell-style `${VAR:-default}`. `RUN_ID` resolves to `RAY_JOB_SUBMISSION_ID` (injected by KubeRay in rayjob mode) → `NRL_K8S_RUN_ID` (injected by the CLI in long-lived mode) → local timestamp — so the name is unique across either path.\n\n## 6. Per-profile concerns (hardware + scheduler + DRA)\n\nEvery infra YAML encodes a hardware\u002Fscheduler profile. The concrete examples in `infra\u002Fnrl_k8s\u002Fexamples\u002F` are authoritative for the profiles they target — read the neighbouring infra file before writing a new one. Things that commonly vary:\n\n- **Per-node GPUs** (e.g. 4 vs 8) — must match `cluster.gpus_per_node` in the recipe, otherwise workers stay `Pending`.\n- **Node selectors** — head pods usually land on a CPU-only node pool; GPU workers match on `nvidia.com\u002Fgpu.product` or a node-group label.\n- **Scheduler** — KAI (`schedulerName: kai-scheduler` + `kai.scheduler\u002Fqueue` label) with topology annotations (`kai.scheduler\u002Ftopology`, `kai.scheduler\u002Ftopology-required-placement`) gang-schedules workers into one clique. Without it, pods may land on different racks and NVLink\u002FRoCE won't span them.\n- **DRA claims** — ComputeDomain + RoCE are attached via `resourceClaims` referencing `ResourceClaimTemplate`s. The CLI auto-creates\u002Fdeletes these when the worker pod spec contains DRA claim references — no manual setup needed.\n- **Secrets** — always via `secretKeyRef` (`wandb-api-key`, image pull secret). Never embed.\n- **Shared filesystem mounts** — typically a Lustre PVC mounted twice: once at the code path (e.g. `\u002Fopt\u002Fnemo-rl` with a user-scoped `subPath`) and once at a workspace root (e.g. `\u002Fmnt\u002Frl-workspace`) for datasets, HF cache, and checkpoints.\n\nBefore applying an infra, verify prereqs exist in the target namespace:\n\n```bash\nkubectl get pvc \u003Cworkspace-pvc>\nkubectl get secret \u003Cwandb-secret> \u003Cimage-pull-secret>\nkubectl get sa \u003Cservice-account>\n```\n\n## 7. End-to-end workflows\n\n### 7a. Fresh one-shot run (rayjob)\n```bash\n# From the NeMo-RL repo root:\nnrl-k8s check \u003Crecipe> --infra \u003Cinfra>                               # validate first\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --rayjob --dry-run              # render RayJob manifest\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --rayjob --no-wait              # apply, returns fast\n```\n\nWatch status + teardown (works even after your laptop disconnects because KubeRay owns the lifecycle):\n```bash\nkubectl get rayjob -n default \u003Cname> -w\nkubectl get raycluster -n default                                    # empty = teardown succeeded\n```\n\n### 7b. Dev loop (long-lived)\n```bash\nnrl-k8s run \u003Crecipe> --infra \u003Cinfra> --run-id $(date +%Y%m%d-%H%M%S)\n# Edits in the recipe? Just re-run — reuses the live cluster.\n# Pod spec changed? Add --recreate to delete + re-apply.\n# Disagg recipe with gym\u002Fgen already healthy? --skip-daemons.\n```\n\n### 7c. First-time disaggregated bring-up\n```bash\nnrl-k8s run \u003Crecipe> --infra \u003Cdisagg-infra> --mode batch --code-source image\n```\n\n### 7d. Cluster-only lifecycle\n```bash\nnrl-k8s cluster up   \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait\nnrl-k8s cluster up   \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --dry-run   # render manifest\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra>                                       # tear down all\nnrl-k8s cluster list -n default\nnrl-k8s cluster dashboard \u003Ccluster-name>                                  # port-forward + browser\n```\n\n### 7e. Deployments (e.g. nemo-skills sandbox)\n```bash\n# Bring up just the deployment\nnrl-k8s cluster up \u003Crecipe> --infra \u003Cinfra> --target deployments.nemo_skills\n# Tear down just the deployment\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target deployments.nemo_skills\n# Tear down everything (RayClusters + Deployments)\nnrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra>\n```\n\nThe `deployments:` section in infra YAML declares Kubernetes Deployments managed alongside RayClusters. The CLI patches image, imagePullSecrets, and serviceAccountName from the top-level infra keys (same as RayClusters). Deployments start in parallel with cluster bring-up — no ordering dependency.\n\n## 8. Monitoring a run\n\n```bash\n# Status\nnrl-k8s status \u003Crecipe> --infra \u003Cinfra>\nkubectl get rayjob,raycluster -n default\n\n# Follow the driver\nnrl-k8s job list \u003Crecipe> --infra \u003Cinfra> --role training\nnrl-k8s job logs \u003Crun-id> \u003Crecipe> --infra \u003Cinfra> --role training -f\n```\n\nWhen the `nrl-k8s job logs -f` subprocess dies (`kubectl port-forward` i\u002Fo timeout after ~15 min idle), just re-run it. The training job keeps going.\n\nTo fetch driver logs for a terminal job (SUCCEEDED\u002FFAILED) or a RayJob via the dashboard API:\n```bash\nRC=$(kubectl get rayjob -n default \u003Crayjob-name> -o jsonpath='{.status.rayClusterName}')\nkubectl port-forward -n default svc\u002F${RC}-head-svc 18266:8265 &\ncurl -s http:\u002F\u002Flocalhost:18266\u002Fapi\u002Fjobs\u002F                              # lists jobs, find submission_id\ncurl -s \"http:\u002F\u002Flocalhost:18266\u002Fapi\u002Fjobs\u002F\u003Csubmission_id>\u002Flogs\"        # full driver log\n```\n\n`type=DRIVER` with `submission_id=null` means an exec-submitter run (no dashboard log endpoint — use `nrl-k8s job logs` instead). `type=SUBMISSION` has `submission_id` set and `\u002Fapi\u002Fjobs\u002F\u003Cid>\u002Flogs` works.\n\nWandb URL appears in the driver log on the first `wandb.init` call; grep `grep -oE 'https:\u002F\u002Fwandb\\.ai\u002F[A-Za-z0-9_.\u002F-]+'`.\n\n## 9. Stopping things\n\n| What to stop                     | Command                                                                              |\n| :------------------------------- | :----------------------------------------------------------------------------------- |\n| One training run                 | `nrl-k8s job stop \u003Crun-id> \u003Crecipe> --infra \u003Cinfra> --role training`                 |\n| All running Ray jobs on a cluster (+ submit new) | `nrl-k8s run \u003Crecipe> --infra \u003Cinfra> --replace`                         |\n| A long-lived RayCluster          | `nrl-k8s cluster down \u003Crecipe> --infra \u003Cinfra> --target kuberay.training --wait`     |\n| A RayJob (ephemeral)             | `kubectl delete rayjob \u003Cname> -n default` — only if `shutdownAfterJobFinishes` didn't fire |\n\nConfirm before deleting shared infra. The cost of `cluster down` on someone else's cluster is high.\n\n## 10. Verifying RayJob teardown\n\nAfter a `run --rayjob` completes with `--shutdown` (default), KubeRay should delete the RayCluster:\n\n```bash\nkubectl get rayjob   -n default \u003Crayjob-name>                        # jobDeploymentStatus = Complete\nkubectl get raycluster -n default | grep \u003Crayjob-name>               # no output = torn down\n```\n\nThe RayJob object itself sticks around for `--ttl` seconds (default 3600s) so you can still fetch logs.\n\n## 11. Common gotchas\n\n- **OmegaConf interpolation** eats `${VAR}` in recipe\u002Finfra YAML. Escape shell variables with `\\${VAR}` so OmegaConf passes them through to the pod shell verbatim.\n- **Megatron optimizer configs** don't carry `foreach` \u002F `fused`. Overrides like `~policy.optimizer.kwargs.foreach ~policy.optimizer.kwargs.fused` (valid for DTensor configs) break on Megatron recipes. Omit them for Megatron.\n- **DTensor vs Megatron** — MoE recipes typically use `megatron_cfg.enabled=true`; ensure `dtensor_cfg.enabled=false` in inherited defaults.\n- **Shared filesystem vs git divergence** — `codeSource: image|lustre` reads from the pod filesystem. If your local edits aren't on the shared filesystem the pods mount, the run is testing the on-disk version, not yours. Either sync via a helper pod (head pod exec is often blocked) or override via Hydra flags.\n- **Ephemeral-storage + readinessProbe** are injected by kuberay\u002FCDI webhooks at pod-apply time. Do NOT add them to the inline RayCluster spec.\n- **Node taints** vary per cluster. `tolerations: [{operator: Exists}]` on workers is defensive and worth keeping.\n- **Dashboard blank page** — Ray 2.52 installs dashboard assets as symlinks by default; `nrl-k8s cluster dashboard \u003Cname>` auto-reinstalls `ray[default] --link-mode=copy` to fix it. Bake `ENV UV_LINK_MODE=copy` in the image to avoid this entirely.\n- **`kubectl exec` is usually blocked** in automation — route around with `kubectl get ... -o yaml`, `kubectl logs`, and `kubectl port-forward` + Ray dashboard APIs.\n\n## 12. Checklist before calling a run \"done\"\n\nBefore reporting a launch as successful, verify:\n\n1. `kubectl get rayjob\u002Fraycluster -n default` shows the expected objects.\n2. `nrl-k8s job list` (or `curl \u002Fapi\u002Fjobs\u002F`) shows the job in `RUNNING` \u002F `SUCCEEDED`.\n3. Driver log contains `wandb.ai\u002F\u003Cproject>\u002Fruns\u002F\u003Cid>` (if wandb is enabled) — share the URL with the user.\n4. At least one `Processed prompts: 100%` line appears (confirms generation is wired).\n5. For `--rayjob` mode only: after `jobDeploymentStatus=Complete`, confirm `kubectl get raycluster | grep \u003Cname>` is empty (teardown worked).\n\n## 13. Dev pod\n\n`nrl-k8s dev` manages a lightweight CPU pod on the cluster for code syncing, debugging, and running `kubectl`\u002F`nrl-k8s` from within the cluster.\n\n```bash\n# One-time: set up secrets (HF token, wandb, SSH key, rclone)\nnrl-k8s dev setup-secrets --ssh-key ~\u002F.ssh\u002Fid_rsa --add-rclone\n\n# Create pod and exec in (idempotent — reuses existing pod)\nnrl-k8s dev connect\n\n# Switch image (must stop first — image change is warned but not auto-applied)\nnrl-k8s dev stop\nnrl-k8s dev connect --image nvcr.io\u002Fnvidian\u002Fnemo-rl:v0.7.0\n\n# Tear down\nnrl-k8s dev stop\n```\n\nThe dev pod:\n- Runs on a CPU-only node (anti-affinity to GPU nodes)\n- Mounts the shared `rl-workspace` PVC at `\u002Fmnt\u002Frl-workspace`\n- Sets `USER` env var to the `nrl-k8s` username (so `$USER` and `getpass.getuser()` work correctly despite running as root)\n- Installs `kubectl`, `rclone` (if configured) on first boot\n- Injects SSH keys and tokens via `envFrom` on a per-user K8s Secret\n\nThe pod's `default` service account needs an `edit` RoleBinding in the namespace for `kubectl` to work inside. `dev connect` checks this and prints the required YAML if missing.\n\n## 14. Where things live in the repo\n\n- CLI code: `infra\u002Fnrl_k8s\u002Fsrc\u002Fnrl_k8s\u002F` (`cli.py`, `orchestrate.py`, `manifest.py`, `rayjob.py`, `k8s.py`, `submitters\u002F`, `schema.py`).\n- Tests: `infra\u002Fnrl_k8s\u002Ftests\u002Funit\u002F` — run with `uv run --extra test pytest -x -q` from `infra\u002Fnrl_k8s\u002F`.\n- Recipe + infra examples: `infra\u002Fnrl_k8s\u002Fexamples\u002F`.\n- Base recipes this tool wraps: `examples\u002Fconfigs\u002Frecipes\u002Fllm\u002F…` and `examples\u002Fnemo_gym\u002F…`.\n",{"name":5,"license":15,"description":7,"when_to_use":49,"allowed-tools":58},[50,51,52,53,54,55,56,57],"run this recipe on k8s","launch on the cluster","submit a training job","tear down the cluster","resubmit as rayjob","why is the run stuck","how do I get logs for job X","bring the cluster back up","Bash Read Grep Glob Edit Write","main","7a940b8e5af16c95e5c190a524421d32fc7445a9",".agent\u002Fskills\u002Flaunch-nemo-rl","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui","https:\u002F\u002Fneuroads.com.br","2026-08-12 00:42:44",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add headmktlucca-ui\u002Fneuroads-lp --skill launch-nemo-rl",{"tool":72,"command":73},"bunx","bunx skills add headmktlucca-ui\u002Fneuroads-lp --skill launch-nemo-rl",{"tool":75,"command":76},"pnpm","pnpm dlx skills add headmktlucca-ui\u002Fneuroads-lp --skill launch-nemo-rl","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002FSKILL.md",true,[80,86,90,94],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"BENCHMARK.md","REFERENCE","参考文档",4103,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002FBENCHMARK.md",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fevals.json",2690,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002Fevals\u002Fevals.json",{"path":91,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":92,"sourceHtmlUrl":93},"skill-card.md",3741,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002Fskill-card.md",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"skill.oms.sig","OTHER","其他",4585,"https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Flaunch-nemo-rl\u002Fskill.oms.sig",[101,126,151,177,195,230],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":105,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":114,"publishedAt":44},"01M6PTDCZTXTGSTX4RFK901YSZ","xunit-skill","Generates xUnit.net tests in C#. Covers Fact\u002FTheory, constructor injection, IClassFixture, and FluentAssertions. Use when user mentions \"xUnit\", \"[Fact]\", \"[Theory]\", \"Assert.Equal\", \"C# xUnit\". Triggers on: \"xUnit\", \"[Fact]\", \"[Theory]\", \"Assert.Equal C#\", \"xUnit.net\".","MIT","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fxunit-skill\u002FSKILL.md",[108,111],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[115,116,117,118,119,120,121,122,123,124,125],"xunit","xunit skill","testing","injection","user","use","tests","triggers","unit","unit-testing","C#",{"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":105,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":134,"publishedAt":44},"01M6PTCB59ZTG5FTMWGPYEMMBP","xcuitest-skill","Generates XCUITest UI tests for iOS\u002FiPadOS apps in Swift. Apple's native testing framework for reliable, fast UI automation. Supports local simulators and TestMu AI cloud real devices. Use when user mentions \"XCUITest\", \"XCTest\", \"iOS UI test\", \"Swift test\", \"XCUIApplication\". Triggers on: \"XCUITest\", \"XCTest UI\", \"iOS UI test\", \"Swift UI test\", \"XCUIApplication\", \"TestMu\".","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fxcuitest-skill\u002FSKILL.md",[132,133],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[135,136,117,137,138,139,140,141,120,142,143,144,145,146,121,122,147,148,149,150],"xcuitest","xcuitest skill","automation","test","testing framework","ios","devices","mobile","mobile-testing","ui test","local","apple","apps","native","for","objective",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":105,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":161,"publishedAt":44},"01M6PTATMNTY9NF4J7KSR76YK6","world-builder","Create and manage generative game zones for Dorothy's Pokemon-style world. Use this skill when creating, updating, or designing game worlds via MCP tools.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworld-builder\u002FSKILL.md",[157,160],{"categoryNo":158,"categoryName":159,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[162,163,164,165,166,167,168,169,120,170,171,172,173,174,175,149,176],"builder","world","world builder","MCP","create","mcp tools","Tools","game","pokemon","manage","style","via","theme","zone","generative",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":105,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":185,"publishedAt":44},"01M6PT9Z92JTSQEHE1QR0NNW5F","webdriverio-skill","Generates WebdriverIO (WDIO) automation tests in JavaScript or TypeScript. Supports local and TestMu AI cloud. Use when user mentions \"WebdriverIO\", \"WDIO\", \"wdio.conf\", \"browser.url\", \"$\", \"$$\". Triggers on: \"WebdriverIO\", \"WDIO\", \"wdio\", \"browser.$\".","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwebdriverio-skill\u002FSKILL.md",[183,184],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[186,117,187,137,188,189,190,191,119,120,192,145,121,122,193,194],"webdriverio skill","typescript","javascript","browser","cloud","e2e","e2e-testing","URL","conf",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":105,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":210,"publishedAt":44},"01M6PT9NVK36ZWCQ69YXK3FR4K","web-design-guidelines","Web platform design and accessibility guidelines. Use when building web interfaces, auditing accessibility, implementing responsive layouts, or reviewing web UI code. Triggers on tasks involving HTML, CSS, web components, WCAG compliance, responsive design, or web performance.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fweb\u002FSKILL.md",[201,204,205],{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":158,"categoryName":159,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":206,"categoryName":207,"taxonomyType":208,"taxonomyTypeDesc":209},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,122,229],"design","web","guidelines","web design guidelines","web design","css","performance","components","web components","tasks","code","web performance","ui","platform design","html","responsive design","responsive","platform","implementing",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":105,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":238,"publishedAt":44},"01M6PT9A3JKRE3X34276F2FW5R","watchos-design-guidelines","Apple Human Interface Guidelines for Apple Watch. Use when building watchOS apps, complications, or workout features. Triggers on tasks involving Watch UI, Digital Crown, glanceable interfaces, or wrist-based interactions.","https:\u002F\u002Fgithub.com\u002Fheadmktlucca-ui\u002Fneuroads-lp\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwatchos\u002FSKILL.md",[236,237],{"categoryNo":158,"categoryName":159,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":206,"categoryName":207,"taxonomyType":208,"taxonomyTypeDesc":209},[211,213,239,220,223,120,240,241,146,228,242,122,147,243,149,244,245],"watchos design guidelines","workout","human","watch","interface","platform-design","features"]