lrt-rocm-workspace

Use when setting up the lrt-rocm workspace for the first time, or when a new team member installs the plugin

Use when starting any conversation - establishes how to route tasks to the right skills using the routing table

Use when building CLR (HIP/OCL) with PAL and/or ROCr backends on Windows using rocm-systems — covers prerequisites, CMake flags, build configurations, and troubleshooting for d3dumddi.h and Clang discovery issues

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when executing implementation plans with independent tasks in the current session

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Use when you have a spec or requirements for a multi-step task, before touching code

Use when explicitly building via the rocm-systems monorepo (not the default — use lrt-rocm:the-rock for HIP/OCL builds). Covers rocm-systems branches/PRs, CI pipelines, and monorepo-specific troubleshooting

Use when building TheRock (ROCm) from source — covers Ubuntu/Windows dependency setup, Python venv, submodule management with DVC, full/optimized HIP/OCL build configurations, incremental rebuilds, test execution, nightly containers, and artifact downloads

Use when killing stale VSCode remote server and cleaning sockets

Use when preparing commit stack for PR with milestone review

Use when finding and addressing RVW review comments in source code

Use when preparing commit stack for squash into PR

Use when staging changes and opening VSCode diffs for review

Use when switching to working on a specific task (project)

Use when opening git diffs in VSCode (requires MCP extension)

Use when setting VSCode integration mode (local or remote)

Use when creating a quick WIP commit checkpoint

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when a HIP or OCL test that previously passed is now failing and you need to find which commit introduced the regression — drives git bisect with automated build and test at each step

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when creating new skills, editing existing skills, or verifying skills work before deployment