← ClaudeAtlas

windows_vm_guilisted

Drive the Windows Test VM's GUI — Windows-MCP in the guest, UIA-tree clicking by element ID (never blind coordinates), screenshot verification between actions, and mouse-free in-process test paths for anything repeatable. Exploratory GUI QAQC where windows_devkit's exec loop can't see the UI.
jedbjorn/subfloor · ★ 14 · AI & Automation · score 76
Install: claude install-skill jedbjorn/subfloor
# windows_vm_gui — GUI-driving the Windows Test VM Drive the guest GUI via **Windows UI Automation**: pull the UIA tree, act on elements by ID. NEVER click by screenshot pixel coordinates when an element ID exists — pixel targets break on DPI scaling / window position / theme / dense UIs (a CAD ribbon, a settings tree). Tooling = **Windows-MCP** (`windows-mcp` on PyPI), running inside the guest, reached over HTTP. Tools: `Snapshot` (UIA tree + element IDs), `Click`/`Type`/`Scroll` (act on IDs), `Screenshot` (visual verify), plus `App`, `PowerShell`, `Clipboard`. Expect 0.2–0.5 s per action. ## Where this sits | Skill | Loop | Use for | |---|---|---| | `windows_devkit` | push → exec → capture → reset | installers, services, anything scriptable | | **this** | connect → Snapshot → click/type → verify | exploratory GUI QAQC, visual verification | | `configure_winbox` | provision → verify → bake | the admin prep both of the above assume | GUI driving = exploratory QAQC + visual verification ONLY. A check that will run more than twice does not belong in a click sequence — see the last section. ## One-time guest prep (admin — via the configure_winbox flow) Every `windows_devkit` run reverts to the `clean` snapshot → anything installed but not baked evaporates on the next reset. Windows-MCP is therefore **toolchain**: a missing piece = manifest PR + re-bake, NEVER an ad-hoc install from a test loop. 1. Add Python 3.13+ (e.g. `Python.Python.3.13`) to the fork's committed winge