browser-discoverability

name	browser-discoverability
description	Keep browser automation discovery compact by extending existing semantic UI automation guidance
domain	prompt-design
confidence	high
source	earned

Context

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.

Patterns

Reuse the default semantic workflow

Add a short browser note to the main quickstart or primary guidance surface instead of building a parallel browser-only story.

Add one focused browser prompt

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.

Keep tool descriptions example-driven

Prefer tiny examples in app, ui_find, and ui_click over long prose. Mention msedge.exe or chrome.exe, visible text, and ARIA labels.

Keep docs thin

Use one short README note and one compact reference section when documentation is needed. Avoid repeating the same browser guidance across every doc surface.

Examples

• WindowsAutomationPrompts.Quickstart() gets one browser sentence.
• WindowsAutomationPrompts.BrowserAutomation() handles URL launch, ARIA discovery, and keyboard fallback for browser chrome.
• Tool descriptions mention msedge.exe launch and ARIA-backed name matching.

Anti-Patterns

• Duplicating full browser workflows across many prompts, resources, and docs.
• Introducing Playwright/Selenium/CDP language when the product direction is semantic UI Automation first.
• Explaining browser chrome and page-content automation as separate systems when they are mostly the same workflow plus a few shortcuts.