web-research

Скилл задает дисциплину поиска в интернете. Дефолтное поведение модели - дернуть WebSearch один раз, прочитать сниппеты и ответить - дает поверхностный и часто устаревший/галлюцинированный результат. Здесь поиск превращается в проверяемый процесс: несколько переформулированных запросов, чтение страниц целиком, перекрестная сверка фактов между источниками, явная пометка неуверенного и устаревшего, обязательные цитаты.

Ценность не в количестве ссылок, а в том, что каждое утверждение в ответе привязано к источнику и пережило попытку его опровергнуть.

Когда применять

• Нужен фактический ответ из веба, который мог измениться после обучения модели: версии, цены, релизы, статус проекта, события, "что сейчас с X".
• Сравнение вариантов (инструменты, библиотеки, подходы) с опорой на актуальные данные.
• Проверка конкретного утверждения ("правда ли, что Y") - найти подтверждающие и опровергающие источники.
• Открытый research по теме, где нужен синтез из нескольких источников.

Когда НЕ применять

• Один быстрый факт с известным URL или из одной страницы - прямой WebFetch/WebSearch без обвязки.
• Вопрос уверенно отвечается из знаний модели и свежесть не важна (определения, устоявшаяся теория, синтаксис языка) - не ходить в веб ради проформы.
• Запрос про код/файлы текущего репозитория - это searcher/explorer, не веб.

Жесткие правила

1. Минимум два независимых источника на ключевое утверждение. Один источник = гипотеза, не факт. Если второго нет - так и пометить ("по единственному источнику").
2. Читать страницы, а не сниппеты. По релевантным результатам поиска делать WebFetch и опираться на полный текст. Сниппет выдачи - повод открыть страницу, а не готовый факт.
3. Каждый факт - с источником. В заметке у утверждения стоит ссылка (URL) и дата доступа. Без источника утверждение в ответ не идет.
4. Свежесть явно. Для меняющихся данных (цены, версии, статусы) указывать дату публикации источника и помечать риск устаревания. Сегодняшнюю дату брать из контекста сессии.
5. Противоречия не сглаживать. Если источники расходятся - показать расхождение и какой источник почему весомее (первоисточник > агрегатор > форум), а не выбирать удобный молча.
6. Не выдавать знания модели за результат поиска. Если факт не подтвержден найденной страницей - он либо помечен как догадка, либо не включается.

Процесс

1. Декомпозиция. Разбить вопрос на 2-5 под-вопросов / поисковых линий. Для каждого - сформулировать несколько вариантов запроса (синонимы, разные формулировки, англ. + рус.).
2. Fan-out поиска. Под-вопросы раздать субагентам в одном ответе (параллельно). Тип - Explore или general-purpose на дешевой модели (механический сбор, не суждение). Бриф каждому: под-вопрос, требование делать WebSearch несколькими формулировками + WebFetch релевантных страниц, вернуть только факты с URL и датой публикации/доступа, без воды. См. subagents-usage.
3. Сбор и дедуп. Свести находки, убрать дубли, сгруппировать по под-вопросам. Отметить, где источник один, где несколько, где расхождение.
4. Состязательная верификация ключевых утверждений. Для каждого утверждения, на котором держится ответ, - отдельный проход (можно субагентом), который пытается его опровергнуть: ищет противоречащий источник, более свежие данные, первоисточник вместо пересказа. Утверждение, не пережившее проверку, - вниз в "неуверенно" или вон.
5. Синтез. Собрать ответ/заметку: вывод сверху, под ним факты с цитатами, отдельным блоком - неуверенное/противоречивое/устаревшее. Для wiki-проектов оформлять по wiki-notes-style (заметка с источниками и перелинковкой).

Формат ответа

• Вывод - 2-5 строк прямого ответа на исходный вопрос.
• Обоснование - тезисы, у каждого инлайн-ссылка на источник. Меняющиеся данные - с датой.
• Неуверенно / противоречиво - отдельный блок: что не подтвердилось двумя источниками, где источники разошлись, что может устареть.
• Источники - список URL с краткой пометкой (первоисточник / агрегатор / дата).

Глубину масштабировать под запрос: быстрая проверка факта - 1-2 под-вопроса без отдельной фазы верификации; "разберись детально" / "сравни все" - полный fan-out + состязательный проход + блок противоречий.

Ограничения

• Веб-данные бывают платными/за paywall, региональными, A/B - WebFetch может вернуть не то, что видит человек. Если ключевая страница недоступна - пометить, не домысливать.
• Состязательная верификация снижает, но не убирает риск ошибки: согласованность двух агрегаторов, переписавших один пресс-релиз, - не независимое подтверждение. Где можно - доходить до первоисточника.
• Скилл не заменяет review / второе мнение по коду - он про факты из веба, не про корректность решения.

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.