"Use advanced Jittor extension APIs for custom operators, jt.code
Scanned 9/8/2026
Install to Claude Code
npx -y skills add VectorSpaceLab/AREX-Skill --skill custom-op-console-and-tools --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Custom Op Console And Tools?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/vectorspacelab-custom-op-console-and-tools)More formats (shields.io, HTML) on the badges page.
---
name: custom-op-console-and-tools
description: "Use advanced Jittor extension APIs for custom operators, jt.code
kernels, C++ console embedding, and safe utility or converter workflows."
disable-model-invocation: true
metadata:
disco-role: operating
license: Apache 2.0
---
# Custom op, console, and tools
Use this sub-skill when a task asks for advanced Jittor extension surfaces: inline `jt.code`, compiled custom ops, meta-operator design, C++ console embedding, utility CLI flags, or bounded PyTorch conversion/interoperability notes.
Do not use it for ordinary model/layer training, package installation, CUDA toolkit setup, dataset/model zoo workflows, or low-level framework internals that are not exposed by the public APIs. Route those tasks to the appropriate sibling sub-skill.
## Read and run map
| Need | Use |
| --- | --- |
| Decide between meta-operators, `jt.code`, `compile_custom_op`, and `compile_custom_ops` | Read [references/custom-op-and-code.md](references/custom-op-and-code.md). |
| Write or review a CPU-first custom code-op smoke check | Run [scripts/custom_op_smoke.py](scripts/custom_op_smoke.py) with `--help`, then `--skip-compile` or the default tiny CPU smoke. |
| Generate C++ console compile flags, example source, or a compile command template | Read [references/console-and-utilities.md](references/console-and-utilities.md) and run [scripts/jittor_console_flags.py](scripts/jittor_console_flags.py). |
| Diagnose compiler, shape, dtype, CUDA, console-link, converter, or unsafe-service failures | Read [references/troubleshooting.md](references/troubleshooting.md). |
## Default operating workflow
1. Confirm the user really needs an extension surface. Prefer meta-operators for shape-indexing algebra, `jt.code` for small inline C++/CUDA kernels, and `compile_custom_op(s)` only for larger op classes or multi-file C++/CUDA implementations.
2. Verify a CPU path first. A CUDA kernel, CUDA branch in a custom op, or CUDA-only `jt.code` snippet is a separate optional verification step and must be guarded by CUDA availability.
3. Keep shape and dtype contracts explicit. Record output shapes/dtypes before writing source strings; verify with tiny arrays and synchronized values before scaling.
4. For C++ console embedding, use `jittor_utils.config` through the bundled wrapper to generate flags or example code. Do not assume the host has a linkable Python shared library or a C++17-capable compiler.
5. Treat converter and service utilities as boundary tools. Text conversion still requires manual review and tests; service/server scripts are not safe defaults.
## Safety gates
- Do not start long-running converter services, Docker containers, network listeners, or network downloads unless the user explicitly requests that service work and accepts the boundary.
- Do not claim CUDA verification from a CPU run. Use optional CUDA probes only when the runtime backend is available and intentionally selected.
- Do not paste local include, library, cache, or checkout paths into generated guidance. CLI wrappers may print user-local flags at run time because those are compile inputs, but reference material should stay path-agnostic.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!