wezdeck-runtime-ops
Skill4 starsChanged 48 days agoMITView on GitHub
Operate the WezDeck runtime environment: run the read-only environment and dependency checks, then synchronize this repository's WezTerm runtime. Reuse a valid cached target from repo-root `.sync-target` or `WEZTERM_SYNC_TARGET` when available; otherwise list candidate homes, confirm one with the user, and run the skill-owned sync script.
- Reads credentials
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- frontend-designSkill
- web-design-guidelinesSkill
- adversarial-reviewSkill
- brainstormSkill
- cross-repo-delegateSkill
- habit-weeklySkill
- human-runSkill
- repo-hygieneSkill
- worktree-recycleSkill
- yuns-engineerSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 6 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this skill for WezDeck environment checks and runtime sync.
- Very specific: line 14
Run from the repository root, or set WEZDECK_REPO=/absolute/path/to/repo (legacy WEZTERM_CONFIG_REPO still accepted) before invoking the …
- Distinctive: line 15
Run the read-only environment check when diagnosing or closing a runtime round:
- Very specific: line 26
If repo-root .sync-target or WEZTERM_SYNC_TARGET already points at an existing directory, run …
- Very specific: line 27
If there is no valid cached target, run skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --list-targets to print candidate user home …
- Very specific: line 29
After the user confirms a target, run skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --target-home /absolute/path.
- Distinctive: line 34
Do not ask the user to type into the script's interactive prompt.
- Distinctive: line 35
If a valid cached target exists and the user did not ask to change it, sync immediately with no extra confirmation step.
- Distinctive: line 36
If the cache is missing, invalid, or the user wants to change targets, use the explicit list-and-confirm flow above.
- Very specific: line 37
Prefer --target-home over WEZTERM_SYNC_TARGET when the user has explicitly confirmed a path, because --target-home also refreshes …
- Distinctive: line 38
If the requested target is outside the writable sandbox and the sync command fails with a filesystem permission error, rerun it with …
- Very specific: line 39
If --list-targets prints no directories, report that clearly instead of guessing a target.
- Distinctive: line 40
If the user names a path directly, validate that it is absolute and exists before running the sync.
- Very specific: line 41
Treat repo-root .sync-target as the cache for the chosen runtime home.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
WezDeck Runtime Ops
Use this skill for WezDeck environment checks and runtime sync. The check path is read-only and does not need a target home. The sync path writes the selected runtime target and owns canary publication, helper ensure, Lua prechecks, tmux reload, and post-sync diagnostics.
The scripts under skills/wezdeck-runtime-ops/scripts/ are the source of truth for sync prompting, target discovery, and prompt-format regression checks.
Workflow
- Run from the repository root, or set
WEZDECK_REPO=/absolute/path/to/repo(legacyWEZTERM_CONFIG_REPOstill accepted) before invoking the skill scripts. Run the read-only environment check when diagnosing or closing a runtime round:
skills/wezdeck-runtime-ops/scripts/check-runtime.shUse
--advisoryfor a non-blocking report and--skip-depswhen the network is unavailable. This check owns the aggregate view of Lua source syntax and managed config precheck, the configured agent CLI binary, agent hooks, the WSLagent-tools.envcapability marker, launcher permission overlays, resume-command/workspace-agent-map lockstep, Node/fnm runtime state, interactiveshell-env.dinjection (wezdeck-env.env+ thewezdeck:shell-env.dzsh snippet +grokas the focus-filter function), the WSL bridge binary (scripts/dev/check-wezdeck-wsl.sh:native/wezdeck-wsl/bin/wezdeck-wsl+ local socket smoke, and liveGET /api/v1/wslwhen the Runtime HTTP surface is up), the optional Rime commit counter, and WezTerm/tmux/Go dependency floors. The Rime check is advisory: when a Windows Rime user directory is present but the counter is not installed, it prints the install command without blocking the base runtime check. The shell-env and wezdeck-wsl checks are gates here; shell-env is only an advisory warning during sync (WEZTERM_SYNC_SKIP_SHELL_ENV_CHECK=1skips that warning).- Default sync stages a canary tree, auto-launches an isolated WezTerm probe, and promotes to live only if
healthy.stampappears (otherwise live is untouched and sync exits 1). Skip probe withWEZTERM_SYNC_SKIP_CANARY_AUTO=1. Use--liveto publish straight to the running GUI. Details:docs/daily-workflow.md. Windows targets are preflighted with a realpowershell.exeprobe before any canary files are written; if WSL interop is disabled, sync exits with the/etc/wsl.confandwsl --shutdownrepair steps. - If repo-root
.sync-targetorWEZTERM_SYNC_TARGETalready points at an existing directory, runskills/wezdeck-runtime-ops/scripts/sync-runtime.shwith no extra arguments. - If there is no valid cached target, run
skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --list-targetsto print candidate user home directories. - Present the candidates to the user and ask which path should be used. Accept either one of the listed paths or another absolute path the user explicitly provides.
- After the user confirms a target, run
skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --target-home /absolute/path. - Summarize the check and sync results, including warnings, canary outcome, and the chosen target path.
Rules
- Do not ask the user to type into the script's interactive prompt.
- If a valid cached target exists and the user did not ask to change it, sync immediately with no extra confirmation step.
- If the cache is missing, invalid, or the user wants to change targets, use the explicit list-and-confirm flow above.
- Prefer
--target-homeoverWEZTERM_SYNC_TARGETwhen the user has explicitly confirmed a path, because--target-homealso refreshes.sync-target. - If the requested target is outside the writable sandbox and the sync command fails with a filesystem permission error, rerun it with escalated permissions.
- If
--list-targetsprints no directories, report that clearly instead of guessing a target. - If the user names a path directly, validate that it is absolute and exists before running the sync.
- Treat repo-root
.sync-targetas the cache for the chosen runtime home. - Remember that gitignored files under
wezterm-x/local/are still copied because sync reads the repository working tree, not just tracked files. - Sync also copies
config/worktree-task.envto<runtime_dir>/repo-worktree-task.envso the Windows-side wezterm.exe can read it (io.openon a/home/...WSL path returns nil from Windows).wezterm-x/lua/constants.luareads that local copy first; without it, the<base>_resumeprofile defined only in the env file is missing on the Windows leg and workspace open silently falls back to the bare profile. - Sync runs
scripts/runtime/render-workspace-agent-map.sh(requireslua5.4) to regeneratewezterm-x/local/workspace-agent-map.tsvfrom workspaces.lua so shell launch paths honor per-itemlauncheroverrides. Seedocs/workspaces.md#per-repo-agent-cli. - The
lua-precheckstep (betweenpublish-runtimeandhelper-install) dofile-loads the syncedlua/constants.luaunder a mockedweztermand assertsdefault_resume_profile ≠ default_profileplus a--continue/resumeliteral in the resume command. Requireslua5.4(orlua5.3/lua); skips with a warning when none is installed. check-runtime.shis the read-only aggregate entry point. Keep individual checks inscripts/dev/so they remain directly testable; add new environment checks to this orchestrator and document whether they are advisory or publishing gates.sync-runtime.shkeeps only the checks needed at the publish boundary inline (Lua/source validity, helper state, hooks, Node warning, shell-env warning, canary, and reload). Do not add another standalone environment check there without also wiring it intocheck-runtime.sh.
Commands
Sync using the cached target:
skills/wezdeck-runtime-ops/scripts/sync-runtime.shList candidate homes:
skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --list-targetsSync to a confirmed target:
skills/wezdeck-runtime-ops/scripts/sync-runtime.sh --target-home /absolute/pathPrompt-format regression test:
skills/wezdeck-runtime-ops/scripts/test-sync-prompt.sh tty en
skills/wezdeck-runtime-ops/scripts/test-sync-prompt.sh non-tty zhEnvironment and dependency check:
skills/wezdeck-runtime-ops/scripts/check-runtime.sh
skills/wezdeck-runtime-ops/scripts/check-runtime.sh --advisory --skip-depsDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

