rocm-libraries

Build hipDNN with providers via the repository superbuild. Faster than standalone since providers build alongside hipDNN in a single CMake invocation. On Windows, auto-runs the wheel-based ROCm setup if not already prepared.

Run tests against an existing hipDNN superbuild. Supports per-component selection (hipdnn, miopen-provider, hipblaslt-provider, hip-kernel-provider, integration-tests), unit/integration/external-integration scope, and gtest filtering. Reproduces the cross-provider external-integration-check suite. Handles Windows DLL PATH automatically.

Draft or revise pull request titles and bodies with a concise standard format: summary, risk assessment, testing summary, testing checklist, and technical changes. Use when preparing a new draft or ready-for-review PR, opening a PR from a branch, updating an existing draft/open PR, reopening a PR, or when the user provides a GitHub PR URL/branch and asks for PR summary, risk, testing, or description text. New PRs should be draft by default unless the user explicitly asks to open them ready for review.

hipBLASLt supplements to the ROCm PR quality base skill. Use for hipBLASLt PR author, review, or pre-merge gating (target branch develop; product paths under projects/hipblaslt/**, including tensilelite/). Adds and tightens base rules; never relaxes a base MUST.

Turn a technical RFC into an actionable backlog of JIRA stories and tasks, grounded in the codebase the RFC affects. Derives unified, independently-shippable work items (each with a user-story sentence, acceptance criteria, functional and non-functional requirements), presents them for review, then — unless run as a dry run — collects component/epic/label defaults and creates the tickets in JIRA. Use when you have an approved or near-approved RFC and need to plan the implementation as trackable work.

Review a hipDNN pull request, branch, or local diff for correctness, API compatibility, provider behavior, resource management, code reuse, and testing coverage/quality. Uses local source/worktrees for cross-reference by default. Use when asked to review hipDNN code, review a PR, or assess whether a change is ready to merge.

Deep-dive review of a technical RFC focused on change-management concerns — API/ABI/wire/on-disk compatibility, version skew, migration tooling, rollout mechanics, reversibility, and consumer impact. Produces a written review report. Use when an RFC touches a stable surface (public API, plugin ABI, on-disk or wire format), or as a follow-up pass after `/rfc-review` flags compatibility as a deeper concern.

Deep operational-concerns review of a technical RFC — build system impact, packaging, CI, observability, performance-in-production, deployment, capacity, and failure modes. Use as a focused follow-up to /rfc-review when the operational lens deserves more than the umbrella's one-paragraph pass, or standalone when the RFC is primarily ops-shaped (new dependency, build/CI change, perf-sensitive subsystem). Not a substitute for /review on implementation PRs.

Deep-dive security review of a technical RFC or design document — threat model, trust boundaries, attack surface, input validation, crypto, authN/authZ, secrets, supply chain, privacy, and audit. Use when reviewing an RFC and security warrants its own focused pass, or as a follow-up from /rfc-review. NOT for reviewing implementation diffs — use /security-review for that.

Review a technical RFC or design document across a structured set of perspectives (framing, design correctness, change management, operational concerns, sustainability) and produce a written review report. Use when reviewing RFCs, design docs, ADRs, or proposal documents — not for reviewing implementation PRs (use /review for that).

Generate hipDNN operation boilerplate from a YAML config. Use when the user wants to add a new operation type to hipDNN, or generate descriptor/packer/unpacker code.