// Keep browser automation discovery compact by extending existing semantic UI automation guidance
Guidance for semantic-first Windows automation with the bundled windows-mcp server. Use when automating desktop apps, choosing UI Automation vs screenshots, or handling DPI and multi-monitor issues.
Pattern for always-on Chromium browser smoke coverage using a deterministic local Edge page plus a stable public-web slice
How to test prompt guidance for usefulness without letting prompt size or claims sprawl
| name | browser-discoverability |
| description | Keep browser automation discovery compact by extending existing semantic UI automation guidance |
| domain | prompt-design |
| confidence | high |
| source | earned |
Use this when browser support already exists in the backend and the goal is to help users or LLMs discover it without adding a separate automation model.
Add a short browser note to the main quickstart or primary guidance surface instead of building a parallel browser-only story.
Create a single prompt that covers the browser-specific gaps: launching with a URL, using ARIA labels as names, and using shortcuts for browser chrome like the address bar or tab switching.
Prefer tiny examples in app, ui_find, and ui_click over long prose. Mention msedge.exe or chrome.exe, visible text, and ARIA labels.
Use one short README note and one compact reference section when documentation is needed. Avoid repeating the same browser guidance across every doc surface.
WindowsAutomationPrompts.Quickstart() gets one browser sentence.WindowsAutomationPrompts.BrowserAutomation() handles URL launch, ARIA discovery, and keyboard fallback for browser chrome.msedge.exe launch and ARIA-backed name matching.