vgpu: Skill for Claude Code

Visual explainer

Explain the mechanism so a reader unfamiliar with the implementation can follow it from their own code to the outcome. This is the shared visual and narrative style for the repository; it does not grant permission to implement a fix or publish a PR. Follow the active workflow in AGENTS.md. Write in the user's language for personal explanations and the repository's language for PR descriptions unless directed otherwise.

Establish what is being explained

Read the issue or request, relevant source/API docs, and available reproduction or validation evidence. For a PR, identify its base and head and inspect both versions where behavior changed. Distinguish the reported symptom, confirmed cause, proposed solution and implemented result. If the fix is only proposed, label it as proposed throughout; do not present predictions as results. Use one representative example throughout the explanation. Name omitted setup and define terms when the reader first needs them. Do not infer an API from a diagram or an old draft.

Narrative: problem first, then solution

1. Make the problem explicit before the first snippet. Name who encounters it, the trigger, expected behavior and actual outcome. Use a heading such as "The problem — before this PR" and state that the following steps trace the old behavior. For an unfixed issue, say "The current problem". "Summary" or "User code" alone does not establish what is being shown.
2. Start at user code or an action. Show a small, representative snippet with syntax highlighting. Explain whether it is valid code exposing a library problem, incorrect usage, or a workaround. If the code is valid, do not imply the user needs to repair it.
3. Follow the system step by step. Connect the user call to the necessary internal work, the failure point and its observable consequence. Use short sections, one causal step each. Separate correct mechanisms required for safety or semantics from the actual defect.
4. Mark the transition to the solution. Use a separate heading such as "The solution — after this PR" or "Proposed solution". Trace the same example through the changed steps, explain why they fix the problem, and state whether user code changes. For a feature, use "Previous limitation" and "New behavior" instead of inventing a bug. For a refactor, state that observable behavior is unchanged.
5. Show the result and limits. Give supported before/after evidence with units, workload, environment and conditions such as warmup. Separate allocations, CPU time and GPU throughput; mock and native results; measured outcomes and expectations. Keep unmet targets and material limitations visible in the human explanation, not only in a technical appendix.