291 skills · sorted by relevance
Analyze GPU operation timings and execution traces to find costly data access, repeated computation, launch overhead, and synchronization waits. Check whether improving an individual operation actually reduces the time needed to complete a full request.
Add or change a named Pallas/Mosaic kernel, including its reference implementation, correctness tests, wrapper, or requested tuning.
The English summary is being prepared. Showing the original description.
Use when you need to rebuild the BSP overlay — DT, OOT modules, or kernel — from changes under bsp_sources/. Triggers: build bsp, rebuild dtb, rebuild kernel.
The English summary is being prepared. Showing the original description.
Use this skill when the user is building, running, or interpreting the doca/tools/gpunetio_ib_write_bw client+server benchmark — a CUDA kernel on the client posts RDMA WRITE work requests through the doca-gpunetio device-side surface to measure sustained GPU-driven WRITE bandwidth on a GPU+IB-device pair. Trigger even when the user does not explicitly mention "doca-gpunetio-ib-write-bw" or "GPUNetIO" — typical implicit phrasings include "measure WRITE BW when the GPU posts the WRs", "BW swings between runs on the same flags", "is the NIC saturated or am I CPU-bound on the CUDA kernel", "meson compile fails for the GPUNetIO bw tool", "nvidia_peermem isn't picking up my GPU buffer", or "GPU-initiated WRITE throughput vs CPU-initiated perftest". Refuse and route elsewhere for general doca-gpunetio library work, DOCA install, the GPU-initiated WRITE latency analog, the CPU-initiated upstream perftest, or application-level end-to-end throughput — those belong to other skills.
The English summary is being prepared. Showing the original description.
Use this skill when the operator is authoring, building, loading, or debugging a custom doca-bench plug-in — a versioned shared library with DOCA_EXPERIMENTAL-marked C entry points that doca-bench loads to measure a workload class its built-in modes do not cover, with doca_bench_cuda as the shipped reference exemplar. Trigger even when the user does not say "doca-bench-extension" or "doca_bench_cuda" — typical implicit phrasings include "no built-in doca-bench mode fits my workload", "how do I benchmark a CUDA GPUNetIO RX/TX kernel", "doca-bench cannot find or load my custom .so", "extension exported symbols do not match what the parent expects", "soversion mismatch after a DOCA upgrade", or "my GPU kernel hangs because stop_flag was never set". Refuse and route elsewhere for questions about which built-in doca-bench mode to pick, DOCA GPUNetIO programming semantics, CUDA toolkit installation, or contributor work on in-tree extensions — those belong to other skills.
The English summary is being prepared. Showing the original description.
Use when porting circuits from another framework (e.g. Qiskit) into CUDA-Q kernels while preserving the source algorithm and validation fidelity.
The English summary is being prepared. Showing the original description.
Use for CUDA-Q setup, simulation targets, QPU access, and @cudaq.kernel authoring guidance.
The English summary is being prepared. Showing the original description.
Formulate and audit real strategy using Richard Rumelt's "Good Strategy Bad Strategy": an honest diagnosis, a guiding policy, and coherent action instead of goals, vision, and wishful thinking. Use when the user mentions "good strategy bad strategy", "strategy kernel", "diagnosis guiding policy coherent action", "our strategy is just goals", "strategic planning", "mission vs strategy", "annual plan", or "is this actually a strategy". Also trigger when auditing a strategy doc or pitch deck for fluff, turning a goal list into real strategy, formulating strategy for a product or company, or finding leverage and proximate objectives. Covers the kernel of strategy, bad-strategy detection, and sources of power. For product positioning, see obviously-awesome. For uncontested markets, see blue-ocean-strategy.
The English summary is being prepared. Showing the original description.
Microsoft Semantic Kernel planner and plugin setup for orchestrated AI
The English summary is being prepared. Showing the original description.
Optimize LuisaCompute DSL kernels using warp/wave primitives, shared-memory aggregation, block-level collectives, thread-group (block) size / occupancy tuning, and C++ branch-prediction hints (`[[likely]]`/`[[unlikely]]`). Use when kernels bottleneck on atomics, reductions, inter-thread communication, or poor occupancy.
The English summary is being prepared. Showing the original description.
Use when a kernel dump contains Driver Verifier violations; inspect flags, bugcheck subcodes, and available I/O shadow state. Not for Application Verifier user-mode stops or inferring a violation from enabled flags alone.
The English summary is being prepared. Showing the original description.
Use when kernel evidence shows stalled I/O, a power IRP, or completion/cancellation misuse; inspect request state and driver ownership. Not for interpreting an empty IRP search in a limited dump as proof of healthy I/O.
The English summary is being prepared. Showing the original description.
Use when kernel threads block on driver synchronization or Verifier reports a lock-order violation; build an owner/waiter graph. Not for treating every watchdog stop as a deadlock or listing every lock type with !locks.
The English summary is being prepared. Showing the original description.
Use when a kernel dump reports a Windows bugcheck; decode parameters and recover exception or trap context before investigating your driver. Not for user-mode process crashes or blaming a module from its name alone.
The English summary is being prepared. Showing the original description.
Convert PyTorch AT_DISPATCH macros to AT_DISPATCH_V2 format in ATen C++ code. Use when porting AT_DISPATCH_ALL_TYPES_AND*, AT_DISPATCH_FLOATING_TYPES*, or other dispatch macros to the new v2 API. For ATen kernel files, CUDA kernels, and native operator implementations.
The English summary is being prepared. Showing the original description.
Use when crossing a Windows security boundary or escaping a sandbox — kernel/user crossing (win32k/dxgkrnl UAF CVE-2025-24983), BYOVD kernel R/W, UAC/COM elevation, AppContainer/LPAC & Chromium-Mojo sandbox escape (CVE-2025-2783), PPL bypass, RPC/ALPC & named-pipe impersonation
The English summary is being prepared. Showing the original description.
通过实时 Jupyter kernel 进行交互式 Python（hamelnb）。
The English summary is being prepared. Showing the original description.
Iterative Python via live Jupyter kernel (hamelnb).
The English summary is being prepared. Showing the original description.
Essential Zephyr RTOS kernel services. Covers thread lifecycle and priority, the logging subsystem for diagnostics, and the interactive shell for real-time hardware inspection and debugging. Trigger when writing application flows, adding logging to modules, or creating interactive CLI commands.
The English summary is being prepared. Showing the original description.
Advanced Zephyr RTOS kernel services. Covers inter-thread communication using Zbus (pub/sub), behavioral management with the State Machine Framework (SMF), background processing via work queues, and persistent configuration with the Settings subsystem. Trigger when building modular application architectures, complex state-driven logic, or requiring persistent data storage.
The English summary is being prepared. Showing the original description.
Use when working on imp's quantization formats, loaders, or dequant paths - GGUF Q4_0...Q8_0/Q*_K/IQ4/MXFP4, NVFP4 two-level scaling (Modelopt vs compressed-tensors layouts), FP8 E4M3, StorageTier, decode cache, KV-cache dtypes (auto/fp16/fp8/int8/int4/nvfp4/mxfp4), "which quant should I use", "which KV dtype", scale-factor layout, dequant kernel wiring, imp-quantize / AWQ, judging quant quality (PPL). Do NOT use for writing/optimizing GEMM/GEMV kernels (sm120-cuda-expert) or measuring quant perf (benchmark-cuda).
The English summary is being prepared. Showing the original description.
Use when asking whether something in imp is actually finished - hunting stubs, placeholders, request fields that are parsed and then ignored, code paths or kernels that never run, gate-based features that silently no-op, tests that assert nothing. Triggers on "is this implemented", "unfinished", "stub", "placeholder", "dead path", "does this flag do anything", "accepted but ignored", "kernel never launched", "test asserts nothing", "neutral A/B on a gated feature". Do NOT use for structural debt / god files / duplication (codebase-audit) or for who-calls-what (code-graph).
The English summary is being prepared. Showing the original description.
Use when a question is about *structure* rather than text - who calls or launches a symbol, where it is defined, what a change would reach, whether something is dead, how a request gets from the API to a kernel. Triggers on "who calls", "who launches this kernel", "where is X defined", "what breaks if I change", "is this still used", "is this dead", "trace the path from X to Y", "blast radius", "what depends on this header". Do NOT use for free-text search (`rg` is better and cheaper) or to open a file whose path you already know.
The English summary is being prepared. Showing the original description.
Apply software pipelining (double-buffering) to a tiled GPU kernel to overlap global memory loads with Tensor Core computation. Covers prologue/loop/epilogue restructuring, LDG-register vs cp.async (LDGSTS) variant selection based on compute/load ratio, shared memory budget verification against architecture-specific occupancy cliffs, and SASS-level verification of load/compute overlap.
The English summary is being prepared. Showing the original description.