Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vipshop/cache-dit/operator-migrationnpx skills add vipshop/cache-dit --skill operator-migrationgit clone --depth 1 https://github.com/vipshop/cache-ditWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00094 | $0.03171 |
| Opus 5 | $0.00047 | $0.01586 |
| Sonnet 5 | $0.00019 | $0.00634 |
| Haiku 4.5 | $0.00009 | $0.00317 |
Grade A, and why
operator-migration scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 411 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Operator Migration for cache-dit
Goal
Migrate one operator or kernel family into cache-dit in a way that is:
- semantically correct
- aligned with cache-dit repository conventions
- safe to import when optional native extensions are absent
- validated at multiple layers instead of by one smoke test
This skill is for migration work that touches native code, Python wrappers, operator registration, build packaging, or quantized module integration.
When to Use
Use this skill when you need to:
- migrate a CUDA or Triton operator from another repo into cache-dit
- port a nunchaku operator or kernel family into cache-dit
- decide what native files are actually required for a migration
- design cache-dit public wrappers for a newly migrated operator
- register low-level ops through cache-dit's CUDA registry layer
- add optional-extension build logic, submodule checks, or packaging guards
- design layered validation for a migrated operator
- review whether an operator migration plan is thoughtful or mechanical
Do not use this skill for:
- generic model integration with no operator or kernel work
- pure Python feature work unrelated to kernels or extensions
- blind "copy upstream into csrc" execution
Core Rule
Do not mechanically replay upstream structure.
Treat the source repository as the reference for semantics, not as the required layout.
Before writing code, answer these questions:
- What behavior is essential to preserve?
- What is the smallest native and Python closure needed to preserve that behavior?
- Which names should remain source-compatible, and which should be renamed to match cache-dit conventions?
- What must be public, and what should remain private implementation detail?
- Which tests prove the migration works, instead of merely compiling?
If those questions are not answered yet, do not start copying files.
Reference Style Rule
Use portable references only.
- For cache-dit files, use repo-relative paths such as
src/cache_dit/kernels/ops.pyortests/kernels/test_svdquant_runtime.py. - For sibling or external repos, use repository-relative or GitHub-searchable paths such as
nunchaku/nunchaku/models/linear.pyordeepcompressor/deepcompressor/backend/nunchaku/utils.py. - Do not write machine-local absolute paths such as
/abs/path/to/workspace/...into the skill or its supporting documentation.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 411 lines · 94 tokens per session scan A 184f70f5d1d2
operator-migration is a skill published in the GitHub repository vipshop/cache-dit (1,262 stars, last pushed 5d ago), licensed Apache-2.0. It adds 94 tokens to every session and 3,171 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
add-sgl-kernel
Step-by-step tutorial for adding a heavyweight AOT CUDA/C++ kernel to sgl-kernel (including tests & benchmarks).
spanify-buffers
Find and fix unsafe buffer operations in a C++ file by removing UNSAFETODO markers and replacing unsafe raw pointers/C-style functions with base::span and standard safe containers. Use when the user asks to fix unsafe buffer warnings or -Wunsafe-buffer-usage errors. Don't use for other types of memory safety bugs like…
jni-type-conversion
How to use @JniType annotations for ergonomic JNI. Relevant for Java files that use @NativeMethods or @CalledByNative.
new-cpp-lint
Create a new C++ lint rule, test it, run it across the codebase, and selectively apply fixes. Usage - /new-cpp-lint.
platform-port
Guide porting FastLED to new MCU platforms, including int.h types, clockless drivers, SPI implementations, and platform detection. Use when adding support for a new microcontroller family or board.
qt-cpp-review
Invoke when the user asks to review, check, audit, or look over Qt6 C++ code — or suggest before committing. Runs deterministic linting (60+ rules) then six parallel deep- analysis agents covering model contracts, ownership, threading, API correctness, error handling, and performance. Reports only high-confidence…