Use this skill when the user asks to "release the gemma-4 image", "build the prebuilt gemma-4 image", "run the gemma-4 image release session", "warm and bake the gemma-4 kernels", "create/publish the gemma-4 docker image with prebuilt kernels", or otherwise wants the vllm-emmy-gemma4 release pipeline executed end to end. Runs the documented workflow (docker/vllm-emmy-gemma4/ARCHITECTURE.md) on a rented RTX 5090 (via start-remote-server) or a local one — base image, toolchain preflight, memory-headroom sweep that pins config.env, HF-parity validation gate, warm, bake, offline zero-recompile verify, push — with hard abort gates at every step, a human approval pause before the push, and guaranteed teardown.
Use this skill when the user asks to "tune the goldens", "update the golden configs", "re-tune the goldens", "run the golden sweep", "refresh golden matmul configs", "evaluate goldens and update", "tune/seed the dynamic goldens", or otherwise wants to re-tune the GOLDEN_CONFIGS matmul shapes (static and dynamic/.dynM symbolic-axis entries alike), A/B the greedy pick against the recorded golden, and record genuine improvements into the per-GPU golden YAML. Tunes the whole golden dataset, benches greedy-vs-golden per shape with `emmy tune` / `run --bench`, categorizes (better → replace, same → add, worse → leave), edits the goldens YAML by hand, and writes a findings report to plans/ — unlike tune-model, the target config is known here, so the report analyzes the offline/online prior's expectation against it (rank, per-knob misses, recommendations) plus workflow notes.
Use this skill when the user wants to populate or refresh the autotune DB's node table (the cross-hardware search-tree node store) with data measured on a SPECIFIC GPU — e.g. "collect node data for an H200", "tune the goldens on a rented <GPU> and merge the nodes back", "gather cross-hardware node-store data", "populate / update the node table from <hardware>", "run the golden node sweep on a remote <GPU>". Rents a fresh single-GPU server (via start-remote-server; --billing-exempt for CloudRift), rsyncs + sets up emmy there, runs `emmy tune --dataset golden --explore-eps 0.25` (ε-greedy so the node data covers siblings the incumbent prior would skip), then merges the remote node rows into the local `~/.cache/emmy/autotune.db` (nodes table only, GPU-keyed so cards never collide), and tears the server down.
Use this skill when the user asks to "tune model X", "analyze tune findings for <model>", "tune and analyze model X", "why is emmy slower than eager / torch.compile on X", "do a per-kernel performance analysis", "drill into kernel performance", "profile the compiled kernels with NCU", or otherwise wants a clean autotune of a model (or one layer), an end-to-end + per-kernel bench against PyTorch eager and torch.compile, a root-cause analysis of every underperforming kernel (search shortfall, tier/optimization lockout, codegen quality, bench failures), and a findings report saved to plans/. For a whole-model tune it also validates the full model end-to-end (eager / torch.compile / emmy) and, when the model is servable via `emmy serve` (an embedding model), benches the served model via `vllm bench serve` against vanilla vLLM. Modeled on plans/qwen3-embedding-layer0-tune-findings.md. For the golden matmul shapes use the tune-golden skill instead — there the target config is known, so the analysis evaluates the pr
Use this skill when the user asks to "add a new model and benchmark it", "benchmark this model", "try out model X on a server", "benchmark <HF model id>", or otherwise wants to onboard a previously-unsupported model into emmy and run benchmarks against it on an existing or freshly provisioned remote GPU server. The skill creates a recipe, web-searches optimal launch parameters and the right engine/image, validates context length / tool / reasoning parsers, and runs benchmarks with hard time caps.
Use this skill when the user asks "what new models should we try / benchmark", "find / discover new (open) models worth exploring", "scout trending models for our GPUs", "which new models fit B200 / H200 / H100 / Pro6000 / 5090 / 4090", "what's new and worth benchmarking", or otherwise wants a shortlist of newly-released, in-demand open-weight models emmy doesn't support yet, each mapped to the hardware it runs on. Produces a ranked, hardware-bucketed shortlist ready to hand to the `benchmark-new-model` skill. Discovery + popularity come from `scripts/new_models.py` (keyless); hype/news from web search; hardware fit from a VRAM calculation.
This skill should be used when the user asks to "start a remote server", "spin up a GPU VM", "provision a cloud GPU", "create a remote server with X GPU", "give me a server with Y GPUs", or otherwise wants a fresh cloud GPU VM provisioned (without immediately deploying a model) so it stays available for later benchmarks or inference work.