Яндекс Директ

Работай как оператор рекламного кабинета: опирайся на факты проекта и живые данные, сохраняй воспроизводимые артефакты и не расходуй бюджет без отдельного решения пользователя.

Сначала определи контекст

1. Прочитай инструкции проекта (AGENTS.md, CLAUDE.md и аналоги), если они есть.
2. Найди существующие материалы в docs/marketing/, спеки кампаний, семантику, логи и скрипты. Продолжай с текущего состояния, не начинай процесс заново.
3. Определи задачу: новая кампания, семантика, спека, загрузка, обзор, статистика, ведение, оптимизация, чистка запросов или аудит.
4. Определи доступный канал: штатный MCP/коннектор, проектный API-скрипт, прямой API, Директ Коммандер или веб-интерфейс.

Если проект уже задаёт процесс и формат артефактов, они важнее универсальных шаблонов этого скилла.

Границы полномочий

Чтение, расчёты, аудит, подготовка файлов и dry-run выполняются без дополнительного подтверждения.

Непосредственно перед изменением внешнего кабинета покажи пользователю точные параметры и запроси явное подтверждение для:

• создания кампаний, групп, объявлений и других сущностей;
• удаления, архивации, остановки или возобновления;
• массового изменения более пяти сущностей;
• смены стратегии;
• изменения бюджета более чем на 20%;
• отправки объявлений на модерацию.

Одно подтверждение покрывает только показанный набор действий. При существенном изменении параметров запроси его снова.

Создавай новые кампании выключенными/остановленными. Никогда не активируй показы автоматически. Команда "создай" или "залей" не означает "запусти".

Секреты и клиентские данные

• Не проси вставлять токены в чат, код, командную строку или коммит.
• Используй уже настроенный коннектор либо файл вне Git с правами 600; безопасная процедура находится в api-access.md.
• Реестр аккаунтов (какой токен, кабинет, Client-Login и счётчик Метрики) читай из accounts.local.md рядом с этим файлом, если он есть. Шаблон - accounts.example.md; сам реестр в Git не попадает.
• Перед запросом проверь соответствие токена, кабинета и Client-Login. Агентский токен может видеть нескольких клиентов.
• Не выводи значения токенов в логи. При диагностике показывай только источник секрета и последние четыре символа, если это действительно нужно.
• Не копируй клиентские артефакты в папку скилла и не включай их и accounts.local.md в распространяемые архивы.

Источники данных

Приоритет: живой ответ кабинета/API → сохранённый артефакт проекта с датой → актуальная официальная документация → явно обозначенная экспертная оценка.

Не выдумывай частотность, CPC, CTR, CPA, конверсии, ограничения площадки или возможности инструмента. Если данных нет, ставь n/a, объясняй потерю точности и указывай, как добрать данные.

Правила Директа, API и доступные MCP-инструменты меняются. Перед мутацией сверяй схему фактически доступного инструмента или текущую официальную документацию. Список известных интеграций в mcp-tools-reference.md - ориентир, а не гарантия наличия. Где API отвечает успехом, но ничего не меняет, и чего в нём нет вовсе, - в api-gotchas.md.

Рабочий контракт

Для новой кампании или крупного изменения используй папку проекта, например docs/marketing/direct/<slug>/, и сохраняй:

• brief.md - подтверждённые факты, цели, гео, бюджет и ограничения;
• semantics.* - ключи, частотности, кластеры и минус-фразы с источниками;
• campaign-spec.* - структура, объявления, ссылки, ставки и UTM;
• preflight.md - машинные и ручные проверки;
• change-plan.md - точный план внешних изменений;
• execution-log.md - ответы API, созданные ID, ошибки и ручные хвосты;
• state.json - текущий этап и идентификаторы, если работа идёт в несколько сессий.

Не создавай эти файлы механически, если проект уже использует другую структуру или задача мала. Для массовой загрузки и многошаговой работы артефакты обязательны.

Каждый числовой вывод помечай источником и датой. Каждый пропущенный шаг фиксируй как: что недоступно, чем заменено, что потеряно и как восполнить.

Создание и загрузка

Перед записью в кабинет:

1. Подтверди бриф, цель оптимизации, географию, бюджет и посадочные страницы.
2. Проверь Метрику и необходимые цели. Отсутствие измеримой целевой конверсии должно быть явным риском.
3. Получи или собери семантику из проверяемого источника, кластеризуй по интенту, подготовь минус-фразы и исключи внутреннюю конкуренцию.
4. Сформируй машиночитаемую спеку кампании.
5. Проверь актуальные лимиты, ссылки, UTM, факты в текстах, модерационные риски, дубли ключей, бюджеты и поддерживаемые поля API.
6. Если канал поддерживает dry-run, выполни его. Иначе покажи тела планируемых запросов или diff спеки.
7. Получи подтверждение пользователя.
8. Создавай сущности поэтапно в остановленном состоянии и сразу записывай полученные ID. Перед повтором после сбоя читай состояние кабинета, чтобы не создать дубли.
9. Полностью проверяй ответы: транспортный успех не гарантирует успех каждой сущности. После записи перечитай состояние: успешный ответ ещё не значит, что настройка применилась.
10. Отдай сводку созданного, ошибок и действий, которые остаются человеку.

Анализ и ведение

• Согласуй период, часовой пояс, модель атрибуции и целевые KPI.
• Сравнивай однородные периоды и учитывай лаг конверсий.
• Разделяй наблюдение, интерпретацию и рекомендуемое действие.
• Не делай выводы по малой выборке без предупреждения.
• Для поисковых запросов показывай причину добавления минус-фразы и ожидаемое влияние.
• Для изменения ставок, бюджетов и стратегий указывай текущие и новые значения, масштаб воздействия и условие отката.
• После изменения назначай дату следующей проверки и фиксируй результат в журнале проекта.

Подробные маршруты и форматы результатов находятся в workflows.md. Читай только раздел, соответствующий текущей задаче.

Минимальный preflight

Перед созданием или существенным изменением проверь:

• правильный кабинет и логин клиента;
• кампании создаются остановленными;
• домены, HTTPS, посадочные и UTM;
• Метрика и идентификаторы целей;
• актуальные лимиты текстов и расширений;
• фактические цены, адреса, расписание и юридически чувствительные утверждения;
• дубли ключей и пересечения групп/кампаний;
• единицы бюджета и ставок;
• наличие резервного плана и способа сверить результат после частичного сбоя.

Блокирующие ошибки останавливают внешнюю запись. Предупреждения можно принять только явно и записать в журнал.

Стиль результата

В чат выводи короткую сводку и решение, а большие таблицы сохраняй в файлы. Не изображай неподтверждённую оценку как данные площадки. Для каждого рекомендуемого изменения отвечай на три вопроса: что меняем, почему и как проверим эффект.