init-landing-system

---

name: init-landing-system description: Развернуть систему генерации лендингов (скиллы new-landing/landing-experiment/landing-journal/landing-ads + CI + nginx + docs/adr + experiments + стартовые README/CLAUDE) в уже существующем проекте. Использовать, когда нужно поставить эту систему в другой репозиторий/проект, забутстрапить лендинг-проект с нуля или перенести наработки. Merge-aware: не затирает существующие файлы без подтверждения.

init-landing-system — развёртывание системы в проекте

Ставит всю систему генерации лендингов в существующий проект из снимка (reference/system/) + шаблонов (reference/templates/), подставляя инфраструктурные значения целевого проекта. Безопасно: существующие файлы по умолчанию не перезаписываются.

Когда и где

• Запускать в целевом проекте (куда ставим систему), не в эталоне-источнике.
• Чтобы skill был доступен в любом проекте — установить его в user-level: bash scripts/install_user.sh (копирует skill со снимком в ~/.claude/skills/). После этого /init-landing-system доступен везде.
• Снимок системы обновляется из эталона скриптом scripts/sync_templates.sh (запускать в эталонном репо после изменений в скиллах/CI/инфре, затем переустановить в user-level).

Workflow

1. Проверки

• Целевой проект — git-репозиторий (если нет — предложи git init).
• Это не сам эталон-источник (init_project.py предупредит, если увидит себя в целевом).

2. Собрать параметры

Нужно (если не заданы — спроси через AskUserQuestion):

• brand — название проекта/бренда;
• prod-domain — канонический прод-домен;
• staging-domain — staging-домен;
• slug — базовый slug (из него имена контейнеров <slug>-landing / new-<slug>-landing и каталоги /root/<container>; можно переопределить --prod-container/--staging-dir и т.д.).

3. Предпросмотр (dry-run)

python3 .claude/skills/init-landing-system/scripts/init_project.py \
  --brand "<Brand>" --prod-domain <prod> --staging-domain <staging> --slug <slug> \
  --target <path-to-project> --dry-run

Покажет, что будет записано и что уже существует (конфликты).

4. Развернуть

Убери --dry-run. Существующие файлы пропускаются (перечислятся). Чтобы перезаписать конкретные — повтори с --force (осторожно: затрёт правки целевого проекта).

5. Что получит проект

.claude/skills/ (4 генераторных скилла), .github/workflows/ (deploy + cleanup-preview под домены проекта), deploy/nginx.{prod,staging}.conf, docs/adr/ (README + template), experiments/README.md, .gitignore, стартовые README.md и CLAUDE.md.

6. Чеклист ручного (вне кода)

init_project.py печатает его в конце:

1. Сервер: два контейнера nginx + Traefik-роуты на домены (как в эталоне: Traefik + два nginx:alpine; webroot <DIR>/html, конфиг <DIR>/nginx.conf).
2. DNS: прод- и staging-домены → сервер.
3. GitHub-secrets: DEPLOY_HOST, DEPLOY_USER, DEPLOY_SSH_KEY, DEPLOY_KNOWN_HOSTS.
4. Первый лендинг: /new-landing; затем реальные ID Метрики/верификаций.

7. Зафиксировать

Предложи в целевом проекте: git add -A && git commit первичной системы. Дальше проект живёт по своему README/CLAUDE.

Важно

• Контентные плейсхолдеры скелета ({{TITLE}}, {{HERO_*}}, {{METRIKA_ID}} …) не подставляются — это часть new-landing, заполняются при генерации лендинга. init подставляет только инфраструктурный whitelist (см. reference/placeholders.md).
• Инвариант системы переносится вместе: лендинги — статический HTML, контент в разметке, без JS на критпути.