amd

Collect and normalize environment facts (OS, Python, GPU, CUDA/ROCm, container state) before Quark installation or PTQ planning. Use this skill whenever a downstream skill needs confirmed hardware and toolchain facts, when the user mentions their setup, when you need to decide between CUDA/ROCm/CPU install paths, or when any accelerator-related assumption is unconfirmed. Also trigger when the user says things like "check my environment", "what GPU do I have", "is my setup ready for Quark", or before any install/quantization step where hardware facts are missing.

Validate workspace shape, model paths, output directories, and repo structure before downstream Quark skills proceed. Use this skill whenever a skill needs confirmed file paths, when the user provides a model path or output directory, when you need to distinguish a local model from a HuggingFace ID, or when any path assumption is unverified. Also trigger for "where should I put outputs", "is my model path right", or before model-intake/export steps.

Diagnose failed Quark ONNX installation, calibration, quantization, custom-op compilation, or export attempts. Use when the user reports an error, stack trace, invalid artifact, missing dependency, ORT execution-provider mismatch, silent CPU fallback, OOM during calibration, custom-op load failure (BFPQuantizeDequantize / MXQuantizeDequantize / Extended*), or unexpected quantization results from the ONNX flow. Trigger for "Quark ONNX error", "onnxruntime error", "quantize_static failed", "calibration crashed", "CUDAExecutionProvider not available", "ROCMExecutionProvider not available", "custom op library load failed", "model.onnx larger than 2GB", "external data not found", "AdaRound diverged", "GPTQ ONNX failed", "QuaRot failed", "NPU power-of-2 scale", any Python traceback mentioning quark.onnx / onnxruntime / onnx, or when the user pastes an error message related to Quark ONNX workflows.

Install or verify the correct ONNX Runtime build (and the `onnx` package) for a user's accelerator backend before Quark's ONNX-to-ONNX flow. Use when the user needs ONNX Runtime set up, reports onnxruntime version conflicts, CPU vs GPU variant mix-ups (only one variant of `onnxruntime*` may be installed at a time), missing CUDA/ROCm execution providers, or when `import onnxruntime` / `import onnx` fails. Trigger for "install onnxruntime", "pip install onnxruntime", "set up onnxruntime for ROCm", "set up onnxruntime for CUDA", "onnxruntime-gpu vs onnxruntime", "onnx version mismatch", "CPU-only onnxruntime installed", "ORT providers list missing CUDAExecutionProvider/ROCMExecutionProvider", or any request to get the correct ONNX Runtime build running. Also trigger when `quark-install` reports that ONNX Runtime is missing or mismatched before proceeding with the ONNX flow.

Inspect a target ONNX model and prepare metadata for Quark ONNX PTQ planning. Use when the user needs `.onnx` path validation, opset / IR version detection, input/output shape and dtype discovery, op-type histogram, quantizable-op counting, deployment-target compatibility checks (CPU / CUDA / ROCm / AMD NPU CNN / AMD NPU Transformer), or risk assessment before planning PTQ. Trigger for "analyze my ONNX model", "check this onnx model", "what opset is this", "can Quark quantize this .onnx", "is my model NPU-compatible", "does my model already have QDQ", "is my model larger than 2 GB", or when any ONNX quantization step needs model facts that are missing.

Build a Quark ONNX PTQ quantization plan from `model_analysis.json` and user intent. Use when the user needs preset selection (XINT8 / A8W8 / A16W8 / BF16 / BFP16 / MX* / MXFP* …), calibration method choice (MinMax / Entropy / Percentile / Distribution / NonOverflow / MinMSE / LayerWisePercentile), algorithm selection (CLE / AdaRound / AdaQuant / BiasCorrection / AutoMixprecision), deployment-target gating (CPU / CUDA / ROCm / AMD NPU CNN / AMD NPU Transformer), op-type include/exclude lists, weights-only INT4 (MatMulNBits) decisions, dynamic vs static quantization, or a draft `quant_plan.json`. Trigger for "what preset should I use for my ONNX model", "choose XINT8 vs A8W8", "plan ONNX PTQ", "INT4 "BFP16 / MXFP4 for my model", "calibration method for Ryzen AI", "should I use AdaRound or AdaQuant", "SmoothQuant alpha", or when the user has a model analysis and needs to decide how to quantize an ONNX model.

Validate Quark ONNX quantization output using four lightweight checks: auxiliary file copy alignment, expected non-quantized initializer MD5 byte-identity (inline `raw_data` + external-data byte ranges), model metadata equality after stripping quantization-only opset entries / Quark domains, and fuzzy node-pattern + op-type + dtype summaries with QDQ / `com.amd.quark` custom-op presence. Intended for post-quantization inspection of `model.onnx` (with or without `model.onnx_data`). Trigger for "validate ONNX quantization result", "check quantized .onnx output", "verify ONNX initializers", "did QDQ insertion happen", "are the non-quantized weights byte-identical".

Route Quark ONNX user goals to the correct atomic skill. Use when a user describes an ONNX quantization task in plain language — such as "install onnxruntime", "analyze my .onnx model", "choose a preset for my YOLO model", "plan ONNX PTQ", "quantize this .onnx with XINT8/BFP16/MXFP4", "validate my quantized .onnx", "debug a failed ONNX quantization", or any request that involves Quark's ONNX-to-ONNX flow. This is the ONNX-side entry point — trigger it whenever the user's intent involves Quark ONNX and the correct downstream skill is not immediately obvious.

Use when integrating the @amd-gaia/agent-email npm package — embedding the GAIA email agent (a local triage/draft/send sidecar) into a Node, TypeScript, or Electron app. Covers install, spawning the sidecar, calling the typed client, prerequisites, and the common gotchas.

The non-obvious invariants of the proactive weekly Claude audit workflow (.github/workflows/claude-weekly-audit.yml): the stable dedup-key scheme that keeps it from re-filing findings every week, the four audit dimensions (security has its own workflow, claude-security-audit.yml) and which one owns the Fail-Loudly check, and the `bug`-label → auto-fix promotion path. Read before editing that workflow, changing how findings are filed/deduped, or adding an audit dimension.

Adopt the per-agent eval scorecard for a GAIA hub agent: write the harness→payload adapter, run the eval to produce a REAL scorecard, link + surface it from the agent's README, wire the release gate, and (for a new agent) generalize the format. Use when asked to 'add a scorecard', 'adopt the eval scorecard', 'generate the scorecard for <agent>', or wire scorecard CI for an agent. Builds on docs/reference/eval-scorecard.mdx and the email agent reference adapter.

Cut or wire a frozen-binary + npm sidecar release for a GAIA agent (the email-agent CI pipeline: freeze -> Agent Hub Worker /publish -> npm OIDC). Use when releasing or onboarding a sidecar agent under hub/agents/, or authoring a release_agent_<id>.yml. For the standard wheel/PyPI + Hub publish, defer to the author guide docs/guides/hub-publishing.mdx — this skill is the sidecar extension on top of it.

Build a new GAIA agent with the SDK end-to-end: scaffold the package, write the Agent subclass, register @tool functions, compose reusable tool mixins, set the model + system prompt, and test it locally — then hand off to publishing. Use when creating a NEW agent (a Python class inheriting from the base Agent) for the GAIA repo or a user-authored package, not for tuning an existing agent's prompt (prompt-engineer), adding one tool to an existing class (python-developer), or shipping/releasing an already-built agent (use the agent-hub-release skill + docs/guides/hub-publishing.mdx). Pairs with the agent-hub-release skill: this one BUILDS, that one PUBLISHES.

Use when taking an existing in-repo GAIA agent to a published, day-one-usable hub package — porting a legacy agent under hub/agents/<id>/, deciding whether an agent should ship at all, or answering why an agent 'is not ready to publish'. Also use when an agent's manifest advertises capability its code does not deliver, or when an agent has a README but no SPEC/SKILL/CHANGELOG/SCORECARD.

Generate an EXECUTIVE slide presentation (leadership / decision-maker audience) from a source document as self-contained HTML that prints cleanly to PDF, one slide per page. Use when the user asks for an executive presentation, a leadership briefing, a pitch or exec deck, or to turn a README/spec/design doc into executive slides. Leads with outcome, impact, timeline, risk, and cost; no code blocks, no architecture diagrams, no methodology. Offline HTML with an @media print profile; no PPTX/Keynote/Google Slides. For an engineering-facing version, use gaia-technical-presentation.

Generate a TECHNICAL slide presentation (engineering audience) from a source document as self-contained HTML that prints cleanly to PDF, one slide per page. Use when the user asks for a technical presentation, engineering slides, an architecture or deep-dive deck, or to turn a README/spec/design doc into technical slides. Covers architecture, methodology, request/response contracts, and metrics with their method; code blocks and diagrams allowed. Offline HTML with an @media print profile; no PPTX/Keynote/Google Slides. For a leadership-facing version, use gaia-executive-presentation.

Integrates local AI capabilities into applications using Embeddable Lemonade. Use when the user wants to add local AI, offline AI, private AI, on-device AI, a local LLM, local chat, embeddings, image generation, speech-to-text, or text-to-speech to an app; replace or supplement OpenAI, Anthropic, Ollama, or other cloud AI APIs with a local backend; bundle AI inference into an app installer; or mentions Lemonade, `lemond`, embeddable lemonade, Ryzen AI, NPU/iGPU/dGPU inference, or auto-optimizing local AI.

Routes image generation, text-to-speech, and speech-to-text through a local Lemonade Server so the agent stops paying for cloud calls on those modalities. Use when the user wants to save tokens, save cost, or save money using local AI; default to local, offline, on-device, or private image generation, transcription, or text-to-speech in this workspace; stop using DALL-E, Whisper-as-a-service, ElevenLabs, or other paid multimodal APIs; route the agent's image, TTS, or STT tool calls to a local model; or mentions Lemonade Server, OmniRouter, SD-Turbo, kokoro, Whisper, Ryzen AI, NPU/iGPU/dGPU inference, or "use local for images but cloud for chat". Run once per workspace; the rule it installs handles every later request.

Orchestrates modular PyTorch profiler trace analysis with TraceLens: generates perf reports, prepares category data, runs system-level and compute-kernel subagents in parallel, validates outputs, and writes a prioritized stakeholder report (analysis.md). Use when the user asks to follow the analysis orchestrator, run the agentic analysis workflow, analyze a trace, compare two traces, or mentions standalone or comparative TraceLens analysis.

Serves a language model on an AMD EPYC CPU host using vLLM with the zentorch backend, in a container (Docker or Podman) or a conda env. Use whenever the user wants to run, serve, deploy, start, host, or launch an LLM on AMD EPYC, Zen CPU, "vLLM on CPU", "zentorch serving", or "serve a model without a GPU". Use for "serve Qwen on EPYC", "start a CPU vLLM endpoint", "run an OpenAI server on my EPYC box", or similar. Handles the full single-instance flow: detect the CPU (incl. EPYC generation), validate the runtime/env, check vLLM supports the model (via vLLM's registry, not a modality blocklist), check it fits host RAM, size CPU threads/KV/NUMA from the hardware, confirm the plan with the user, launch, and poll until the endpoint is responsive. Single instance, single socket (pinned to one socket + its memory; vLLM scales poorly across sockets). Does NOT debug failures and does NOT retry -- it reports and stops. Do not use for GPU/Instinct (use serving-llms-on-instinct) or multi-node.

Performs GPU kernel correctness and performance evaluation and LLM inference benchmarking with Magpie. Analyzes single or multiple kernels (HIP/CUDA/PyTorch), compares kernel implementations, runs vLLM/SGLang benchmarks with profiling and TraceLens, and runs gap analysis on torch traces. Creates kernel config YAMLs, discovers kernels in a project, and queries GPU specs. Use when the user mentions Magpie, kernel analyze or compare, HIP/CUDA kernel evaluation, vLLM/SGLang benchmark, gap analysis, TraceLens, creating kernel configs, or discovering GPU kernels.

Inspects and tunes the shared-vs-dedicated memory split on AMD Ryzen APUs with unified memory (UMA) so larger LLMs and image-gen models fit on the iGPU, or so reserved GPU memory is returned to the CPU. Use when the user mentions Ryzen AI, Strix Halo / Strix Point / Krackan / Phoenix / Hawk Point, Ryzen AI Max, gfx1150 / gfx1151 / gfx1152, integrated Radeon, iGPU memory, UMA Frame Buffer Size, AMD Variable Graphics Memory, VGM, GTT, GART, TTM, pages_limit, amd-ttm, amd-debug-tools, "shared GPU memory", "dedicated GPU memory", carve-out, "not enough VRAM", "out of VRAM", "GPU OOM", llama.cpp on iGPU, ROCm on APU; or asks how much memory the iGPU can use, how to give the iGPU more memory, how to balance memory between CPU and GPU on UMA, or how to change the BIOS UMA reservation. Read-only diagnostics work everywhere; tuning runs automatically on Linux via `amd-ttm` and prints guided BIOS steps on Windows. Do not use for discrete Radeon cards, Intel iGPUs, or Apple Silicon -- it is APU-only.

Diagnoses why ROCm, the HIP SDK, PyTorch, or llama.cpp is broken on an AMD GPU on Linux or Windows, and either applies a low-risk fix with consent or hands back the exact next step. Also routes Lemonade, LM Studio, and Ollama issues to the right upstream channel. Use when the user reports that ROCm or HIP isn't working, torch.cuda.is_available() is False Ryzen AI, rocminfo or hipInfo can't see the GPU, or hits hipErrorNoBinaryForGpu, HSA_STATUS_ERROR_INVALID_ISA, invalid device function, missing amdhip64_6.dll, vcruntime140_1.dll, or libamdhip64.so, cannot open /dev/kfd, ROCk module not loaded, an Adrenalin driver too old for the HIP SDK, or a ROCm wheel that doesn't recognize gfx1151, gfx1150, or gfx1103; or mentions HSA_OVERRIDE_GFX_VERSION, HIP_VISIBLE_DEVICES, PYTORCH_ROCM_ARCH, render-group permissions, amdgpu blacklist, Secure Boot, iGPU/dGPU collisions, or multi-GPU hangs. Do not use for non-AMD GPUs, performance tuning, or ROCm-on-WSL2.

Serves AI models on AMD Instinct GPU hardware using vLLM. Use this skill whenever the user wants to run, serve, deploy, start, host, or launch a language model on an AMD GPU, AMD Instinct, MI300X, MI325X, MI350X, or MI355X. Also use when the user mentions vLLM on ROCm, vLLM on AMD, serving on HBM, or asks how to get a model running on AMD data center hardware. Use when the user asks "run Qwen3", "serve DeepSeek", "start a vLLM endpoint", "get a model running on my AMD machine", or any similar phrasing. Handles the full flow: GPU detection, environment validation, vLLM configuration, launch, and health verification. Do not use for NVIDIA GPUs, consumer AMD GPUs (RX series, Radeon), Ryzen AI, NPU, MI250X, or MI100.