vs-ui-explore

vs-ui-explore

Drive a running, debugged desktop application from Visual Studio through its UI using the vs-mcp UI Automation tools. The goal is to visit every reachable screen/dialog, exercise interactive elements, and collect a structured report of crashes, unhandled dialogs, UIA binding errors, disabled-but-expected states, and unreachable features.

This skill is the Windows/VS analogue of iOS ios-simulator-skill. It expects the target application to already be running under the VS debugger before the crawl starts.

When to use this skill

Trigger when the user says things like:

• "Test all the screens of this app"
• "Crawl the UI and tell me what's broken"
• "Run through every dialog and report issues"
• "Find UI bugs autonomously"

Do not trigger for single, targeted UI actions ("click Save", "open the Settings dialog") — use the individual ui_* tools directly for those.

Prerequisites

Before starting a crawl, confirm via get_status:

1. A solution is open in Visual Studio.
2. debugMode is Run (the target is being debugged). If it is Design, ask the user whether to start debugging first via debug_start or debug_start_without_debugging; do not start it silently because the user may want to target a specific configuration.
3. The debuggee has a visible main window (ui_capture_window must not error with "no debugged process").

If any of the above fails, stop and ask the user how to proceed instead of guessing.

Crawl loop

For each iteration the agent should:

1. Observe. Call ui_snapshot with depth: 8, includeScreenshot: true. The compact tree returned already prunes offscreen/boring containers and annotates each node with its role, id, name, actions, and state.
2. Fingerprint the screen. Build a signature from window.title + focused.role + focused.automationId + top-level child roles. Skip screens you have already explored (track signatures in memory for the duration of the crawl).
3. Catalogue interactive targets. From the tree, collect every node whose actions array contains invoke, toggle, select, or expand. Prefer elements with meaningful name or id; de-prioritize anonymous Custom controls unless nothing else is available.
4. Decide the next action. Pick one interactive target that has not been exercised yet on this screen. Prefer:
   • Buttons whose name suggests navigation ("Next", "Open", menu items, tabs) over destructive verbs ("Delete", "Remove", "Uninstall").
   • Toggles and selects last, since they rarely reveal new screens.
5. Act. Use ui_invoke (preferred when an AutomationId exists) or ui_click (by name if no id). Never fall back to raw coordinates.
6. Settle. Immediately call ui_wait_idle with quietMs: 600, timeoutMs: 4000 so any async UI updates finish before the next observation.
7. Verify. Call ui_snapshot again. If the focused window title changed or a new dialog appeared, treat it as a new screen and recurse. If nothing changed after a non-trivial action, record that as a suspicious result.
8. Escape dialogs. If a modal dialog appears that you did not intend (error, confirmation, progress), record it, close it via the most benign option (Cancel, Close, No), and continue. Never click Delete, Uninstall, Reset, or similar destructive defaults. If the only option is destructive, stop and ask the user.