菜单
Open Enfusion Workbench (DayZ Tools' script + UI editor) from the CLI, optionally pointed at a specific mod's project file. Spawns detached with cwd=P:\ so vanilla data resolves. Default behavior loads the vanilla dayz.gproj shipped with DayZ Tools; --mod <ModName> loads the per-mod gproj scaffolded by /dayz-new-mod.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit and fix DayZ .p3d model files for collision, action targeting, physics, animation, path, and structural issues. Runs py3d-based validation against known-working reference patterns. Also validates config.cpp and .rvmat files for path and property issues. Use this skill whenever: a DayZ mod object has no collision, actions don't appear, the player walks through placed objects, CCTObject raycasts miss, Geometry LOD seems ignored, a model was exported from Blender and doesn't work in-game, textures are missing, animations don't play, or the user says "review the p3d", "check the model", "audit collision", "why no actions", "flag/object has no collision", "audit the mod", "check paths", "validate the model". Also trigger when debugging any placed Inventory_Base item. This is the GO-TO skill for P3D and mod structure debugging.
Bootstrap Community-Online-Tools (COT) admin permissions on a DayZ test server in one shot. Auto-prepends @CF + @Community-Online-Tools to the mod chain, launches the server + client, waits for your character to spawn (detected when COT writes the per-player files), kills the session, grants you the `admin` role in your Players JSON, flips every ` 0` to ` 2` in your personal `Permissions/<id>.txt` file, then relaunches. Per-player grant only — `Roles/everyone.txt` is never touched. Requires /dayz-init + /dayz-add-server + /dayz-build-pbo first.
Pull the latest Agentic-Z template improvements (agents, skills, conventions, docs) from upstream into your clone, without touching your DayZ mod work in workspace/. Adds the upstream remote on first run, fetches, shows a changelog, then merges only template-managed paths. Re-runs sync-skills automatically. Refuses if your working tree is dirty unless --force is passed.
Wipe ALL template-managed artifacts across every domain so the repo is ready to push. Orchestrator — discovers and runs every domain's `<domain>-clean-workspace` skill in turn (currently just `dayz-clean-workspace`). Future domains plug in here automatically when they ship their own cleanup skill following the naming convention. Interactive confirmation by default; --yes skips it; --dry-run lists what each domain would clean.
Add missing DayZ mod scaffolding pieces (config.cpp stub, $PBOPREFIX$, workbench/dayz.gproj + DayZSetting.xml, README, .gitkeeps) into an EXISTING workspace/<ModName>/ folder. Idempotent - never overwrites files that are already present. Used by /dayz-import-mod after symlinking an external mod, but also runnable directly when you cloned a mod into workspace/ manually and want the standard skeleton filled in.
Set up a DayZ test server instance under .server/<instance>/. Copies the mission template from DayZ Server install if missing, creates per-instance serverDZ.cfg + Profiles/ (server -profiles=) and a top-level shared .server/!ClientDiagLogs/ (client -profiles=). Each instance is isolated on the server side so you can run multiple variants of the same map (chernarus, chernarus-hardcore, etc.) without cross-contamination. Refuses if the legacy workspace/_server/ layout exists (delete it manually; that layout is no longer supported). Required before /dayz-launch-test for a given instance. Use --refresh-mission to re-copy mission content after a DayZ update.
| name | dayz-launch-workbench |
| description | Open Enfusion Workbench (DayZ Tools' script + UI editor) from the CLI, optionally pointed at a specific mod's project file. Spawns detached with cwd=P:\ so vanilla data resolves. Default behavior loads the vanilla dayz.gproj shipped with DayZ Tools; --mod <ModName> loads the per-mod gproj scaffolded by /dayz-new-mod. |
Path note:
<skill-dir>in commands below is the absolute path of this skill's folder. When the agent loads this skill the harness exposes the skill's base directory; substitute it before running. Sibling skills are reached via<skill-dir>\..\dayz-X\.
Open Workbench without leaving the terminal. Default loads vanilla DayZ; --mod <ModName> loads the customized dayz.gproj that /dayz-new-mod writes into workspace/<ModName>/workbench/, so Workbench compiles and lints vanilla + your mod together.
Follow .claude/skills/_shared/dayz-conventions.md.
/dayz-preflight.workbenchApp.exe via DayZ Tools (Bin\Workbench\workbenchApp.exe).--mod <ModName> → uses P:\<ModName>\workbench\dayz.gproj (the file scaffolded by /dayz-new-mod). Fails fast if the mod folder or gproj isn't there.--gproj <path> → uses an explicit .gproj path (escape hatch for non-scaffolded layouts).dayz.gproj shipped next to workbenchApp.exe.workbenchApp.exe with cwd=P:\ (so the gproj's Directory "./" resolves to the work drive root) and DETACHED_PROCESS so the shell returns immediately.Just open Workbench on vanilla:
python "<skill-dir>\launch.py"
Open with a mod's project file (compiles vanilla + mod together):
python "<skill-dir>\launch.py" --mod MyMod
(Requires P:\MyMod\workbench\dayz.gproj to exist — created automatically by /dayz-new-mod MyMod.)
Open with an arbitrary gproj:
python "<skill-dir>\launch.py" --gproj P:\Custom\path\to\my.gproj
/dayz-new-mod to start writing scripts/UI for a fresh mod with full code completion against vanilla..layout files or browse vanilla scripts in their native IDE.DayZ Workbench launcher
[OK] P:\ mounted
[OK] DayZ Tools: ...
[OK] Vanilla data: P:\dz
[OK] P:\Mods junction valid
[OK] workbenchApp.exe: ...\Bin\Workbench\workbenchApp.exe
[INFO] Project: P:\MyMod\workbench\dayz.gproj
[OK] Working directory: P:\
[OK] Workbench launched (PID 12345). The window may take a few seconds to appear.
--mod and --gproj are mutually exclusive.--mod is just the mod name; the skill expands to P:\<ModName>\workbench\dayz.gproj. Fails fast if either the mod folder or the gproj is missing.--gproj accepts an absolute path (relative paths resolve against repo root). Warns if the extension isn't .gproj.<DayZ Tools>\Bin\WorkbenchWorkbench loads its support files (dta\, platforms\, ToolAddons\) and its bundled dayz.gproj relative to cwd, not relative to workbenchApp.exe. Launching from anywhere else (including P:\) triggers a "cannot find file dayz.gproj" error even when a valid project file is passed as an argument. We always launch with cwd = <DayZ Tools>\Bin\Workbench\. The project file we pass as an arg is then loaded as the active project, while the support files resolve from the install dir as Workbench expects.
Vanilla data paths inside the gproj (e.g. DZ/Anims/cfg/..., gui/imagesets/...) are resolved by Workbench relative to the gproj file's location, NOT cwd — so as long as your mod's dayz.gproj lives next to its sibling <ModName>/ source tree on the work drive (the layout /dayz-new-mod produces), vanilla imports keep resolving via the P:\ junction the engine and Workbench share.
Running Workbench under the parent shell would block the terminal until you close the editor. We spawn with DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP so:
--mod for a mod that wasn't scaffolded by /dayz-new-mod — the workbench/dayz.gproj won't exist. Run /dayz-new-mod <ModName> first./dayz-new-mod re-runs to preserve your changes — the scaffolder writes a fresh copy each time. If you need custom modules beyond the auto-injected game/world/mission, keep your edits in a side file or accept that re-running scaffolding will overwrite.