Skill: kklouzal/vulkan-encyclopedia (version 0.1.0)

--- name: vulkan-encyclopedia description: >- Vulkan specification/reference workflow for Vulkan-API-specific questions, exact command and structure semantics, valid-usage and VUID lookup, synchronization reasoning, pipeline/resource setup, extension/feature checks, limits/formats/capabilities review, and code review in a Vulkan API context. Use when the request is clearly about Vulkan itself: `Vk*` types, `vk*` commands, VUIDs, instance/physical-device/logical-device setup, swapchains, queues, command buffers, descriptors, render passes or dynamic rendering, pipelines, memory/resources, synchronization, SPIR-V in a Vulkan pipeline context, or extension/feature behavior. Do not use for generic graphics programming, engine-level rendering design, shader-language-only questions, OpenGL, Direct3D, Metal, CUDA, or generic shader authoring unless the Vulkan API/spec layer is materially involved. metadata: {"openclaw":{"emoji":"🌋","homepage":"https://docs.vulkan.org/spec/latest/index.html"}} --- # Vulkan Encyclopedia ## Overview Use a docs-first workflow for Vulkan work. Prefer the official Vulkan specification/reference docs at `https://docs.vulkan.org/spec/latest/index.html`, consult cached local copies under `.Vulkan-Encyclopedia/` before re-fetching, and record useful authoritative excerpts plus environment-specific operational learnings so future work gets faster, safer, and more grounded. This skill is for the **Vulkan API/spec layer**, not for generic rendering theory and not for standalone shader-language questions unless they are being asked in direct service of Vulkan API behavior. ## Workflow 1. **Classify the task** - Decide whether the task is a Vulkan API question, specification lookup, code-review task, validation/debugging task, architecture/design task, or live implementation task. - Use this skill when the task materially depends on Vulkan API semantics, Vulkan object/command structure, extension/feature behavior, synchronization rules, limits/capabilities/formats, or validation/spec interpretation. - Do not use this skill for generic graphics concepts, standalone shader-language work, or engine-level rendering discussion unless the Vulkan API/spec layer is actually in play. 2. **Check local cache first** - Use `.Vulkan-Encyclopedia/` as the local knowledge/cache root. - Check these locations first when relevant: - `.Vulkan-Encyclopedia/docs/docs.vulkan.org/spec/latest/...` - `.Vulkan-Encyclopedia/notes/components/...` - `.Vulkan-Encyclopedia/notes/patterns/...` - `.Vulkan-Encyclopedia/inventory/...` - If a cached page or note already answers the question well enough, use it. 3. **Consult authoritative Vulkan docs before answering or acting** - Before answering direct or indirect Vulkan questions that depend on API semantics, exact command/structure rules, feature or extension behavior, synchronization guarantees, limits, valid usage, or version-sensitive details, consult the official Vulkan docs unless the answer is already well-supported by the local cache. - Before performing non-trivial Vulkan code review or implementation guidance, consult the relevant docs first when: - exact member names, allowed states, or command rules matter - synchronization or resource-lifetime behavior is easy to misremember - the task involves VUID interpretation, extension/feature enabling, or pipeline/resource correctness - If the problem is really about GLSL syntax/qualifiers/stage interfaces rather than Vulkan API semantics, prefer the GLSL skill instead of stretching this one. - Do not improvise fragile Vulkan answers from memory when the spec is easy to check. 4. **Cache consulted docs locally** - When you consult a Vulkan docs page, save a normalized cache copy under `.Vulkan-Encyclopedia/docs/docs.vulkan.org/spec/latest/...`. - Mirror the official docs path structure as much as practical. - Cache only pages actually consulted; do not try to mirror the whole spec eagerly. - Use `scripts/cache_doc.py` when appropriate. 5. **Separate authoritative documentation from local observations** - Store official-doc-derived material under `.Vulkan-Encyclopedia/docs/...`. - Store environment-specific operational knowledge under: - `.Vulkan-Encyclopedia/notes/components/` - `.Vulkan-Encyclopedia/notes/patterns/` - `.Vulkan-Encyclopedia/inventory/` - Distinguish clearly between: - authoritative documented behavior - observed project/environment state - inferred best-practice guidance 6. **Record useful local learnings** - After useful live work, save durable notes such as: - project-specific Vulkan architecture notes - recurring validation/debugging patterns - extension/feature adoption decisions - synchronization/resource-management gotchas - safe/unsafe operational boundaries for the codebase or environment - Prefer concise durable notes over re-learning the same Vulkan details later. ## Live Work Rules - Treat spec lookup as the default preflight for non-trivial Vulkan work. - Prefer read/inspect first when entering unfamiliar Vulkan code. - Treat synchronization, memory/resource lifetime, queue ownership, layout transitions, extension/feature gating, and validation/VUID interpretation as higher-sensitivity areas. - When uncertainty remains after checking cache + docs, say so and avoid bluffing. - When answering a question, mention when useful whether the answer comes from cached official docs, a fresh official docs lookup, or live observed project state. ## Data Root Use this workspace-local root for cache and notes: - `.Vulkan-Encyclopedia/` Expected structure: - `.Vulkan-Encyclopedia/docs/docs.vulkan.org/spec/latest/...` - `.Vulkan-Encyclopedia/notes/components/...` - `.Vulkan-Encyclopedia/notes/patterns/...` - `.Vulkan-Encyclopedia/inventory/...` Use `scripts/init_workspace.py` to create or repair the expected directory structure. ## Note Destinations - Component-specific observations → `.Vulkan-Encyclopedia/notes/components/<component-name>.md` - Reusable Vulkan patterns/gotchas → `.Vulkan-Encyclopedia/notes/patterns/<topic>.md` - Environment-wide architecture/access info → `.Vulkan-Encyclopedia/inventory/*.md` - Cached official docs → `.Vulkan-Encyclopedia/docs/docs.vulkan.org/spec/latest/...` ## Secrets / Sensitive Data - Do not store plaintext credentials, API keys, session tokens, private URLs, recovery codes, or other secrets in the encyclopedia notes/inventory tree. - If a note needs to mention access details, keep it high-level and redact or omit secret material. - Treat these workspace notes as operational memory, not as a secrets vault. ## Resources - `scripts/init_workspace.py` — create or repair the `.Vulkan-Encyclopedia/` directory tree. - `scripts/cache_doc.py` — fetch and cache a consulted official Vulkan docs page under `.Vulkan-Encyclopedia/docs/...`. - `references/workflow.md` — detailed operating workflow and evidence-handling rules. - `references/cache-layout.md` — canonical `.Vulkan-Encyclopedia/` directory structure. - `references/topic-map.md` — useful Vulkan topic groupings for faster authoritative lookup. ## Good Outcomes - Answer a Vulkan question using cached or freshly checked official docs instead of guesswork. - Inspect Vulkan code after checking the relevant spec pages and record any new project-specific operational knowledge. - Build a growing local Vulkan knowledge cache that makes later work faster, safer, and more grounded. - Turn one-off Vulkan discoveries into durable notes so future work does not rediscover them from scratch. ## Avoid - Answering Vulkan-specific questions purely from memory when the spec is easy to consult. - Treating local observed engine/project behavior as if it were guaranteed authoritative Vulkan behavior. - Dumping large amounts of low-value docs into the workspace without a reason. - Writing project-specific observations into the official-doc cache tree. - Making high-confidence claims about synchronization/valid-usage details without checking the spec when exact behavior matters.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)