vibesys-kernels-rocm

Plugin vibesys-kernels-rocm from marketplace vibesys in uw-syfi/vibesys. Commands read from the repo's manifest — today.

Skills (37)

• custom-rpc-optimization

  Design and validate custom RPC policies for microservices using measured request behavior and framework hooks. Use when optimizing admission, concurrency, scheduling, routing, retries, hedging, deadlines, cancellation, or cross-service feedback with rpcstack (the rpcstack/hotel and rpcstack/socialne

• dial9-rank-bottlenecks

  Rank where a dial9-instrumented Tokio engine (for example RisingWave) spends its in-window on-CPU time, and read the slow-versus-starved verdict. This is the entry workflow over the vendored dial9 trace skills and the on-CPU ranker in this bundle. Activate when you have a dial9 trace of an async Rus

• dial9-diagnose-long-poll

  Root-cause why a poll was long, not just where it was. Use after `red_flag_scan.js` or `analyze.js` flags a long poll and you need to explain it and recommend a fix — including the off-CPU case with no scheduling events captured. Use when the user says "why is this poll long", "what is it blocked on

• dial9-red-flags

  Automated health checks for dial9 Tokio runtime traces. Detects incomplete files, long polls, task leaks, scheduling delays, blocking calls, queue buildup, worker imbalance, CPU contention, and span anomalies. Use when you want a quick automated assessment of trace health.

• dial9-runtime

  Tokio async runtime internals reference. Covers the execution model, waking and scheduling, cooperative scheduling, poll duration effects on tail latency, worker parking, and how to connect trace data to application behavior. Use when reasoning about runtime performance from first principles.

• dial9-toolkit

  JavaScript analysis toolkit for parsing and analyzing dial9 Tokio runtime traces. Always start trace diagnosis with analyzeTraces() from analyze.js, then use parseTrace() and lower-level helpers only to confirm assumptions or drill into raw events.

• dial9-trace-analysis

  Analysis pipeline API for dial9 traces. Covers analyzeTraces() aggregation, buildWorkerSpans, attachCpuSamples, scheduling delays, flamegraphs, span data, and the full return schema. Use when analyzing parsed traces or building custom analysis pipelines.

• dial9-trace-loading

  Parse already-local dial9 Tokio runtime trace files or buffers and understand the ParsedTrace data model. Use when trace bytes are available locally or in memory; do not use to retrieve a viewer URL, API object, or S3 object.

• dial9-trace-recipes

  Diagnostic recipes for common questions about dial9 Tokio runtime traces. Covers finding long polls, task leaks, worker utilization, blocking calls, wake chains, span analysis, task dumps, time-window debugging, and estimating allocation totals from sampled `Alloc` events. Use when answering specifi

• dial9-zoom-window

  Zoom into a narrow time window of a dial9 trace to see every worker and OS thread at one moment. Use after an aggregate pass (`analyze.js`, `red_flag_scan.js`) flags a timestamp: a long poll, a queue spike, a latency outlier. Use when the user says \"zoom in\", \"what was happening at +6953ms\", or

• kernel-correctness

  Check a compute kernel against its task reference, including numerical tolerance, memory safety, and supported input variants. Use for kernel implementation or correctness failures.

• kernel-ncu-analysis

  Interpret NVIDIA Nsight Compute evidence for a CUDA kernel task. Use when an NCU capture is available and a measured bottleneck needs diagnosis.

• kernel-performance

  Optimize a compute kernel using its scored benchmark and measured bottlenecks. Use when choosing launch geometry, tiling, memory layout, fusion, or precision changes.

• kernel-rocprof-analysis

  Capture and interpret AMD rocprofv3 and rocprof-compute evidence for a ROCm kernel or serving task. Ships a capture wrapper that checks the profiler, HIP runtime and driver versions before it runs, and local tools that analyze copied-back traces, counters, thread traces, torch traces and A/B microbe

• kernel-timeline-analysis

  Instrument a CUDA kernel with FlashInfer's profiler macros and read its per-block timeline. Use for persistent, multi-phase, or grid-synchronized kernels where per-launch counters cannot say which phase or which block sets the critical path.

• microservice-optimization

  Restructuring the request graph of a microservice application to cut end-to-end latency. Activate on serialized cross-service calls, critical-path contribution, sequential dependencies that could run in parallel, work that could move off the request path, batching repeated calls to one service, or c

• neuron-explorer-profile-schema

  Reference for the neuron-explorer profile schema (the parquet tables produced when `neuron-explorer view`/`ingest` processes a profile). Use when the user asks "what tables are in the profile", "what fields are in <Table>", "where does this field come from", "where can I find matmul/source-line info

• neuron-nki-debugging

  This skill guides debugging NKI compilation errors on Neuron hardware. Use when encountering "compiler error on device", "debug NKI kernel", "test kernel on trn2/trn3", "neuronx-cc compilation failed", "validate kernel on hardware", "run kernel on trainium", or asking "how to debug NKI compilation e

• neuron-nki-docs

  Research NKI documentation for API lookups, tutorials, error codes, architecture, and optimization guides. Use when user asks "what does <API> do", "how to do <task>", "what is error <code>", "NKI <API> signature", "find NKI tutorial for <topic>", "look up <symbol>", or needs any NKI documentation r

• neuron-nki-profile-querying

  Query and analyze NKI kernel profile data from neuron-explorer parquet files. Supports SQL queries via the neuron-explorer API and Python on parquet for advanced analysis. Works locally on trainium with NEFF/NTFF files on disk. Querying: start neuron-explorer, ingest profiles, run SQL against tables

• neuron-nki-profiling

  This skill guides using the cli to generate NKI kernel profiles (NEFF + NTFF pairs) to analyze performance on Neuron hardware. Use when encountering "profile kernel", "capture execution trace", "generate NEFF", "get summary-json", or asking "how to profile NKI kernel".

• neuron-nki-writing

  Guide for writing and modifying NKI kernels. Covers new kernel creation from PyTorch/NumPy/natural language, editing existing kernels, adding shape/dtype support, refactoring tiling strategies, and implementing new features in NKI code. Use when user says "write NKI kernel", "convert PyTorch to NKI"

• serving-systems

  LLM and multimodal serving systems. Activate on inference servers, latency / throughput / TTFT / TPOT, KV-cache, batching, attention kernels, graph capture, speculative decoding, structured output, quantization, MoE, prefix caching, vision/speech/image/video serving, porting a model to vLLM / SGLang

• allocations

  Use when jobs of a vibesys optimization wait long in a cluster queue, or before a long stretch of jobs on a placement that queues. Says when to hold a standing allocation with vibesys-cli, how to start one, how to judge renewal from `placement capacity`, how to end it, and how to read `alloc show` h

• combine-candidates

  Use when a vibesys optimize brief asks you to combine several candidates' changes into one new commit on a given base, or to merge judged winners for promotion. Applies each candidate's own change in the stated order, resolves conflicts as the brief says, runs the checks, measures the result with vi

• commit

  Use when you commit work in a vibesys optimization: at every working step, before any measurement, and before ending a turn. Defines when to commit, what a commit holds, the enforced message schema (Conventional Commits plus Checks and Plan trailers, with cheap wip checkpoints), and which commits ma

• create-task

  Use when a user describes in their own words what they want to optimize in a repository (the code, the workload, the number that should move, what must stay correct) and there is no `.vibesys/tasks/<task>/` for it yet, or an existing task needs to be made runnable. Turns that description into a task

• implement-hypothesis

  Use when a vibesys optimize brief gives you one hypothesis to implement in your own git worktree. Makes the smallest change that yields a measurement, commits it, measures it with vibesys:measure (vibesys-cli jobs), and hands back the claim, the commit, the verdict, what was learned and the next ste

• judge-candidate

  Use when a vibesys optimize brief asks you to independently review a candidate commit that claims a gain, before the lead treats it as a win. Read-only: compares the diff with its parent against the claim, checks that the change is on the measured path, looks for gaming of the check or benchmark, an

• measure

  Use when you must measure a commit for a vibesys optimization, compare it with another commit, or read the current best number. Submits check, measure and command jobs to vibesys-cli, which builds and runs the exact commit in a clean checkout and owns the queue, the cache, the verdict and the saved

• optimize

  Use when asked to optimize a repository against a benchmark, unattended, as `optimize <task> [--fanout N]`, in a repository that has `.vibesys/tasks/<task>/`. One long-running, stoppable and resumable optimization per task: planners propose hypotheses as plans, workers try them in parallel git workt

• plan-hypotheses

  Use when a vibesys optimize brief asks you to propose one hypothesis as a plan. Read-only on code: browses the plans, the saved results and the code, picks its own idea, bounds the possible gain from measured peaks and observed numbers, and stores one falsifiable proposal with vibesys-cli plan creat

• profile-revision

  Use when a vibesys optimize brief asks you to answer one question about one revision with evidence, to inform the lead's next decision. Changes no code and produces no candidate: runs the profiler, trace or measurement the question needs on a read-only checkout and hands back findings with the decis

• report-progress

  Write a periodic progress report for a long-running multi-agent effort, so the reader can tell what changed, what to trust and what was decided for them. Use when an orchestrating lead reports on a schedule, at a stop, or when asked for status.

• setup

  Use when a session is about to make its first vibesys-cli call (vibesys:create-task and vibesys:optimize start here), when vibesys-cli is missing, fails or reports a version the skills do not support, or when the user asks to install, upgrade or check it. Finds vibesys-cli or installs it with the us

• state

  Use when you create, resume or update the state of a vibesys optimization: what vibesys-cli stores (jobs, results, plans and their comments), what lives in git (the result branch, candidate branches, worktrees), who writes which part, how to find what is live, and how to resume after a stop.

• visualize-progress

  Use when you need charts of how a vibesys optimization is going: the headline objective along the result branch, the throughput-versus-latency Pareto frontier, latency along the branch, and how plans ended. Reads the optimization state and writes PNGs plus a report.md. Read-only on state; runs no be