Trend Research
Каркас процесса — как в скилле Deep-web-search, поверх него правила «Аве Марии»: источники, сигналы, оформление трендов.
7 шагов: получить задачу → SPICE-уточнение → сужение областей (approve) → план ключей и источников (approve) → параллельный поиск и сбор сигналов (50+ запросов, агенты по вариантам поиска) → отсев сигналов по тирам → синтез трендов + QA-аудит в фоне.
References (читать по ходу)
- references/sources.md — каталог источников и как в каждом искать. Читать в Phase 3 при назначении источников.
- references/trend-rules.md — мета-правила, сужение задачи, тиры сигналов, структура тренда, проверка источников. Читать в Phase 2 и Phase 5–6.
- references/slice-method.md — типы слайсов для генерации запросов. Читать в Phase 3.
- references/html-report-example.html — эталон HTML-одностраничника по трендам (аналитическая шапка-саммари → «Отбор сигналов» с тирами → карта трендов → список трендов с описанием, «преломлением» и каруселью сигналов; теги сила/охват/горизонт; шрифт ONY One; редакционный тон). Использовать как структурный шаблон в Phase 7, если заказчик попросил HTML.
Gotchas
- Solid keywords верифицирует человек. Не запускать поиск по своим ключам без подтверждения: показать список ключей (русские и английские, если нужно) и дать выбрать. Это мета-правило «Аве Марии».
- Примеры в срезах — иллюстрации, не границы поиска. Примеры внутри срезов агент придумывает сам — это гипотезы, а не факты о рынке. Ключи и запросы строить от формулировки среза целиком, а не от перечисленных примеров, иначе поиск замкнётся на самопридуманных кейсах и пропустит всё, чего в примерах не было. Задача поиска — найти в том числе то, что мы не смогли предугадать.
- Не парсить всё подряд. Нейросеть склонна усердно сканировать то, что человек сканировать бы не стал. Каждый запуск парсера/крауля должен отвечать на конкретный вопрос плана.
- Всплеск ≠ понимание. После найденной интересной динамики делать доп-запрос на прояснение причины (например, «why sardines are hyping»).
- Сигналы старше 3 лет — отсев (Tier 4). Ставить фильтры по дате в инструментах поиска.
- Каждый сигнал несёт ссылку на первоисточник — везде. В сборе, дедупликации, тировании и бэклоге НЕ отбрасывать URL, оставляя одно название. Фактология без рабочей ссылки = сгенерированный текст.
- Бэклог — таблица по тирам, колонки Название | Описание | Обоснование | Источник. Описание — полноценная фраза с цифрами, не обрезок. Никакой колонки «Тренд».
- Бэклог сигналов пишется ДО трендов — не проставлять в нём номера трендов. Тренды синтезируются ИЗ сигналов (Phase 6), а не наоборот. Пред-привязка сигнала к тренду = натягивание. Порядок строго: сигналы → тиры → тренды.
- Reddit бесполезен для российских ниш — pikabu.ru, dzen.ru, otzovik.com, irecommend.ru. Не ставить
userLocation: US для российских тем. (Правила из QA-аудитов Deep-web-search.)
- В чат сигналы НЕ вываливать. Полные списки сигналов, бэклог, тексты трендов и QA-отчёт живут в файлах, а НЕ в переписке — это жжёт токены. Не пересказывать в чат находки каждого вернувшегося агента. В чат — только короткий финальный отчёт (см. Phase 6.4).
- В трендах и бэклоге рендер сигнала одинаковый: жирное название-действие → суть с цифрами →
— источник: [издание](URL) + дата. Актор (Delta, Магнит) — в названии, НЕ в позиции источника. В бэклоге то же самое, разложенное по колонкам Название | Описание | Обоснование | Источник.
Phase 0: Получить задачу
Если $ARGUMENTS непуст — это категория/рынок, сразу в Phase 1.
Если пуст — спросить: «В какой категории/рынке ищем тренды и для какой задачи заказчика?» STOP и ждать ответа.
Phase 1: SPICE-уточнение
Задать 6 вопросов и ждать ответов (как в Deep-web-search Phase 1):
- Рамки (S): география (РФ / мир / рынок-бенчмарк) и временной горизонт трендов?
- Перспектива (P): чьё поведение изучаем, для какой аудитории результат?
- Объект (I): тренды чего именно — категория, продукт, маркетинг, бизнес-модели?
- Сравнение (C): есть ли бенчмарк (другая страна, соседняя категория)?
- Критерий успеха (E): что нужно на выходе — карта трендов, топ-N трендов, сигналы для стратегии? Какое решение примут по результатам?
- Уже знаете: какие тренды/отчёты уже видели, что НЕ нужно искать?
Phase 2: Сужение областей
По правилу «Как сузить задачу» из references/trend-rules.md:
- Зафиксировать объекты поиска.
- Перечислить ВСЕ возможные срезы (продукт, маркетинг, сервис, бизнес-модели, процессы; гео; ширина категории) и предположить фокусные. Примеры внутри среза давать с пометкой «например» и не больше 1–2 на срез — они только поясняют срез, поиск ими не ограничивается.
- STOP: показать список срезов с пометкой «изучаем / не изучаем» и ждать подтверждения заказчика.
Phase 3: План ключей и источников
3.1 Два типа ключей — не смешивать
A. Solid-ключи (короткие). Ровно 2–3 на русском и 2–3 на английском (если гео позволяет), уровня категории («fish food», «морепродукты тренды»). Назначение ТОЛЬКО одно: прицельный поиск там, где длинные запросы не работают — соцсети (YouTube, Pinterest), Telegram по MCP, парсеры, дописывание к имени источника. Базой для остальных изысканий они НЕ являются — не растягивать список до 10+.
B. Слайс-запросы (длинные). Основной массив запросов для поиска «без подсказки» — по правилам references/slice-method.md. Ограничений на количество запросов НЕТ — их должно хватить, чтобы покрыть каждый подтверждённый срез и широкими, и точечными запросами на всех релевантных языках. На полноценный тренд-рисёрч это обычно 50+ запросов суммарно по всем вариантам поиска; план из ~25 запросов — несерьёзный, расширить. Порядок на каждый срез:
- Сначала широкие категорийные запросы от формулировки среза — они дискаверят то, чего мы не предугадали.
- Потом точечные по конкретным гипотезам (в т.ч. по примерам из Phase 2) — как дополнение, не основа.
- Срез, покрытый только точечными запросами по примерам, — невалиден.
3.2 Распределение по вариантам поиска
Прочитать references/sources.md (раздел «Порядок поиска») и распределить:
| Вариант |
Какие ключи |
Что делать |
Инструменты |
| С подсказкой источника |
Solid-ключи (A) |
К solid-ключу дописывается имя источника из каталога («fish food Statista», «seafood trends McKinsey», «... Trendhunter») или site:/include_domains — см. пометки «Как искать» в каталоге. Пройти каталог ШИРОКО: разделы «Тренды», «Готовые исследования» + все профильные под тему. Запросов здесь может быть много — не ограничиваться 5–7, каждому потенциально релевантному источнику свой запрос |
tavily_search, Exa |
| Без подсказки |
Слайс-запросы (B) |
Общий поиск по всему массиву слайс-запросов |
Exa, Tavily, WebSearch |
| Telegram: каналы из списка |
Solid-ключи (A) |
Всегда не больше 2 ключей. Искать в релевантных каналах из TGStat-списка |
telegram-mcp |
| Telegram: все подписки |
Расширенный ключ |
Только при малом улове в каналах. Запрос конкретизировать («тренды рынка морепродуктов», НЕ «рыба») — однословный категорийный ключ зацепит кучу нерелевантных чатов и даст мусор |
telegram-mcp |
| Отраслевая пресса |
Solid + слайсы |
Отдельный агент собирает релевантные отраслевые издания (веб + соцсети), затем поиск по ним |
subagent + tavily/Exa |
Парсеры и сервисы «поиск внутри» — на уровне категории, не отдельных продуктов. Точечные продуктовые ключи в парсеры — только вторым заходом, чтобы прояснить конкретный всплеск:
| Инструмент |
Какие ключи |
Как |
vibecode_projects/gtrends-parser |
Solid-ключи категории; динамика + RISING-запросы (Tier 2) |
./run.sh "fish food,seafood" --geo US |
vibecode_projects/yt-parser |
Категория в целом («fish food»), не продукт |
./yt-parser.sh search "fish food" 30 year |
| Яндекс Wordstat, Pinterest Trends, Glimpse |
Solid-ключи |
руками или WebSearch по выдаче, см. sources.md «Тренды» |
Выбор инструмента по кейсам и fallback-правила — как в Deep-web-search (Phase 2.3): полная таблица кейсов в .claude/skills/Deep-web-search/SKILL.md, накопленные правила в .claude/skills/Deep-web-search/references/operational-rules.md.
3.3 Approve
STOP: показать план и ждать подтверждения:
## План поиска трендов: [тема]
**Срезы:** [подтверждённые] | **Запросов:** [N]
### Solid-ключи на верификацию (для соцсетей, Telegram, парсеров, подсказок источника)
RU (2–3): [ключ1, ключ2]
EN (2–3): [key1, key2]
### Слайс-запросы (поиск без подсказки)
| # | Срез | Слайс | Запрос | Инструмент |
|---|------|-------|--------|------------|
### С подсказкой источника (solid-ключ + источник)
| # | Запрос | Источник | Инструмент |
|---|--------|----------|------------|
### Telegram / пресса / парсеры
[каналы + max 2 ключа; расширенный ключ для всех подписок; категорийные ключи парсеров]
Подтверди ключи и план, поправь или дополни.
Phase 4: Параллельный поиск и сбор сигналов
Агентов распределять по вариантам поиска, а не слепо по числу запросов: отдельный агент (или несколько) на каждый вариант — Telegram, отраслевая пресса, с подсказкой источника, без подсказки. Внутри варианта смотреть на объём: до ~15 запросов — один агент, больше — поделить между двумя-тремя (например: Telegram 10 запросов → 1 агент; с подсказкой 30 → 2 агента). Так каждый агент работает одним инструментом и одной логикой поиска, а не скачет между Telegram и Exa. Всех запускать параллельно. Пока агенты работают и по мере их возврата — НЕ пересказывать их находки в чат (в чате достаточно «агенты запущены» / «все вернулись»): дождаться всех, свести сигналы в файлы, и выдать один короткий отчёт по Phase 6.4. Шаблон промпта, tool usage rules, fallback-правила и per-query attribution — из Deep-web-search Phase 3. Дополнения к промпту каждого агента:
- Собирать сигналы по ходу. Часть находок — не источники, а сигналы (проекты, новые компании, продукты, запуски, нашумевшие новости). Каждый оформлять сразу по формату: Название сигнала (что произошло — решение/действие) + суть с цифрами +
— источник: [издание](URL) + дата. ВАЖНО: компания/актор внутри названия (напр. «Delta», «Магнит») — это НЕ источник. Источник — издание/отчёт/канал, откуда взят факт, и он ВСЕГДА идёт в конце после — источник: (если фактов из двух изданий — — источники:). Название должно быть самодостаточным и содержательным (полная мысль с цифрой), а не обрезком.
- Логировать провенанс каждого сигнала. У каждого сигнала фиксировать, от какого запроса (№) и из какого источника (издание/канал/отчёт) он получен — чтобы в конце свести, что реально приносит сигналы. Без этого QA не сможет оценить полезность источников.
- Прояснять всплески. Нашёл интересную динамику → доп-запрос на причину («why X is hyping»).
- Фильтр по дате: сигналы старше 3 лет не собирать (
startPublishedDate, --dateafter).
- Возвращать: per-query breakdown (как в Deep-web-search) + отдельный блок «Сигналы» (каждый с пометкой запрос № / источник).
Если после первого раунда сигналов мало (искали в основном отчёты) — запустить дополнительный раунд поиска сигналов с фокусом на отраслевые СМИ и глобальный поиск (правило 2 из «Как выбирать сигналы»).
Phase 5: Отсев сигналов по тирам
По разделу «Как выбирать сигналы для тренда» из references/trend-rules.md:
- Свести все сигналы от агентов, дедуплицировать.
- Каждому сигналу присвоить Tier 1–4 с одной строкой обоснования.
- Tier 4 (старше 3 лет) — отсев; Tier 3 — оставить с низким приоритетом.
- Сохранить бэклог-файл: какие сигналы пошли в работу, какие отсеяны и почему.
Формат бэклога — таблица по тирам, 4 колонки: Название | Описание | Обоснование | Источник. Отдельная таблица под каждый тир (Tier 1 → Tier 4), плюс таблицы «Контр-сигналы» и «Кластеры». Колонки:
- Название — сигнал как решение/действие (напр. «Магнит удваивает продажи готовых блюд из рыбы»); РФ-сигналы помечать
[RU].
- Описание — что именно произошло, с цифрами. Полноценная фраза, не обрезок.
- Обоснование — одна строка, почему этот тир.
- Источник — рабочая ссылка
[Название](URL) + дата (безссылочные Telegram — [Канал, дата](t.me/...)). Ссылка обязательна у КАЖДОГО (правило «нет ссылок → текст сгенерирован»); URL при дедупликации/тировании не отбрасывать.
| Название | Описание | Обоснование | Источник |
|----------|----------|-------------|----------|
| Магнит ×2 RTE-рыбы [RU] | Сеть удваивает продажи готовых блюд из рыбы в 2026 | Крупный ритейлер ставит деньги на формат | [Магнит, 2026-03](URL) |
Содержание каждой строки = канонический сигнал из trend-rules.md (Название решения/действия + суть + источник), просто разложенный по колонкам.
НЕ проставлять в бэклоге номера или названия трендов. Тренды на этом этапе ещё не построены — они рождаются ИЗ сигналов в Phase 6. Привязка сигнала к тренду в бэклоге = обратная логика (натягивание сигналов под заранее решённые тренды). Правильный порядок строго: сигналы → тиры → (потом) синтез трендов. Максимум допустимого в бэклоге — группировка похожих сигналов в кластеры по смыслу (без присвоения им финального номера тренда) как мостик к Phase 6.
Phase 6: Синтез трендов + сохранение
6.1 Синтез
По разделу «Как оформлять тренд»: сгруппировать похожие по смыслу сигналы в системные тренды по принципу движущей силы (фундаментальное изменение в предпочтениях и поведении потребителей). Каждый тренд описать по структуре:
- Название
- Описание (что изменилось vs как было раньше)
- Преломление тренда — влияние на продукт/маркетинг под задачу заказчика
- Список сигналов с описанием и ссылками
- Сила тренда 1–10
- Глобальность (локальный–глобальный)
- Долгосрочность (краткосрочный–долгосрочный)
Перед выдачей — проверка источников по чеклисту «Как проверять источники» (актуальность, первоисточник, авторитетность, предвзятость).
6.2 Сохранение (MANDATORY)
Все файлы — в CLOUD ZB (3600)/Researches/<slug>/ (новые файлы, ничего не перезаписывать):
<slug>-trends-YYYY-MM-DD.md — тренды с сигналами и оценками (+ мета: дата, назначение, описание)<slug>-signals-backlog-YYYY-MM-DD.md — бэклог сигналов: в работе / отсеяны с причинами и тирами. Каждая строка сигнала несёт ссылку на первоисточник (колонка с URL в таблице либо инлайн [источник](URL)) — фактология без ссылок недопустима.
6.3 QA-аудит (фоном)
Параллельно с синтезом запустить фоновый QA-агент по формату Deep-web-search Phase 3.5 (оценка ключей, инструментов, извлечения). Полный отчёт в чат НЕ печатать — дописать в накопительный файл CLOUD ZB (3600)/Researches/trend-research-qa-log/trend-research-qa-log.md (создать папку и файл при первом запуске; шапка и формат — как в search-quality-log.md, но это отдельный лог только для тренд-рисёрчей). В чат идёт только 2–3 строки QA-резюме внутри финального отчёта (см. Phase 6.4).
Дополнительно — полезность по сигналам (главное для этого скилла). Кроме оценки выдачи, QA-агент сводит провенанс сигналов (запрос № / источник из Phase 4) и отдельным блоком проговаривает:
- Топ запросов по сигналам — какие запросы принесли больше всего сигналов и сколько из них дошло до Tier 1–2 (а не просто «дали выдачу»).
- Топ источников по сигналам — какие издания / каналы / отчёты оказались «жилами» (много сигналов), а какие — пустышки (0 сигналов при наличии выдачи).
- Вывод для каталога — какие источники стоит добавить/поднять в
sources.md, какие — понизить.
Таблицы:
### Полезность запросов (по сигналам)
| Запрос | Сигналов | из них Tier 1–2 | Вердикт |
### Полезность источников (по сигналам)
| Источник | Сигналов | из них Tier 1–2 | Тип (жила/россыпь/пусто) |
Метрика — выжившие сигналы, НЕ количество результатов поиска: источник с 10 результатами и 0 сигналов Tier 1–2 = пустышка.
Phase 6.4: Вывод в чат (MANDATORY)
Сигналы, бэклог и полный QA — только в файлах. В чат — короткий финальный отчёт, и всё. Не дублировать в переписке списки сигналов и тексты трендов (это жжёт токены). Формат отчёта в чат:
- Список ключевых трендов — только названия (можно с оценкой силы), 1 строка на тренд. Без описаний и сигналов.
- Сколько сигналов на тренд — числом рядом с каждым трендом (или сводкой «N сигналов на M трендов, из них Tier 1–2 — K»).
- QA-резюме — 2–3 строки: главные жилы, главные пустышки, 1 вывод для каталога. Полный QA — в
trend-research-qa-log/.
- Пути к файлам — где лежат тренды, бэклог, QA.
Всё, что подробнее этого, пользователь открывает в файлах сам. Если он попросит раскрыть конкретный тренд — тогда и раскрывать, точечно.
Phase 7: Предложить HTML-оформление
После короткого отчёта в чат (Phase 6.4) спросить заказчика: «Оформить тренды в HTML-одностраничник?» и STOP. Не собирать HTML без подтверждения — многим достаточно md.
Если да — собрать одностраничник по эталону references/html-report-example.html (прочитать его как структурный шаблон):
- Структура: аналитическая шапка-саммари (тема, задача, что нашли, каналы поиска, оценка трендов) → раздел «Отбор сигналов» с легендой тиров Tier 1–4 → карта трендов (оглавление с мини-метром силы) → список трендов, у каждого: заголовок, теги (сила метром + N/10, охват, горизонт,
РФ где есть), полное Описание, врезка «Преломление под задачу», карусель сигналов (Tier-чип + название-действие + суть + источник: [издание](URL), кнопки ‹ ›, свайп/drag).
- Тон: редакционный, читабельный, без продающих слоганов и без «трёх опор»/финального «продающего» блока (это аналитический отчёт, а не презентация-продажа). Данные (тренды, описания, сигналы, оценки) брать из уже сохранённых md-файлов Phase 6.2, не переписывать заново.
- Шрифт ONY One — 6 начертаний в
CLOUD ZB (3600)/Signal, Ony/fonts-ony/ONYOne-{Thin,Light,Regular,Medium,Bold,Black}.otf. Копировать в Researches/<slug>/onepager/fonts/ и подключать через @font-face относительным путём.
- Куда:
Researches/<slug>/onepager/index.html (+ fonts/). Проверить рендер через headless-Chrome (скриншот), затем дать путь в чат.
- Деплой лендингом (если попросят «выложить на сайт») — статикой в
public/<slug>/ Next-сайта + rewrites для чистого URL; коммитить только свои файлы.
1---2name: trend-research3description: Поиск и оформление трендов по методике «Аве Мария»: SPICE-уточнение, сужение областей, верификация ключей человеком, поиск по 4 вариантам источников (каталог, Telegram, отраслевая пресса, глобальный), сбор сигналов, отсев по тирам, синтез трендов с оценками. Триггеры: «найди тренды», «карта трендов», «трендвотчинг», «тренд-рисёрч», «выяви тренды в категории/рынке», «trend research», «trend map», «сигналы трендов». НЕ для быстрых fact-check вопросов (WebSearch) и не для общего deep research без трендовой задачи (Deep-web-search).4---56# Trend Research78Каркас процесса — как в скилле Deep-web-search, поверх него правила «Аве Марии»: источники, сигналы, оформление трендов.9107 шагов: получить задачу → SPICE-уточнение → сужение областей (approve) → план ключей и источников (approve) → параллельный поиск и сбор сигналов (50+ запросов, агенты по вариантам поиска) → отсев сигналов по тирам → синтез трендов + QA-аудит в фоне.1112## References (читать по ходу)1314- [references/sources.md](references/sources.md) — каталог источников и как в каждом искать. Читать в Phase 3 при назначении источников.15- [references/trend-rules.md](references/trend-rules.md) — мета-правила, сужение задачи, тиры сигналов, структура тренда, проверка источников. Читать в Phase 2 и Phase 5–6.16- [references/slice-method.md](references/slice-method.md) — типы слайсов для генерации запросов. Читать в Phase 3.17- [references/html-report-example.html](references/html-report-example.html) — эталон HTML-одностраничника по трендам (аналитическая шапка-саммари → «Отбор сигналов» с тирами → карта трендов → список трендов с описанием, «преломлением» и каруселью сигналов; теги сила/охват/горизонт; шрифт ONY One; редакционный тон). Использовать как структурный шаблон в Phase 7, если заказчик попросил HTML.1819## Gotchas2021- **Solid keywords верифицирует человек.** Не запускать поиск по своим ключам без подтверждения: показать список ключей (русские и английские, если нужно) и дать выбрать. Это мета-правило «Аве Марии».22- **Примеры в срезах — иллюстрации, не границы поиска.** Примеры внутри срезов агент придумывает сам — это гипотезы, а не факты о рынке. Ключи и запросы строить от формулировки среза целиком, а не от перечисленных примеров, иначе поиск замкнётся на самопридуманных кейсах и пропустит всё, чего в примерах не было. Задача поиска — найти в том числе то, что мы не смогли предугадать.23- **Не парсить всё подряд.** Нейросеть склонна усердно сканировать то, что человек сканировать бы не стал. Каждый запуск парсера/крауля должен отвечать на конкретный вопрос плана.24- **Всплеск ≠ понимание.** После найденной интересной динамики делать доп-запрос на прояснение причины (например, «why sardines are hyping»).25- **Сигналы старше 3 лет — отсев** (Tier 4). Ставить фильтры по дате в инструментах поиска.26- **Каждый сигнал несёт ссылку на первоисточник — везде.** В сборе, дедупликации, тировании и бэклоге НЕ отбрасывать URL, оставляя одно название. Фактология без рабочей ссылки = сгенерированный текст.27- **Бэклог — таблица по тирам, колонки Название | Описание | Обоснование | Источник.** Описание — полноценная фраза с цифрами, не обрезок. Никакой колонки «Тренд».28- **Бэклог сигналов пишется ДО трендов — не проставлять в нём номера трендов.** Тренды синтезируются ИЗ сигналов (Phase 6), а не наоборот. Пред-привязка сигнала к тренду = натягивание. Порядок строго: сигналы → тиры → тренды.29- **Reddit бесполезен для российских ниш** — pikabu.ru, dzen.ru, otzovik.com, irecommend.ru. Не ставить `userLocation: US` для российских тем. (Правила из QA-аудитов Deep-web-search.)30- **В чат сигналы НЕ вываливать.** Полные списки сигналов, бэклог, тексты трендов и QA-отчёт живут в файлах, а НЕ в переписке — это жжёт токены. Не пересказывать в чат находки каждого вернувшегося агента. В чат — только короткий финальный отчёт (см. Phase 6.4).31- **В трендах и бэклоге рендер сигнала одинаковый:** жирное название-действие → суть с цифрами → `— источник: [издание](URL)` + дата. Актор (Delta, Магнит) — в названии, НЕ в позиции источника. В бэклоге то же самое, разложенное по колонкам Название | Описание | Обоснование | Источник.3233## Phase 0: Получить задачу3435**Если `$ARGUMENTS` непуст** — это категория/рынок, сразу в Phase 1.3637**Если пуст** — спросить: «В какой категории/рынке ищем тренды и для какой задачи заказчика?» **STOP и ждать ответа.**3839## Phase 1: SPICE-уточнение4041Задать 6 вопросов и ждать ответов (как в Deep-web-search Phase 1):42431. **Рамки (S):** география (РФ / мир / рынок-бенчмарк) и временной горизонт трендов?442. **Перспектива (P):** чьё поведение изучаем, для какой аудитории результат?453. **Объект (I):** тренды чего именно — категория, продукт, маркетинг, бизнес-модели?464. **Сравнение (C):** есть ли бенчмарк (другая страна, соседняя категория)?475. **Критерий успеха (E):** что нужно на выходе — карта трендов, топ-N трендов, сигналы для стратегии? Какое решение примут по результатам?486. **Уже знаете:** какие тренды/отчёты уже видели, что НЕ нужно искать?4950## Phase 2: Сужение областей5152По правилу «Как сузить задачу» из [references/trend-rules.md](references/trend-rules.md):53541. Зафиксировать объекты поиска.552. Перечислить ВСЕ возможные срезы (продукт, маркетинг, сервис, бизнес-модели, процессы; гео; ширина категории) и предположить фокусные. Примеры внутри среза давать с пометкой «например» и не больше 1–2 на срез — они только поясняют срез, поиск ими не ограничивается.563. **STOP: показать список срезов с пометкой «изучаем / не изучаем» и ждать подтверждения заказчика.**5758## Phase 3: План ключей и источников5960### 3.1 Два типа ключей — не смешивать6162**A. Solid-ключи (короткие).** Ровно 2–3 на русском и 2–3 на английском (если гео позволяет), уровня категории («fish food», «морепродукты тренды»). Назначение ТОЛЬКО одно: прицельный поиск там, где длинные запросы не работают — соцсети (YouTube, Pinterest), Telegram по MCP, парсеры, дописывание к имени источника. Базой для остальных изысканий они НЕ являются — не растягивать список до 10+.6364**B. Слайс-запросы (длинные).** Основной массив запросов для поиска «без подсказки» — по правилам [references/slice-method.md](references/slice-method.md). **Ограничений на количество запросов НЕТ** — их должно хватить, чтобы покрыть каждый подтверждённый срез и широкими, и точечными запросами на всех релевантных языках. На полноценный тренд-рисёрч это обычно 50+ запросов суммарно по всем вариантам поиска; план из ~25 запросов — несерьёзный, расширить. Порядок на каждый срез:65661. Сначала широкие категорийные запросы от формулировки среза — они дискаверят то, чего мы не предугадали.672. Потом точечные по конкретным гипотезам (в т.ч. по примерам из Phase 2) — как дополнение, не основа.683. Срез, покрытый только точечными запросами по примерам, — невалиден.6970### 3.2 Распределение по вариантам поиска7172Прочитать [references/sources.md](references/sources.md) (раздел «Порядок поиска») и распределить:7374| Вариант | Какие ключи | Что делать | Инструменты |75|---|---|---|---|76| **С подсказкой источника** | Solid-ключи (A) | К solid-ключу дописывается имя источника из каталога («fish food Statista», «seafood trends McKinsey», «... Trendhunter») или `site:`/include_domains — см. пометки «Как искать» в каталоге. Пройти каталог ШИРОКО: разделы «Тренды», «Готовые исследования» + все профильные под тему. Запросов здесь может быть много — не ограничиваться 5–7, каждому потенциально релевантному источнику свой запрос | tavily_search, Exa |77| **Без подсказки** | Слайс-запросы (B) | Общий поиск по всему массиву слайс-запросов | Exa, Tavily, WebSearch |78| **Telegram: каналы из списка** | Solid-ключи (A) | **Всегда не больше 2 ключей.** Искать в релевантных каналах из TGStat-списка | telegram-mcp |79| **Telegram: все подписки** | Расширенный ключ | Только при малом улове в каналах. Запрос конкретизировать («тренды рынка морепродуктов», НЕ «рыба») — однословный категорийный ключ зацепит кучу нерелевантных чатов и даст мусор | telegram-mcp |80| **Отраслевая пресса** | Solid + слайсы | Отдельный агент собирает релевантные отраслевые издания (веб + соцсети), затем поиск по ним | subagent + tavily/Exa |8182Парсеры и сервисы «поиск внутри» — **на уровне категории, не отдельных продуктов**. Точечные продуктовые ключи в парсеры — только вторым заходом, чтобы прояснить конкретный всплеск:8384| Инструмент | Какие ключи | Как |85|---|---|---|86| `vibecode_projects/gtrends-parser` | Solid-ключи категории; динамика + RISING-запросы (Tier 2) | `./run.sh "fish food,seafood" --geo US` |87| `vibecode_projects/yt-parser` | Категория в целом («fish food»), не продукт | `./yt-parser.sh search "fish food" 30 year` |88| Яндекс Wordstat, Pinterest Trends, Glimpse | Solid-ключи | руками или WebSearch по выдаче, см. sources.md «Тренды» |8990Выбор инструмента по кейсам и fallback-правила — как в Deep-web-search (Phase 2.3): полная таблица кейсов в `.claude/skills/Deep-web-search/SKILL.md`, накопленные правила в `.claude/skills/Deep-web-search/references/operational-rules.md`.9192### 3.3 Approve9394**STOP: показать план и ждать подтверждения:**9596```97## План поиска трендов: [тема]98**Срезы:** [подтверждённые] | **Запросов:** [N]99100### Solid-ключи на верификацию (для соцсетей, Telegram, парсеров, подсказок источника)101RU (2–3): [ключ1, ключ2]102EN (2–3): [key1, key2]103104### Слайс-запросы (поиск без подсказки)105| # | Срез | Слайс | Запрос | Инструмент |106|---|------|-------|--------|------------|107108### С подсказкой источника (solid-ключ + источник)109| # | Запрос | Источник | Инструмент |110|---|--------|----------|------------|111112### Telegram / пресса / парсеры113[каналы + max 2 ключа; расширенный ключ для всех подписок; категорийные ключи парсеров]114115Подтверди ключи и план, поправь или дополни.116```117118## Phase 4: Параллельный поиск и сбор сигналов119120Агентов распределять **по вариантам поиска, а не слепо по числу запросов**: отдельный агент (или несколько) на каждый вариант — Telegram, отраслевая пресса, с подсказкой источника, без подсказки. Внутри варианта смотреть на объём: до ~15 запросов — один агент, больше — поделить между двумя-тремя (например: Telegram 10 запросов → 1 агент; с подсказкой 30 → 2 агента). Так каждый агент работает одним инструментом и одной логикой поиска, а не скачет между Telegram и Exa. Всех запускать параллельно. **Пока агенты работают и по мере их возврата — НЕ пересказывать их находки в чат** (в чате достаточно «агенты запущены» / «все вернулись»): дождаться всех, свести сигналы в файлы, и выдать один короткий отчёт по Phase 6.4. Шаблон промпта, tool usage rules, fallback-правила и per-query attribution — из Deep-web-search Phase 3. Дополнения к промпту каждого агента:1211221. **Собирать сигналы по ходу.** Часть находок — не источники, а сигналы (проекты, новые компании, продукты, запуски, нашумевшие новости). Каждый оформлять сразу по формату: **Название сигнала (что произошло — решение/действие) + суть с цифрами + `— источник: [издание](URL)` + дата.** ВАЖНО: компания/актор внутри названия (напр. «Delta», «Магнит») — это НЕ источник. Источник — издание/отчёт/канал, откуда взят факт, и он ВСЕГДА идёт в конце после `— источник:` (если фактов из двух изданий — `— источники:`). Название должно быть самодостаточным и содержательным (полная мысль с цифрой), а не обрезком.1232. **Логировать провенанс каждого сигнала.** У каждого сигнала фиксировать, **от какого запроса** (№) и **из какого источника** (издание/канал/отчёт) он получен — чтобы в конце свести, что реально приносит сигналы. Без этого QA не сможет оценить полезность источников.1243. **Прояснять всплески.** Нашёл интересную динамику → доп-запрос на причину («why X is hyping»).1254. **Фильтр по дате:** сигналы старше 3 лет не собирать (`startPublishedDate`, `--dateafter`).1265. Возвращать: per-query breakdown (как в Deep-web-search) + отдельный блок «Сигналы» (каждый с пометкой запрос № / источник).127128Если после первого раунда сигналов мало (искали в основном отчёты) — запустить дополнительный раунд поиска сигналов с фокусом на отраслевые СМИ и глобальный поиск (правило 2 из «Как выбирать сигналы»).129130## Phase 5: Отсев сигналов по тирам131132По разделу «Как выбирать сигналы для тренда» из [references/trend-rules.md](references/trend-rules.md):1331341. Свести все сигналы от агентов, дедуплицировать.1352. Каждому сигналу присвоить Tier 1–4 с одной строкой обоснования.1363. Tier 4 (старше 3 лет) — отсев; Tier 3 — оставить с низким приоритетом.1374. Сохранить бэклог-файл: какие сигналы пошли в работу, какие отсеяны и почему.138139**Формат бэклога — таблица по тирам, 4 колонки: Название | Описание | Обоснование | Источник.** Отдельная таблица под каждый тир (Tier 1 → Tier 4), плюс таблицы «Контр-сигналы» и «Кластеры». Колонки:140141- **Название** — сигнал как решение/действие (напр. «Магнит удваивает продажи готовых блюд из рыбы»); РФ-сигналы помечать `[RU]`.142- **Описание** — что именно произошло, с цифрами. Полноценная фраза, не обрезок.143- **Обоснование** — одна строка, почему этот тир.144- **Источник** — рабочая ссылка `[Название](URL)` + дата (безссылочные Telegram — `[Канал, дата](t.me/...)`). Ссылка обязательна у КАЖДОГО (правило «нет ссылок → текст сгенерирован»); URL при дедупликации/тировании не отбрасывать.145146```147| Название | Описание | Обоснование | Источник |148|----------|----------|-------------|----------|149| Магнит ×2 RTE-рыбы [RU] | Сеть удваивает продажи готовых блюд из рыбы в 2026 | Крупный ритейлер ставит деньги на формат | [Магнит, 2026-03](URL) |150```151152Содержание каждой строки = канонический сигнал из trend-rules.md (Название решения/действия + суть + источник), просто разложенный по колонкам.153154**НЕ проставлять в бэклоге номера или названия трендов.** Тренды на этом этапе ещё не построены — они рождаются ИЗ сигналов в Phase 6. Привязка сигнала к тренду в бэклоге = обратная логика (натягивание сигналов под заранее решённые тренды). Правильный порядок строго: **сигналы → тиры → (потом) синтез трендов**. Максимум допустимого в бэклоге — группировка похожих сигналов в кластеры по смыслу (без присвоения им финального номера тренда) как мостик к Phase 6.155156## Phase 6: Синтез трендов + сохранение157158### 6.1 Синтез159160По разделу «Как оформлять тренд»: сгруппировать похожие по смыслу сигналы в системные тренды **по принципу движущей силы** (фундаментальное изменение в предпочтениях и поведении потребителей). Каждый тренд описать по структуре:1611621. Название1632. Описание (что изменилось vs как было раньше)1643. Преломление тренда — влияние на продукт/маркетинг под задачу заказчика1654. Список сигналов с описанием и ссылками1665. Сила тренда 1–101676. Глобальность (локальный–глобальный)1687. Долгосрочность (краткосрочный–долгосрочный)169170Перед выдачей — проверка источников по чеклисту «Как проверять источники» (актуальность, первоисточник, авторитетность, предвзятость).171172### 6.2 Сохранение (MANDATORY)173174Все файлы — в `CLOUD ZB (3600)/Researches/<slug>/` (новые файлы, ничего не перезаписывать):175176- `<slug>-trends-YYYY-MM-DD.md` — тренды с сигналами и оценками (+ мета: дата, назначение, описание)177- `<slug>-signals-backlog-YYYY-MM-DD.md` — бэклог сигналов: в работе / отсеяны с причинами и тирами. **Каждая строка сигнала несёт ссылку на первоисточник** (колонка с URL в таблице либо инлайн `[источник](URL)`) — фактология без ссылок недопустима.178179### 6.3 QA-аудит (фоном)180181Параллельно с синтезом запустить фоновый QA-агент по формату Deep-web-search Phase 3.5 (оценка ключей, инструментов, извлечения). Полный отчёт в чат НЕ печатать — **дописать в накопительный файл `CLOUD ZB (3600)/Researches/trend-research-qa-log/trend-research-qa-log.md`** (создать папку и файл при первом запуске; шапка и формат — как в `search-quality-log.md`, но это отдельный лог только для тренд-рисёрчей). В чат идёт только 2–3 строки QA-резюме внутри финального отчёта (см. Phase 6.4).182183**Дополнительно — полезность по сигналам (главное для этого скилла).** Кроме оценки выдачи, QA-агент сводит провенанс сигналов (запрос № / источник из Phase 4) и отдельным блоком проговаривает:184185- **Топ запросов по сигналам** — какие запросы принесли больше всего сигналов и сколько из них дошло до Tier 1–2 (а не просто «дали выдачу»).186- **Топ источников по сигналам** — какие издания / каналы / отчёты оказались «жилами» (много сигналов), а какие — пустышки (0 сигналов при наличии выдачи).187- **Вывод для каталога** — какие источники стоит добавить/поднять в `sources.md`, какие — понизить.188189Таблицы:190191```192### Полезность запросов (по сигналам)193| Запрос | Сигналов | из них Tier 1–2 | Вердикт |194195### Полезность источников (по сигналам)196| Источник | Сигналов | из них Tier 1–2 | Тип (жила/россыпь/пусто) |197```198199Метрика — выжившие сигналы, НЕ количество результатов поиска: источник с 10 результатами и 0 сигналов Tier 1–2 = пустышка.200201## Phase 6.4: Вывод в чат (MANDATORY)202203**Сигналы, бэклог и полный QA — только в файлах. В чат — короткий финальный отчёт, и всё.** Не дублировать в переписке списки сигналов и тексты трендов (это жжёт токены). Формат отчёта в чат:2042051. **Список ключевых трендов** — только названия (можно с оценкой силы), 1 строка на тренд. Без описаний и сигналов.2062. **Сколько сигналов на тренд** — числом рядом с каждым трендом (или сводкой «N сигналов на M трендов, из них Tier 1–2 — K»).2073. **QA-резюме** — 2–3 строки: главные жилы, главные пустышки, 1 вывод для каталога. Полный QA — в `trend-research-qa-log/`.2084. **Пути к файлам** — где лежат тренды, бэклог, QA.209210Всё, что подробнее этого, пользователь открывает в файлах сам. Если он попросит раскрыть конкретный тренд — тогда и раскрывать, точечно.211212## Phase 7: Предложить HTML-оформление213214После короткого отчёта в чат (Phase 6.4) **спросить заказчика: «Оформить тренды в HTML-одностраничник?»** и STOP. Не собирать HTML без подтверждения — многим достаточно md.215216**Если да** — собрать одностраничник по эталону [references/html-report-example.html](references/html-report-example.html) (прочитать его как структурный шаблон):217218- **Структура:** аналитическая шапка-саммари (тема, задача, что нашли, каналы поиска, оценка трендов) → раздел «Отбор сигналов» с легендой тиров Tier 1–4 → карта трендов (оглавление с мини-метром силы) → список трендов, у каждого: заголовок, теги (сила метром + N/10, охват, горизонт, `РФ` где есть), **полное Описание**, врезка **«Преломление под задачу»**, **карусель сигналов** (Tier-чип + название-действие + суть + `источник: [издание](URL)`, кнопки ‹ ›, свайп/drag).219- **Тон:** редакционный, читабельный, без продающих слоганов и без «трёх опор»/финального «продающего» блока (это аналитический отчёт, а не презентация-продажа). Данные (тренды, описания, сигналы, оценки) брать из уже сохранённых md-файлов Phase 6.2, не переписывать заново.220- **Шрифт ONY One** — 6 начертаний в `CLOUD ZB (3600)/Signal, Ony/fonts-ony/ONYOne-{Thin,Light,Regular,Medium,Bold,Black}.otf`. Копировать в `Researches/<slug>/onepager/fonts/` и подключать через `@font-face` относительным путём.221- **Куда:** `Researches/<slug>/onepager/index.html` (+ `fonts/`). Проверить рендер через headless-Chrome (скриншот), затем дать путь в чат.222- **Деплой лендингом** (если попросят «выложить на сайт») — статикой в `public/<slug>/` Next-сайта + `rewrites` для чистого URL; коммитить только свои файлы.
victorbuto