quark-install

See LICENSE for license information. -->

Answers questions about what rocprofiler-systems configuration options exist and how to use them — e.g. "what hardware counters are available on my system", "what ROCm APIs can I trace", "what settings control sampling/output", "how do I persist my configuration" — by mapping the question to the right `rocprof-sys-avail` or `rocprof-sys-run --help=<topic>` command. Use when the user wants to discover or explore ROCPROFSYS_* settings, Timemory components, hardware counters, ROCm API tracing domains, or GPU metrics, rather than apply them. Do NOT use this for picking a starting --preset for a workload — that's `choosing-a-profiling-preset`.

Guides instrumentation with `rocprof-sys-instrument` - choosing runtime instrumentation vs binary rewrite (`-o`), including or excluding functions and modules with regex options, previewing what will be instrumented with a dry run (`--simulate`, `--dump-info`, `--print-*`), tuning granularity (`--min-instructions`, `--min-address-range`, `--instrument-loops`), rewriting libraries, and diagnosing why a function is missing from, or too numerous in, a trace. Use when the user asks about rocprof-sys-instrument, binary rewrite, instrumenting a shared library, function or module include/exclude regexes, dry runs, or the difference between a function and a module. Do NOT use to pick a `--preset` (use `choosing-a-profiling-preset`), to list settings, counters or ROCm domains (use `discovering-profiling-options`), or to attach to an already-running process (a separate tool, `rocprof-sys-attach`).

Serves an LLM on a supported AMD EPYC server CPU using vLLM with zentorch, in Docker, Podman, or conda. Use for "vLLM on CPU", "zentorch serving", or an EPYC CPU endpoint, including on a host that also has AMD Instinct GPUs. Detects the EPYC generation, validates the runtime, checks model support and RAM fit, sizes threads/KV/NUMA, confirms the plan, launches, and verifies the endpoint. Runs one instance on one socket and its memory. Reports and stops on failure; does not retry or debug. Use serving-llms-on-instinct when the endpoint should run on a GPU. Excludes multi-node, EPYC 4000, and pre-Zen4 EPYC without AVX-512.

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.

See LICENSE for license information. -->

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.

Recommends which rocprofiler-systems runtime profiling preset (balanced, trace-gpu, trace-hpc, sys-trace, workload-trace, etc.) to pass to `rocprof-sys-run --preset=<name>` or `rocprof-sys-sample --preset=<name>` based on the user's workload and profiling goal, and returns the ready-to-run command. Use when the user asks "which preset should I use", describes a workload (GPU kernel, MPI, OpenMP, AI/ML training, production overview) and wants profiling guidance, or invokes `rocprof-sys-run`/`rocprof-sys-sample` without picking a preset. Do NOT use for CMake build presets (`cmake --preset debug|release|ci`) used to configure/compile rocprofiler-systems itself — that is a build-configuration concern, not a profiling-run concern.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

Wire dependency-cruiser into a TypeScript repo so each package is a deep module, with implementation hidden in subfolders and reachable only through its entry-point files. User-invoked.

Conduct a retrospective on a coding session.

Use when completing tasks, implementing major features, or before merging to verify work meets requirements