web-research-cascadelisted

This skill exists because the built-in WebFetch returns a 403 or an empty/CAPTCHA body on many primary sources, and the agent then quietly falls back to a weaker secondary source. The result: your analysis rests on blogs that write *about* the source instead of the source itself. The cascade prevents exactly that. ## Search vs. fetch **Search** (which sources exist on topic X?): use your built-in web search as the default. **Fetch** (read one known URL): the cascade below. Do not confuse the two. ## Work order: sources first, then transport Step 0, before any fetching: decide which sources would genuinely best answer the question (the primary document, the official docs, the original announcement), not whichever page is easiest to fetch. Source quality beats fetch convenience. Then get exactly those sources: if one of them blocks, open it via the cascade instead of swapping it for a weaker error-free source just because that one did not throw a 403. A 403 is a transport problem, not a reason to drop the source. Only when every stage fails may a source count as "unreachable", and then you say so explicitly instead of papering over it. ## Sources with their own route (check BEFORE the cascade) Reddit and X block the public stages (Jina) wholesale because they demand a logged-in/OAuth session and reject datacenter IPs. The generic cascade is not worth it for them; they have a shorter, cleaner path. Check this branch FIRST before running a `reddit.com` or `x.com` URL throug