Разработчик нишевого B2B-продукта опубликовал Landforge — систему на базе Claude Code skills, которая автоматизирует полный цикл работы с лендингами. Проект выложен в открытый доступ под лицензией MIT.
Claude Code skills — это механизм, позволяющий превратить разовый удачный промпт в воспроизводимый процесс. Каждый skill представляет собой папку с файлом SKILL.md, где описаны инструкция и условия применения, а также вспомогательные файлы: шаблоны, справочники, скрипты. При вызове /skill-name ассистент подхватывает эти инструкции и выполняет задачу строго по ним — без зависимости от формулировки промпта в конкретный день. Это принципиальное отличие от обычного использования LLM, где качество результата варьируется от сессии к сессии.
| Skill | Что делает |
|---|---|
| new-landing | Генерирует лендинг из брифа: контракт, скелет, валидатор |
| landing-experiment | A/B-тест на одном URL через inline-сплит |
| landing-journal | Аудит-журнал изменений — что и когда менялось |
| landing-ads | Материалы для Яндекс Директа и Google Ads: UTM, тексты, ключи |
| init-landing-system | Разворачивает всю систему в существующий проект |
Landforge включает пять skills: new-landing генерирует лендинг из брифа, landing-experiment реализует A/B-тест на одном URL, landing-journal ведёт аудит-журнал изменений, landing-ads готовит материалы для Яндекс Директа и Google Ads с UTM-метками, а init-landing-system разворачивает всю систему в существующий проект.
Жёсткий инвариант системы: лендинг — статический HTML без клиентского рендеринга, CSS и JS только инлайн.
Ключевое архитектурное решение — отказ от SPA в пользу статического HTML. Лендинги на React с клиентским рендерингом показывают поисковым роботам пустой контейнер `<div id="root"></div>`: JavaScript дорисовывает контент уже после загрузки, но краулер его не ждёт. Для страницы, которая должна индексироваться и корректно превьюиться при шеринге, это критический изъян. В Landforge зафиксирован жёсткий инвариант: лендинг — самодостаточный статический HTML-файл, CSS и минимальный vanilla-JS только инлайн, никаких внешних блокирующих ресурсов на критическом пути.
Недетерминированность LLM-генерации решается через контракт и автоматическую проверку. Скилл new-landing состоит из трёх частей: landing-contract.md описывает обязательные элементы каждого лендинга (title, meta description, canonical, Open Graph, Twitter Card, JSON-LD, ровно один h1, guarded-аналитика), landing-skeleton.html содержит нейтральный скелет, уже соответствующий контракту, а check_landing.py — валидатор, который прогоняется по готовому файлу и возвращает ненулевой код при нарушении. Модель наполняет скелет контентом, а не изобретает структуру заново. Автор отмечает, что при первом же прогоне валидатор нашёл нарушение в его собственном старом лендинге: там подключались Google Fonts через render-blocking `<link>`.
Деплой организован по принципу branch-routed через GitHub Actions. Ветка main уходит в продакшн и индексируется, ветка dev — на staging с заголовком noindex, любая другая ветка автоматически поднимает превью по адресу staging-домен/{branch} также с noindex. Под капотом — Traefik перед двумя nginx-контейнерами; превью-папка очищается отдельным workflow при удалении ветки. Заголовок X-Robots-Tag: noindex выставляется на уровне nginx, что надёжнее мета-тега и закрывает разом все не-продакшн окружения.
A/B-тесты лендингов нередко реализуют на разных URL, что легко превращается в клоакинг — показ разного контента роботам и людям, за которое поисковики применяют санкции. В Landforge тест идёт на одном URL: вариант A лежит в HTML, вариант B применяется поверх лёгким скриптом по cookie-сплиту, выбранный вариант передаётся в аналитику как параметр визита. Контент доступен роботу в обоих случаях. Система допускает один активный тест за раз и включает «трафик-гейт» — напоминание о минимальном объёме данных для статистически значимых выводов.
Для фиксации истории изменений встроен аудит-журнал landing-journal: каждое значимое действие записывается append-only в journal.jsonl с хешем git-коммита. Записи не перезаписываются — ошибки исправляются добавлением корректирующей записи. Автор описывает это как «чёрный ящик» проекта, позволяющий восстановить, что и когда менялось и чем закончилось.
Автор честно обозначает ограничения: серверная часть (контейнеры nginx, маршруты Traefik, DNS, GitHub-секреты) настраивается вручную — система лишь печатает чеклист. Сниппеты аналитики Метрики и Google Analytics в скелете — стандартный вендорный boilerplate, не авторский код. Система пока не является полноценным генератором из контент-модели с библиотекой блоков — это обозначено в дорожной карте.