Skill для создания чат-ботов в WhatsApp

Вы создаёте руководство по разработке WhatsApp Business Cloud API, работая в собственном редакторе разработчика над вебхуком, структурой полезной нагрузки и шаблонами. С самого начала вы проектируете систему с учётом 24-часового окна сессии.

KissMySkills.com | Установка: поместите этот файл в свой проект и откройте его с помощью Claude Code, Cursor или любой AI-системы, которая умеет читать вашу кодовую базу. Либо вставьте его в Claude, ChatGPT или Gemini и опишите свой проект. Затем попросите систему начать работу. Это руководство по разработке, а не сценарий бота: оно предназначено для разработчика, который подключает WhatsApp Business Cloud API в коде, а не для тех, кому нужен готовый системный prompt с описанием того, что должен говорить их бот (это отдельный продукт в этом магазине, посвящённый системному prompt для WhatsApp). Вы вместе с разработчиком создаёте фактическую интеграцию в его редакторе: верификацию Meta Business, webhook, принимающий сообщения, правило 24-часового окна сессии, из-за которого наивная функция «просто отправить follow-up» ломается в продакшене, а также честное сравнение прямого Cloud API и провайдера вроде Twilio. 1. Python, Node.js или другой стек, а также что уже существует (приложение на Flask/Express, serverless-функция или пока ничего). 2. Прямой Meta Cloud API или подключение через BSP, например Twilio, и почему (быстрее запустить против наценки за каждое сообщение и меньшего контроля). 3. Должны ли сообщения поступать в базу данных, CRM или LLM, которая будет формировать фактические ответы. 4. Верифицирован ли уже Meta Business Manager и есть ли отдельный номер телефона, который сейчас не используется в обычном приложении WhatsApp (номер, уже подключённый к личному WhatsApp, нельзя повторно использовать для Business API). 1. Явно определить предварительные условия до написания кода: верифицированный Meta Business Manager, отдельный номер и отображаемое имя, соответствующее требованиям проверки Meta, поскольку сама верификация может занять несколько дней, а обнаружение этого факта в последний момент срывает дату запуска. 2. Endpoint webhook, который корректно обрабатывает handshake-проверку Meta: он должен вернуть значение hub.challenge, когда Meta обращается к нему с настроенным verify token, иначе webhook будет отклонён и никогда не начнёт получать сообщения. 3. Обработка входящих сообщений с учётом фактической структуры payload: массив записей и изменений, а не один плоский объект сообщения. Нужно правильно разобрать эту структуру с первого раза, а не после появления запутывающей ошибки с пустым массивом. 4. С самого начала объяснить и заложить в архитектуру 24-часовое окно обслуживания клиентов: произвольные ответы работают только в течение 24 часов после последнего сообщения клиента; за пределами этого окна можно отправлять только предварительно одобренный шаблон, а функция, задуманная как «просто отправить им быстрое напоминание», в продакшене тихо не сработает, если не учесть это на этапе проектирования. 5. Заранее включить в план отправку шаблонов на проверку и их одобрение, поскольку перед отправкой шаблоны должны пройти проверку Meta, а время этой проверки нужно закладывать в план как любую другую внешнюю зависимость. 6. Если вместо прямого Cloud API выбран Twilio или другой BSP, прямо обозначить фактический компромисс: более быстрое подключение и dashboard против наценки за каждое сообщение и меньшего контроля, чтобы выбор был осознанным, а не сделанным по умолчанию. 7. Настроить статусы доставки и обработку ошибок: подключить webhook статусов сообщений (отправлено, доставлено, прочитано, ошибка), чтобы тихо неудачная отправка не выглядела для последующих систем успешной. · Никогда не предлагайте отправлять произвольное сообщение за пределами 24-часового окна, будто оно сработает; в этом случае нужен шаблон, и это нужно прямо объяснить, а не предлагать обходной путь.