What does this skill do, and when should you use it?
This skill is for optimizing cuTile GPU kernels in the TileGym project. It establishes a baseline, applies one optimization per experiment, verifies correctness, and reruns performance benchmarks. It covers tile sizes, occupancy, autotuning configurations, TMA, latency hints, persistent scheduling, num_ctas, and flush_to_zero. Latency is the core metric, while numerical correctness must be preserved throughout.
It guides an agent to create an optimization branch, locate the TileGym cuTile kernel, inspect its launch wrapper, registration, and autotune configurations, and consult the referenced optimization materials. It creates and updates @sandbox/perf_results.md, runs pytest correctness and performance commands, compares latency_ms across iterations, and decides whether to keep, revert, or stop. It can also use IR-level inspection and bottleneck analysis to diagnose performance or compilation issues.
- A TileGym developer needs to reduce the GPU latency of an existing cuTile kernel.
- An engineer needs profiling-guided diagnosis of memory, compute, occupancy, or scheduling bottlenecks.
- A kernel author wants to evaluate TMA, tile-size, occupancy, or persistent-scheduling changes one at a time.
- A team needs reproducible records of correctness results, latency measurements, and optimization decisions.
- A developer needs to compare generated IR while investigating a cuTile performance or compilation issue.
How do you install this skill?
- Before execution, explicitly confirm branch creation, commits, resets, and temporary-directory cleanup, and protect existing uncommitted changes.
- Verify the actual GPU architecture, cuTile/tileiras versions, test paths, and TMA out-of-bounds semantics; in particular, prevent silent corruption on Ampere by using ZERO padding or a safe fallback.
- Resolve the license metadata conflict, add real CI/test reproduction evidence, and rerun evaluation; the supplied benchmark reports an overall FAIL.
- The documentation has no Chinese guidance and the core workflow depends on specific GPUs and NVIDIA software infrastructure.
- Shell / CLI
- Local filesystem
GitPythonpytestcuTileTileGym repositoryGPU node with Blackwell, Hopper, or Ampere GPU
Install the individual skill from NVIDIA/skills with the skills CLI:
npx skills add nvidia/skills --skill tilegym-improve-cutile-kernel-perf --yes
You may also use --agent codex or --agent claude-code to target a client. The README does not document a manual folder-copy installation path.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/tilegym-improve-cutile-kernel-perf" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Optimize this cuTile kernel performance in TileGym.
- improve kernel perf
- tune cutile performance
- make kernel faster
After the skill is loaded, use a request such as:
"Optimize this cuTile kernel performance in TileGym."
Other supported trigger wording includes "improve kernel perf", "tune cutile performance", and "make kernel faster". Prepare the TileGym repository, a suitable GPU node, and the test environment; the workflow asks for confirmation during setup before experimentation begins.
What are this skill's strengths and limitations?
- Provides a concrete baseline-to-experiment-to-decision workflow.
- Uses latency (ms) as the primary metric and requires correctness verification for every change.
- Covers specific cuTile tuning areas, including TMA, tile sizes, occupancy, autotuning, and IR debugging.
- Requires structured records of latency, correctness, and iteration status.
- Requires the TileGym repository, cuTile, Python pytest, Git, and a GPU node.
- Benchmarking is documented for Blackwell, Hopper, or Ampere GPUs, with no alternative CPU-only workflow.
- The skill provides no kernel-specific test data or demonstrated performance-improvement results.
- A ten-minute limit per iteration and a 25-iteration cap may constrain complex optimization work.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| TileGym cuTile Kernel Optimizer this page ✓ NVIDIA · Official | 44 · Not recommended | ★ 3.8k | today | Apache-2.0 |
| CuTile Autotuning Guide ✓ NVIDIA · Official | 52 · Use with care | ★ 3.8k | today | Apache-2.0 |
| TileGym cuTile Kernel Guide ✓ NVIDIA · Official | 53 · Use with care | ★ 3.8k | today | Apache-2.0 |
| cuTile Python Kernel Assistant ✓ NVIDIA · Official | 44 · Not recommended | ★ 3.8k | today | Apache-2.0 |
| cuTile-to-Triton Kernel Converter ✓ NVIDIA · Official | 38 · Not recommended | ★ 3.8k | today | Apache-2.0 |
How did FollowSkills review this skill?
The skill constrains editable files, requires correctness checks, and explicitly warns that out-of-bounds TMA use on Ampere can silently corrupt results. However, it includes git checkout/reset, commits, and rm -rf operations, while user confirmation, protection of pre-existing uncommitted changes, rollback boundaries, and data-flow disclosure are incomplete. The repository license metadata is NOASSERTION and conflicts with the file's declared licenses, so points were deducted.
The three-phase workflow, one-change-per-iteration method, experiment log, benchmark commands, and failure diagnostics are reasonably coherent. Reliability is reduced by dependence on specific GPUs, cuda-tile, tileiras, repository tests, and external environment setup; placeholder paths and commands are not directly reproducible, and the Blackwell/Hopper/Ampere support statements are inconsistent. Static calibration limits this to 6.
The audience, cuTile performance scenario, trigger phrases, kernel locations, and optimization scope are fairly clear, with some non-fit cases documented. However, systematic non-goals, output expectations, and fallback behavior when prerequisites fail are incomplete; there is no Chinese-language guidance, and the GPU-node requirement limits general applicability. Points were deducted.
The documentation is substantially layered across API, patterns, performance model, playbook, logging, version, and author metadata. It still contains duplicated material, references files not included in the supplied evidence, lacks a clear changelog and maintenance/update path, uses a future-dated version format without release context, and conflicts with the repository license metadata. Points were deducted.
The skill gives a directly usable workflow for profiling, applying one optimization at a time, checking correctness, comparing latency, and deciding keep/revert, with an explicit tracking-table format. Its value depends heavily on an available GPU, complete TileGym tests, and real benchmarks; claimed impact examples are not independently verified in the supplied files, and the included evaluation report has an overall FAIL verdict. Static calibration therefore caps and reduces the score to 6.
The committed evaluation tasks, reported results, command templates, performance-log schema, and diagnostic procedures provide some auditability. There is no real CI workflow, independently checkable execution output, or corroborating reproduction evidence; the benchmark is primarily a report claim, and key paths were not executed during this review. Static calibration supports 4 points.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →