How do I install the Validate Extension skill?

Run npx skillmds@latest add arm-software/validate-extension in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Validate Extension skill do?

Validate the implementation and support in lavatube for a given Vulkan extension It is listed under Coding & Dev Tools on SkillMD.

Is Validate Extension safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Validate Extension?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Validate Extension free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Validate Extension?

arm-software (@arm-software) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Validate Extension by arm-software — Agent Skill

Name: Validate Extension
Author: arm-software

File contents

Check that we were told which Vulkan extension we are supposed to check. If this was not specified, ask.
Download the extension text from https://docs.vulkan.org/refpages/latest/refpages/source/<extension name>.html and read it.
For each new Vulkan command defined in the given extension, look for its generated implementation named trace_<name> in generated/write_auto.cpp. Review it for errors, then compare it to the corresponding read function named retrace_<name> in generated/read_auto.cpp. Verify that the serialized output is likely to be read back in correctly. If not found in generated code, they may have been hardcoded in code in the src directory instead.
For each new Vulkan structure defined in the given extension, look for its generated implementation named write_<name> in generated/struct_write_auto.cpp. Review it for errors, then compare it to the corresponding read function named read_<name> in generated/struct_read_auto.cpp. Verify that the serialized output is likely to be read back in correctly. If not found in generated code, they may have been hardcoded in the src/hardcode_*.cpp files instead.
Check if any new object types are defined in the given extension. If so, look at the Vulkan creation command for the object type, and see if there is any metadata there we should be tracking. If so, that should be in src/lavatube.h under its corresponding trackable child class. The trackable class is typically named the same as the object type but in all lower case and its vk prefix replaced with tracked.
Check if the extension has been promoted to core (e.g. "Promotion to Vulkan 1.3"). If it has been promoted, and we have any hardcoded functions, check if these also have core equivalents (ie function name without the extension suffix). Warn if these are missing. Check also if there are hardcoded core functions that are missing extension variants.
If the extension adds support for any new SPIRV opcodes, check if these are handled by the spirv-simulator in external/spirv-simulator/framework/spirv_simulator.cpp.
Check if there are any tests in either our tests directory or in external/tracetooltests that use this extension. Make a short note if no tests were found.

---name: validate-extensiondescription: Validate the implementation and support in lavatube for a given Vulkan extension---1. Check that we were told which Vulkan extension we are supposed to check. If this was not specified, ask.2. Download the extension text from `https://docs.vulkan.org/refpages/latest/refpages/source/<extension name>.html` and read it.3. For each new Vulkan command defined in the given extension, look for its generated implementation named `trace_<name>` in `generated/write_auto.cpp`. Review it for errors, then compare it to the corresponding read function named `retrace_<name>` in `generated/read_auto.cpp`. Verify that the serialized output is likely to be read back in correctly. If not found in generated code, they may have been hardcoded in code in the `src` directory instead.4. For each new Vulkan structure defined in the given extension, look for its generated implementation named `write_<name>` in `generated/struct_write_auto.cpp`. Review it for errors, then compare it to the corresponding read function named `read_<name>` in `generated/struct_read_auto.cpp`. Verify that the serialized output is likely to be read back in correctly. If not found in generated code, they may have been hardcoded in the `src/hardcode_*.cpp` files instead.5. Check if any new object types are defined in the given extension. If so, look at the Vulkan creation command for the object type, and see if there is any metadata there we should be tracking. If so, that should be in `src/lavatube.h` under its corresponding `trackable` child class. The trackable class is typically named the same as the object type but in all lower case and its `vk` prefix replaced with `tracked`.6. Check if the extension has been promoted to core (e.g. "Promotion to Vulkan 1.3"). If it has been promoted, and we have any hardcoded functions, check if these also have core equivalents (ie function name without the extension suffix). Warn if these are missing. Check also if there are hardcoded core functions that are missing extension variants.7. If the extension adds support for any new SPIRV opcodes, check if these are handled by the spirv-simulator in `external/spirv-simulator/framework/spirv_simulator.cpp`.8. Check if there are any tests in either our `tests` directory or in `external/tracetooltests` that use this extension. Make a short note if no tests were found.

Frequently asked questions

Validate Extension