version: "1.0.0" name: blogger-ads-skill description: "Сопровождает рекламную сделку в Telegram на стороне блогера, рекламодателя или агентства: условия, отдельные DOCX договора и приложений, счёт, печатный и XML УПД, маркировка, сроки и завершение. Используй при подготовке или ведении конкретного рекламного размещения, проверке пакета документов либо готовности к публикации."

Сопровождение рекламного размещения

Доведи поручение до готовых файлов и понятного следующего действия. Установи сторону пользователя — блогер, рекламодатель или агентство — и защищай её интересы конкретными условиями. Навык самостоятельный: docx-contracts, банковский модуль, конкретный календарь или ОРД не нужны. Python запускай через uv run; зависимости объявлены в скриптах. Пути команд в справках относятся к каталогу навыка, $WORK — существующая папка сделки вне него.

Начало и продолжение

При сопровождении сделки веди deal-state.json с известными условиями, существенными поручениями пользователя и открытыми вопросами. Используй инициализацию. При продолжении сначала прочитай состояние, документы и новые сообщения. Разовый счёт использует отдельные бухгалтерские данные.

Первый содержательный ответ при подготовке документов составь по [порядку уточнения](references/intake.md#первое-уточнение): отдели ещё не заданные вопросы от уже отложенных сведений. Сопоставь материалы с картой полей выбранных шаблонов, задай оставшиеся вопросы до сборки и дождись ответа; варианты условий предложи для согласования. Прямое поручение подготовить проект без уточнений выполни с обозначенными пробелами.

Выбор режима

Прочитай справку нужного режима; не загружай все справки без необходимости.

Если вместе с вопросом о готовности пришла новая редакция договора, сначала выполни сверку и учти изменившиеся условия в состоянии и плане.

Общие правила

• Сохраняй смысл и происхождение. Не выдумывай реквизиты, НДС, сроки, подписи или оплату. Различай роли участников, факт, подтверждение, поручение и предложение. Числовое условие сохраняй с точным значением, единицей, минимумом/максимумом и началом отсчёта. Новые условия предлагай явно. Дата сообщения не доказывает дату события; пустая подпись в копии не доказывает отсутствие другого подписанного экземпляра или нарушение порядка оплаты.
• Сохраняй версии. Полученные оригиналы и прежние выданные файлы не перезаписывай; исправления оформляй отдельно. Дата основного договора сохраняется между редакциями, её явное изменение учитывается по порядку выдачи. При новом доказательстве обнови текущие факты и все актуальные собственные материалы, старые выводы оставь в истории. Порядок сохранения и восстановления точных файлов — в справке.
• Разделяй материал и маркировку. В новой схеме creative — текст, ссылки и медиа без конкретного ERID; его выдача, принадлежность и вставка учитываются отдельно. Полученные оригиналы не меняй. Если ERID уже есть в исходнике, используй порядок версий и подтверждений, включая исключение для действующего подписанного приложения прежней схемы. Выбранные текст и карту ссылок импортируй дословно через deal.py import-creative: сохраняй пробелы, эмодзи, якоря, порядок и повторы URL. Получение или замена ERID не меняет согласование неизменного материала, но требует проверки маркировки. Полный creative_sha256 бери только из import-creative/fingerprint.
• В документах — реквизиты и условия сторон. Статусы проверок, сомнения, разбор переписки и задания агенту сохраняй в состоянии сделки. Не заполняй ими договор, приложения, счёт или УПД; неизвестное значение в проекте договора оставь коротким местом для заполнения по правилам шаблонов.
• Закрывай пропуски перед окончательной выдачей. Сверь итоговый текст с картой полей: реквизиты, суммы, даты, сроки и контакты. Окончательный договор, рабочий счёт и УПД не должны содержать незаполненных обязательных полей, {{…}}, ____ или «уточнить». Недостающие данные запроси по порядку уточнения. Явно отложенные сведения повторно не спрашивай: такой договор или приложение выдавай только как проект и перечисли оставшиеся пропуски в сообщении пользователю. Для рабочего счёта или УПД дождись обязательных данных. Места для будущих подписей и необязательной печати пропусками не считаются.
• Подготовка документов и разрешение публикации различаются. Будущая оплата, неподтверждённый ERID, открытая правовая проверка или отсутствие подписей не мешают подготовить проект с обозначенными пробелами. При поручении подготовить пакет и наличии согласованного текста создай также проект Приложения № 2 сейчас. Готовность публикации устанавливай по подтверждениям и политике сделки.
• Сопровождение использует доступные напоминания. После согласования даты выбери подходящий инструмент среды: крон, рутины, календарь или другой доступный способ. В пределах поручения создай напоминания и сохрани их сведения в состоянии сделки; одного канала достаточно, несколько — по выбору пользователя. JSON/Markdown/ICS — необязательный экспорт для выбранного файлового способа, а не условие выдачи документов. Полноту следующих действий оценивай по открытым вопросам, обновление напоминаний — по правилам расписания. Срок обязательства и час напоминания различаются; пропуск напоминания сам по себе не требует переноса публикации.
• Проверяй окончательные файлы. Заполняй готовый шаблон DOCX через render_contract.py, сохраняй карту полей и ручные правки. После последней правки прочитай итоговый текст. Просмотр в редакторе и PDF — по порядку проверки DOCX; PDF нужен только по потребности. Адреса перехода в своём и полученном приложении проверь через inspect_links.py --expected по правилам сверки ссылок.
• Бухгалтерские границы сохраняются. Счёт создаётся без подписи и печати; полностью оплаченный экземпляр — invoice_status=paid_archive. PDF печатай из того же HTML и просмотри все страницы. XML — неподписанный титул продавца с XSD-проверкой; подпись, приём оператором и подтверждение операции проверяются отдельно. Неподдерживаемый случай не имитируй готовым XML.
• Внешние действия требуют поручения. Не подписывай, не отправляй контрагенту, не публикуй и не меняй кабинеты без соответствующего разрешения. Уже данное разрешение повторно не спрашивай. При недоступном инструменте выполни локальную часть и назови точное действие пользователя.

Выдача результата

При выдаче новых или изменённых файлов выполни техническую проверку: зарегистрируй файлы, включая PDF при его наличии, и проверь сообщение со ссылками командой handoff.py check --state … --response …. Флаг --record-issue добавляй только при выдаче файлового плана. Исправь ошибки до выдачи; передай проверенные файлы и ссылки. Обычные уточнения и ответы без нового пакета не требуют этой процедуры.

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