From xonovex-skill-gpu-rendering-vulkan
Use when implementing a Vulkan renderer: the concrete Vulkan API for device/queues, device memory + memory types + staging, images/buffers + pipeline barriers and layout transitions, descriptor sets/layouts + bindless, pipelines + pipeline cache + dynamic rendering, timeline semaphores + fences, command pools/buffers, and the swapchain. Triggers on Vk* types and vkCmd*/vkCreate* calls, VkImageMemoryBarrier2, VkDescriptorSet, VkPipeline, VkSemaphore, VkCommandPool, swapchain acquire/present, even when the user doesn't say 'Vulkan'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/xonovex-skill-gpu-rendering-vulkan:gpu-rendering-vulkan-guideThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The concrete Vulkan API for a low-level renderer. This skill is the Vulkan _how_; for the _why_ and the API-agnostic architecture (render graphs, binding model, sync model, frames-in-flight, memory strategy) see gpu-rendering-guide. For the general allocator principle behind device memory see memory-management-guide.
The concrete Vulkan API for a low-level renderer. This skill is the Vulkan how; for the why and the API-agnostic architecture (render graphs, binding model, sync model, frames-in-flight, memory strategy) see gpu-rendering-guide. For the general allocator principle behind device memory see memory-management-guide.
VK_KHR_synchronization2, VK_KHR_dynamic_rendering, VK_EXT_descriptor_indexing, VK_KHR_timeline_semaphore).VkInstance → physical device → VkDevice; select graphics/compute/transfer queue families, see references/device-and-queues.mdVkPhysicalDeviceMemoryProperties types/heaps; few vkAllocateMemory + sub-allocation; staging, see references/device-memory.mdVkImage/VkBuffer + views, VkImageMemoryBarrier2 stage/access masks, layout transitions, see references/resources-and-barriers.mdVkSemaphore (binary + timeline), VkFence, pipeline stage/access masks, submit-time waits, see references/synchronization.mdVkDescriptorSetLayout/Pool/Set, update-after-bind for bindless, push constants, set frequency, see references/descriptors.mdVkPipeline (graphics/compute), VkPipelineCache, dynamic rendering vs render passes, dynamic state, see references/pipelines.mdVkCommandPool per thread per frame, primary/secondary buffers, VkSwapchainKHR acquire/present, fence per frame, see references/commands-and-swapchain.mdvkAllocateMemory is hard-capped (maxMemoryAllocationCount, often ~4096) and slow; sub-allocate from a few large blocks. The architecture rationale is in gpu-rendering-guide.VkImageMemoryBarrier2 that omits the layout transition, or uses oldLayout that does not match the image's current layout, is undefined behavior — track current layout per image/subresource.VkDescriptorSet updated while the GPU may still read it (without UPDATE_AFTER_BIND) is a data race — gate on the frame VkFence.VkPipeline whose dynamic state you forgot to set (e.g. vkCmdSetViewport) draws nothing or validation-errors; declare every dynamic state you rely on.VK_ERROR_OUT_OF_DATE_KHR/VK_SUBOPTIMAL_KHR from acquire/present leaves a stale swapchain after resize — recreate it.VkImageMemoryBarrier2/layout transitionsVkPipelines, the pipeline cache, or dynamic renderingVkSemaphore/VkFence, stage/access masks, or submit-time waitsGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.
npx claudepluginhub xonovex/platform --plugin xonovex-skill-gpu-rendering-vulkan