BrowserOS Skill exhibits significant definition quality gaps. Tool names lack action verbs (tabs, snapshot, read, run, observe are generic or incomplete). Descriptions are present but minimal (10-50 chars), below the 50-200 char LLM-optimized baseline. Input schemas are visible but lack depth: parameter descriptions are terse, no enums for constrained inputs, no output schemas documented. The 'run' tool accepts arbitrary JavaScript code with no validation guidance or security warnings. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear READ/WRITE distinctions. Composition is weak: 'run' duplicates functionality of other tools and accepts unbounded code input.

• Rename tools with action verbs: 'manage_tabs' (or split into 'create_tab', 'list_tabs', 'close_tab'), 'capture_snapshot', 'extract_content', 'execute_code', 'observe_page_state'.
• Expand descriptions to 50-200 chars. Example: 'Manage browser tabs: create new tabs with a URL, list all open tabs with their IDs and titles, or close a specific tab by ID. Returns tab list with page IDs for use with snapshot/read tools.'
• Document output schemas for each tool. E.g., tabs list action returns [{page_id: int, url: string, title: string}]. Snapshot returns {text: string, length: int}.
• Add tool annotations: mark 'snapshot', 'read', 'observe' with readOnlyHint=true; mark 'tabs' (close action) and 'run' with destructiveHint=true; mark 'tabs' (new/list) with idempotentHint=true.
• Restrict 'run' tool: document allowed SDK APIs, add code length limits, require explicit opt-in for destructive operations, and provide error recovery guidance (e.g., 'Execution failed: <error>. Check SDK docs at <url>.').