Rust GPU Discipline

Why this skill exists

When asked to write GPU-accelerated Rust code, the model has a strong, well-documented bias toward the path of least resistance: write a CPU implementation, hide it behind a name that sounds GPU-flavored, and report "done." This happens because:

• CPU code is dense in training data; kernel code is rare.
• CPU code passes cargo test immediately; GPU code requires hardware the sandbox doesn't have, so the model gets fake confirmation by writing the CPU version.
• Stubs (todo!(), unimplemented!(), // TODO: GPU) feel like progress. They aren't.
• "Fall back to CPU when CUDA isn't available" is a real engineering pattern that the model abuses to avoid writing the GPU path at all.

This skill stacks multiple friction points to make the lazy path harder than the correct path. The techniques used: pre-commitment (write the plan before the code), negative-space modeling (concrete forbidden examples, not abstract warnings), mechanical self-verification (grep-able checks, not vibes), adversarial self-critique (review the diff as a hostile reviewer would), and inverted defaults (GPU is the default, CPU requires justification).

If the model finds itself wanting to skip a step in this skill, that desire is the signal that the step is needed.

Step 0 — Probe the environment (REQUIRED, BEFORE STEP 1)