wsl-env

# wsl-env - WSL to Windows-side helper When the agent runs inside WSL, the thing it needs to reach or drive often lives on the Windows side. WSL frequently cannot reach Windows `localhost` ports directly, so a naive `curl localhost:PORT` failing is NOT evidence that a service is down. This skill defines how to detect that situation and how to act across the WSL/Windows boundary correctly. ## Self-detect first (no-op when irrelevant) Before doing anything WSL-specific, check whether it applies: - Is this actually WSL? Check for the WSL kernel signature, e.g. `grep -qi microsoft /proc/version` (or check `/proc/sys/kernel/osrelease`). If not WSL, this skill is a no-op - use normal local access. - Is the target Windows-side? A service bound by a Windows process, a Windows `.ps1` launcher, a Windows path, or a machine-level action (hibernate). If the target is a native Linux service inside the WSL distro, this skill is a no-op - reach it the normal Linux way. Only when both are true do the rules below apply. ## Reaching a service: try BOTH methods before giving up A service reachability failure from WSL has two distinct fixes depending on how the service is bound. Never conclude "unreachable" without trying both. 1. Service bound to `0.0.0.0` (all interfaces): reachable from WSL via the Windows LAN-IP, NOT via `localhost`/`127.0.0.1`. Point the request at the host's real LAN address plus the port. 2. True localhost-only service (bound to `127.0.0.1` on Wind...