Agent should check for native site features before building browser-automation workarounds

Summary

A long Claude Code session building a Chrome extension (browser automation / DOM scraping across Gemini, ChatGPT, and Claude.ai) spent the large majority of its cost building and iteratively debugging Claude-specific chat-deletion automation — before discovering that Claude.ai already has this exact feature built in natively. All of that work was then reverted as unnecessary.

What happened

• Asked Claude Code to build a browser extension adding multi-select bulk-delete to the chat sidebars of Gemini, ChatGPT, and Claude.ai.
• Across many rounds of live DOM inspection, selector fixes, and reload-and-test cycles (screenshot- and JS-exec-heavy), the agent built and hardened Claude-specific automation: checkbox injection into two different DOM structures (a sidebar list and a separate table view), timing/race-condition fixes, and confirmation-dialog handling.
• Only after I asked "why do we need this if Claude already has bulk select" did the agent check and confirm Claude.ai's own "Select" mode (on its "Chats and tasks" page) already provides this exact capability, with a native single-confirm batch delete.
• All Claude-specific code was then removed as dead weight.
• Similar automation was still being debugged for Gemini/ChatGPT at the point the session was abandoned due to cost, with mixed reliability.

Suggested improvement

Before writing site-specific browser automation to add a feature to a third-party web app, the agent should do a quick manual check of the target site's own UI for an existing native equivalent — a couple of minutes of reconnaissance that would have avoided a large fraction of this session's cost. This seems like a generally useful default for this class of task ("add feature X to site Y via extension/automation"), not something that should require the user to think to ask for it.

Context

Claude Max plan subscription via Claude Code CLI. The session also illustrated how expensive iterative browser-automation debugging against undocumented third-party site internals (different frontend frameworks per site) can get — many screenshot/JS-exec round trips were needed per site just to find working selectors. A rough cost/scope heads-up before starting this class of task would also be valuable.