# Trend Research > Поиск и оформление трендов по методике «Аве Мария»: SPICE-уточнение, сужение областей, верификация ключей человеком, поиск по 4 вариантам источников (каталог, Telegram, отраслевая пресса, глобальный), сбор сигналов, отсев по тирам, синтез трендов с оценками. Триггеры: «найди тренды», «карта трендов», «трендвотчинг», «тренд-рисёрч», «выяви тренды в категории/рынке», «trend research», «trend map», «сигналы трендов». НЕ для быстрых fact-check вопросов (WebSearch) и не для общего deep research без трендовой задачи (Deep-web-search). - Skill: `victorbuto/trend-research` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add victorbuto/trend-research` - Raw SKILL.md: https://api.skillmd.com/api/skills/victorbuto/trend-research/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: victorbuto (https://skillmd.com/u/victorbuto) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/victorbuto/trend-research --- # Trend Research Каркас процесса — как в скилле Deep-web-search, поверх него правила «Аве Марии»: источники, сигналы, оформление трендов. 7 шагов: получить задачу → SPICE-уточнение → сужение областей (approve) → план ключей и источников (approve) → параллельный поиск и сбор сигналов (50+ запросов, агенты по вариантам поиска) → отсев сигналов по тирам → синтез трендов + QA-аудит в фоне. ## References (читать по ходу) - [references/sources.md](references/sources.md) — каталог источников и как в каждом искать. Читать в Phase 3 при назначении источников. - [references/trend-rules.md](references/trend-rules.md) — мета-правила, сужение задачи, тиры сигналов, структура тренда, проверка источников. Читать в Phase 2 и Phase 5–6. - [references/slice-method.md](references/slice-method.md) — типы слайсов для генерации запросов. Читать в Phase 3. - [references/html-report-example.html](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): 1. **Рамки (S):** география (РФ / мир / рынок-бенчмарк) и временной горизонт трендов? 2. **Перспектива (P):** чьё поведение изучаем, для какой аудитории результат? 3. **Объект (I):** тренды чего именно — категория, продукт, маркетинг, бизнес-модели? 4. **Сравнение (C):** есть ли бенчмарк (другая страна, соседняя категория)? 5. **Критерий успеха (E):** что нужно на выходе — карта трендов, топ-N трендов, сигналы для стратегии? Какое решение примут по результатам? 6. **Уже знаете:** какие тренды/отчёты уже видели, что НЕ нужно искать? ## Phase 2: Сужение областей По правилу «Как сузить задачу» из [references/trend-rules.md](references/trend-rules.md): 1. Зафиксировать объекты поиска. 2. Перечислить ВСЕ возможные срезы (продукт, маркетинг, сервис, бизнес-модели, процессы; гео; ширина категории) и предположить фокусные. Примеры внутри среза давать с пометкой «например» и не больше 1–2 на срез — они только поясняют срез, поиск ими не ограничивается. 3. **STOP: показать список срезов с пометкой «изучаем / не изучаем» и ждать подтверждения заказчика.** ## Phase 3: План ключей и источников ### 3.1 Два типа ключей — не смешивать **A. Solid-ключи (короткие).** Ровно 2–3 на русском и 2–3 на английском (если гео позволяет), уровня категории («fish food», «морепродукты тренды»). Назначение ТОЛЬКО одно: прицельный поиск там, где длинные запросы не работают — соцсети (YouTube, Pinterest), Telegram по MCP, парсеры, дописывание к имени источника. Базой для остальных изысканий они НЕ являются — не растягивать список до 10+. **B. Слайс-запросы (длинные).** Основной массив запросов для поиска «без подсказки» — по правилам [references/slice-method.md](references/slice-method.md). **Ограничений на количество запросов НЕТ** — их должно хватить, чтобы покрыть каждый подтверждённый срез и широкими, и точечными запросами на всех релевантных языках. На полноценный тренд-рисёрч это обычно 50+ запросов суммарно по всем вариантам поиска; план из ~25 запросов — несерьёзный, расширить. Порядок на каждый срез: 1. Сначала широкие категорийные запросы от формулировки среза — они дискаверят то, чего мы не предугадали. 2. Потом точечные по конкретным гипотезам (в т.ч. по примерам из Phase 2) — как дополнение, не основа. 3. Срез, покрытый только точечными запросами по примерам, — невалиден. ### 3.2 Распределение по вариантам поиска Прочитать [references/sources.md](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. Дополнения к промпту каждого агента: 1. **Собирать сигналы по ходу.** Часть находок — не источники, а сигналы (проекты, новые компании, продукты, запуски, нашумевшие новости). Каждый оформлять сразу по формату: **Название сигнала (что произошло — решение/действие) + суть с цифрами + `— источник: [издание](URL)` + дата.** ВАЖНО: компания/актор внутри названия (напр. «Delta», «Магнит») — это НЕ источник. Источник — издание/отчёт/канал, откуда взят факт, и он ВСЕГДА идёт в конце после `— источник:` (если фактов из двух изданий — `— источники:`). Название должно быть самодостаточным и содержательным (полная мысль с цифрой), а не обрезком. 2. **Логировать провенанс каждого сигнала.** У каждого сигнала фиксировать, **от какого запроса** (№) и **из какого источника** (издание/канал/отчёт) он получен — чтобы в конце свести, что реально приносит сигналы. Без этого QA не сможет оценить полезность источников. 3. **Прояснять всплески.** Нашёл интересную динамику → доп-запрос на причину («why X is hyping»). 4. **Фильтр по дате:** сигналы старше 3 лет не собирать (`startPublishedDate`, `--dateafter`). 5. Возвращать: per-query breakdown (как в Deep-web-search) + отдельный блок «Сигналы» (каждый с пометкой запрос № / источник). Если после первого раунда сигналов мало (искали в основном отчёты) — запустить дополнительный раунд поиска сигналов с фокусом на отраслевые СМИ и глобальный поиск (правило 2 из «Как выбирать сигналы»). ## Phase 5: Отсев сигналов по тирам По разделу «Как выбирать сигналы для тренда» из [references/trend-rules.md](references/trend-rules.md): 1. Свести все сигналы от агентов, дедуплицировать. 2. Каждому сигналу присвоить Tier 1–4 с одной строкой обоснования. 3. Tier 4 (старше 3 лет) — отсев; Tier 3 — оставить с низким приоритетом. 4. Сохранить бэклог-файл: какие сигналы пошли в работу, какие отсеяны и почему. **Формат бэклога — таблица по тирам, 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 Синтез По разделу «Как оформлять тренд»: сгруппировать похожие по смыслу сигналы в системные тренды **по принципу движущей силы** (фундаментальное изменение в предпочтениях и поведении потребителей). Каждый тренд описать по структуре: 1. Название 2. Описание (что изменилось vs как было раньше) 3. Преломление тренда — влияние на продукт/маркетинг под задачу заказчика 4. Список сигналов с описанием и ссылками 5. Сила тренда 1–10 6. Глобальность (локальный–глобальный) 7. Долгосрочность (краткосрочный–долгосрочный) Перед выдачей — проверка источников по чеклисту «Как проверять источники» (актуальность, первоисточник, авторитетность, предвзятость). ### 6.2 Сохранение (MANDATORY) Все файлы — в `CLOUD ZB (3600)/Researches//` (новые файлы, ничего не перезаписывать): - `-trends-YYYY-MM-DD.md` — тренды с сигналами и оценками (+ мета: дата, назначение, описание) - `-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. **Список ключевых трендов** — только названия (можно с оценкой силы), 1 строка на тренд. Без описаний и сигналов. 2. **Сколько сигналов на тренд** — числом рядом с каждым трендом (или сводкой «N сигналов на M трендов, из них Tier 1–2 — K»). 3. **QA-резюме** — 2–3 строки: главные жилы, главные пустышки, 1 вывод для каталога. Полный QA — в `trend-research-qa-log/`. 4. **Пути к файлам** — где лежат тренды, бэклог, QA. Всё, что подробнее этого, пользователь открывает в файлах сам. Если он попросит раскрыть конкретный тренд — тогда и раскрывать, точечно. ## Phase 7: Предложить HTML-оформление После короткого отчёта в чат (Phase 6.4) **спросить заказчика: «Оформить тренды в HTML-одностраничник?»** и STOP. Не собирать HTML без подтверждения — многим достаточно md. **Если да** — собрать одностраничник по эталону [references/html-report-example.html](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//onepager/fonts/` и подключать через `@font-face` относительным путём. - **Куда:** `Researches//onepager/index.html` (+ `fonts/`). Проверить рендер через headless-Chrome (скриншот), затем дать путь в чат. - **Деплой лендингом** (если попросят «выложить на сайт») — статикой в `public//` Next-сайта + `rewrites` для чистого URL; коммитить только свои файлы.