new-landing — генератор лендингов

Ты — генератор лендингов для этой системы (см. корневой README.md и docs/adr/). На выходе — самодостаточный статический HTML, соблюдающий контракт системы, в отдельной ветке с автоматическим превью-URL. Человек остаётся в контуре: в main ничего не мержим.

Жёсткие правила (не нарушать)

1. Инвариант статики (ADR-0001): контент — в HTML, виден без JS. Никаких внешних CSS/JS на

критическом пути, никакого клиентского рендеринга контента. Стили и минимальный vanilla-JS — инлайн.

1. Правдивость (правила копирайта проекта): никаких выдуманных фактов, компаний, цифр,

отзывов, гарантий. Если факта нет в брифе — не сочиняй, спроси или опусти. Не раскрывай внутренние секреты/реальную архитектуру продукта.

1. Язык: русский, без англицизмов там, где есть русский аналог (см. тон существующих

лендингов).

1. Контракт обязателен: готовый файл обязан пройти scripts/check_landing.py без ошибок.

Workflow

1. Получить или собрать бриф

Бриф — структурированный вход пайплайна. Формат и поля — в reference/brief-schema.md. Два пути:

• Пользователь принёс готовый бриф (например, собранный внешней нейросетью по

reference/brief-prompt.md) — используй его как есть; добери только недостающие обязательные поля.

• Брифа нет — собери сам: пройди по полям схемы, спрашивая блоками через AskUserQuestion.

Правило достаточности: не начинай генерацию, пока не заполнены Цель, CTA, Продукт, Аудитория, Оффер, Доказательства, Публикация. Никогда не выдумывай доказательства (факты/цифры/кейсы) ради заполнения — если их нет, ставь «нет данных» и не пиши в лендинг. В будущем доказательства будет поставлять RAG по базе знаний компании; пока источник — бриф.

2. Изучить контракт и эталоны

• Прочитай reference/landing-contract.md — обязательные требования (SEO/аналитика/структура/

доступность).

• При необходимости подсмотри паттерн секций в эталоне index.html.

Не копируй его контент — он про Acme.

3. Сгенерировать лендинг

Возьми за основу reference/landing-skeleton.html. Замени все контентные плейсхолдеры {{...}} реальным контентом из брифа. Плейсхолдеры аналитики/верификации ({{METRIKA_ID}}, {{GA4_ID}}, {{YANDEX_VERIFICATION}}, {{GOOGLE_VERIFICATION}}) оставь как есть — они защищены guard-ом и подставляются отдельно. Поставь уникальный маркер сборки: <!-- build:<slug>-landing-v1 -->.

4. Самопроверка

python3 .claude/skills/new-landing/scripts/check_landing.py <путь-к-файлу>

Исправь все ERROR, минимизируй WARN. Затем подними локально (python3 -m http.server 8000) и проверь, что рендерится и контент виден без JS.

5. Завести ветку и превью

• slug: нижний регистр, всё кроме [a-z0-9._-] → -. Не используй зарезервированные имена

(blog, имена ассетов) — их CI отклонит.

• Размести файл:
• отдельный путь (подпапка <name>/index.html → отдаётся по /<name>);
• новый домен: нужен контейнер + Traefik-роут на сервере и правка deploy.yml — это

нетривиально, заведи отдельный ADR и согласуй (см. docs/adr/0002-...).

• Ветка от dev, коммит, пуш:

  git switch -c landing-<slug> dev
  git add <files> && git commit -m "feat(landing): <slug>"
  git push origin landing-<slug>

CI поднимет превью: https://staging.example.com/landing-<slug>/. Учитывай ограничение превью по подпути (ADR-0004): корневые пути резолвятся к корню new.*.

6. Отчёт

Дай: превью-URL, результат check_landing.py, что осталось доделать (реальные ID Метрики/GA4, верификации, домен/Traefik если новый домен), и предложи ревью перед вливанием в dev/main.

Заметки на будущее

Это вариант A (dev-time). Если понадобится self-serve — эволюция в сервис на Agent SDK или n8n+Claude API (см. README, обсуждение агента). Накопленные удачные приёмы выноси в reference/landing-contract.md, чтобы качество не зависело от удачи промпта.