Menu
Use when building Zig projects with xmake — binary/library targets with `.zig` sources, cross-compilation (one of Zig's strengths), and mixing Zig with C.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when switching xmake's output theme (colors, progress style, emoji) or fixing garbled/unreadable terminal output — `xmake g --theme=...`. Built-in themes: default, ninja, emoji, dark, light, plain, powershell.
Use when the user is starting a new Xmake project, installing Xmake, or needs the minimal xmake.lua structure. Covers installation, `xmake create`, the project layout, and the smallest valid xmake.lua.
Use when writing or reviewing an `xmake.lua` (project, package recipe, or toolchain) and you want to follow idiomatic xmake style — description vs script domain separation, naming, indentation, `set_` vs `add_`, option/config organization, and common conventions used across xmake-repo and the xmake project itself. Apply this alongside `xmake-targets`/`xmake-packages`/etc. as a stylistic overlay.
Use when creating a new xmake project from a built-in or third-party template (`xmake create -t <template>`), listing available templates, or authoring and distributing custom templates (built-in, user-global, or via xmake-repo). Covers template layout, `${TARGET_NAME}` / `${FAQ}` substitution, and language selection.
Use when invoking Xmake from the command line — configuring, building, running, cleaning, installing, packing, or inspecting a project. Covers the common flags for `xmake f`, `xmake`, `xmake run`, `xmake install`, `xmake pack`, and friends.
Use when exporting an xmake project to another build system or IDE — `compile_commands.json` for clangd/LSP, `CMakeLists.txt`, `build.ninja`, Visual Studio solution (`vsxmake`), or an Xcode project. Covers `xmake project -k <kind>` and how each generator is typically used.
| name | xmake-zig |
| description | Use when building Zig projects with xmake — binary/library targets with `.zig` sources, cross-compilation (one of Zig's strengths), and mixing Zig with C. |
Xmake drives zig build-exe / zig build-lib under the hood. Zig is particularly nice because its native cross-compile story plays well with xmake's toolchain selection.
xmake create -l zig -t console hello
cd hello
xmake run
add_rules("mode.debug", "mode.release")
target("hello")
set_kind("binary")
add_files("src/*.zig")
target("app") set_kind("binary")
target("mylib") set_kind("static")
target("mydyn") set_kind("shared")
xmake f --toolchain=zig
xmake f --toolchain=zig --sdk=/opt/zig-0.12
Zig is auto-detected when zig is on PATH. Pin with --sdk for a specific install.
Zig has built-in cross-compile for every target it supports — no extra SDK needed:
xmake f -p windows -a x86_64 --toolchain=zig
xmake f -p linux -a arm64 --toolchain=zig
xmake f -p macosx -a arm64 --toolchain=zig
xmake
Xmake passes -target <triple> to zig build-exe. Far easier than GCC/Clang cross-SDKs.
Zig ships its own C compiler (zig cc) that can build C files. You can mix them in one target:
target("app")
set_kind("binary")
add_files("src/main.zig", "src/helper.c")
add_includedirs("include")
Zig imports C via @cImport. No bridging needed.
Bonus trick: point xmake's C toolchain at zig cc for free cross-compile of C projects:
xmake f --toolchain=zig
xmake f --cc="zig cc" --cxx="zig c++"
This is especially useful for MinGW-free Windows builds from Linux.
build-exe / build-lib flags change between versions. Pin --sdk to a known version in CI..zig and .cpp in one target. .zig + .c is fine; C++ is more brittle — use a separate target with add_deps.-target <triple> gives you a cross-compile, but you still need the right dynamic linker at runtime on the target — Zig can produce static binaries if you prefer (-fno-pie etc.).-p, -a, --sdk) → xmake-cross-compilationxmake-targets