Make Landing

---
name: make-landing
description: >-
  Создаёт несколько вариантов дизайна 2D-поверхности (лендинг, герой, обложка, слайды): свой визуальный референс и автор на вариант, полный design.md с UTC/SHA-256 до кода, проверка в браузере, галерея, картинки в чат, выбор человека и второй раунд смешения победителей. Применять по /make-landing, «варианты дизайна», «несколько вариантов лендинга на выбор», «редизайн».
---

# make-landing: дизайн через варианты

**Вариант** — самостоятельное направление с визуальным референсом, полным контрактом и рабочим preview. **Канон** — исходная поверхность проекта, куда после выбора переезжает результат. До выбора авторы работают в своих папках.

Подходит для лендинга, героя, обложки и слайдов. Размеры и формат результата берутся из задачи. Если направление уже выбрано, выполняй обычную реализацию по его контракту.

## 1. Общий бриф

Найди исходник, текущую страницу, команду запуска и правила проекта. При редизайне сними исходную страницу и покажи картинкой в чате. Сохрани `brief.md`: аудитория, задача поверхности, проверенные тексты/оффер/CTA, обязательные секции, доступные ассеты, формат результата, ограничения и критерии готовности. При существенном пробеле проверь публичные первоисточники; приватный контекст остаётся локально. Источники фактов у всех авторов общие.

Число вариантов N возьми из запроса. Если его нет, уточни; предложи 6–10 для широкого поиска. Решение человека определяет N. При лимите исполнителей запускай волнами с полным scope до готового preview.

При запрете менять текст сохрани текстовый канон и список разрешённых фактических корректировок. Каждый автор использует его дословно. Композицию и порядок можно менять; полноту исходных смысловых секций проверяй отдельно. Дизайнерские заметки остаются в документах процесса.

## 2. Референсы и матрица направлений

Привяжи каждый вариант к отдельному визуальному референсу: ссылка или локальный файл и конкретные приёмы сетки, типографики, композиции, медиа и навигации. Например: газетная полоса, швейцарская сетка, терминал, журнальный разворот, фотокопированный зин. Референс задаёт визуальное направление; права на чужие тексты, фотографии и бренд проверяются отдельно.

В `directions.md` запиши N строк:

| slug | Референс и приёмы | composition | storytelling | type | media/proof | navigation | Гипотеза и компромисс |
|---|---|---|---|---|---|---|---|

Каждая пара должна заметно различаться минимум по трём осям — рабочая эвристика для отбора. Дай каждому автору свою строку и общий бриф. Авторы самостоятельно проектируют свою версию; координатор сверяет матрицу и фиксированные концепции. Дополнительные референсы человека создают новые направления: сохраняй готовые варианты, обновляй матрицу и галерею, добавляй авторов.

## 3. Папки и исполнители

Заведи постоянную папку результата в проекте, например:

```text
redesign/
├── brief.md
├── directions.md
├── index.html                 # галерея всех готовых вариантов
├── round-1/<slug>/
│   ├── author-brief.md
│   ├── design.md
│   ├── concept-freeze.json
│   ├── design-amendments.md    # создаётся при корректировках после freeze
│   ├── index.html             # или исходник в формате задачи
│   ├── assets/
│   ├── screenshots/
│   └── result.md
└── round-2/<slug>/
```

У каждого автора своя папка, порт и кеш сборщика. При работе с существующим приложением дай отдельную копию или worktree и его обычную команду сборки. Для самостоятельного HTML-preview достаточно HTML/CSS/JS и локального сервера. Галерея открывается рядом с вариантами. Канон, общие данные, установленные скиллы и чужие папки авторы не меняют; останавливают только свои процессы по PID. Каждый автор знает, что рядом работают другие, и сохраняет их правки.

Бриф автора включает общий brief, референс, строку матрицы, пути, границы владения, формат результата и роль [references/author.md](references/author.md). Дай автору фактический путь установленной папки скилла для запуска скрипта; пути `scripts/` и `references/` ниже считаются от неё.

По умолчанию один исполнитель на вариант — Codex CLI, параллельно в фоне:

```sh
codex exec -C <папка> --skip-git-repo-check -m <модель> -o <итог.md> - < <бриф.md>
```

Модель — выбранная человеком либо самая сильная из доступных Codex. При «model not supported» проверь и обнови CLI или используй более новую установленную версию. Если Codex CLI недоступен, передай тот же бриф субагенту-исполнителю. Число одновременных авторов соответствует возможностям среды; каждый доводит свою версию до проверки и отчёта.

## 4. Полный design.md до кода

Автор читает [references/design-template.md](references/design-template.md) и создаёт полный `design.md`: гипотеза, видимый эффект, компромисс, сценарий чтения, первый экран, сетка, адаптив, типографика и токены, компоненты и состояния, медиа, Do’s and Don’ts, критерии `check`. Концепция должна позволять восстановить композицию и поведение без догадок.

Перед HTML/CSS/компонентами зафиксируй концепцию. Команды выполняются из папки скилла; папка варианта — фактический путь:

```sh
python3 scripts/freeze_concept.py freeze <папка-варианта>
python3 scripts/freeze_concept.py verify <папка-варианта>
```

`concept-freeze.json` содержит UTC, SHA-256 и этап `before_implementation`. Автор сообщает координатору пути концепции и freeze, затем реализует вариант. Сверка направлений внутри процесса не требует нового согласования человека. Timestamp подтверждает запись; порядок «концепция → freeze → код» обеспечивается последовательностью работы.

`design.md` и freeze остаются неизменными. Коллизии направлений и необходимые изменения запиши перед изменением кода в `design-amendments.md`: исходный hash, причина, изменённые решения и затронутые проверки. Проверяй freeze после реализации.

Если поручена генерация изображений, каждый автор создаёт полезные ассеты внутри своей концепции доступным инструментом генерации. Назначение фиксируется до freeze или в amendment перед генерацией; сохраняются промпт и итоговый файл. Читаемый текст и интерактивные связи реализуй средствами поверхности. Реальные продуктовые доказательства берутся из брифа.

## 5. Реализация и проверка

Автор сдаёт готовую поверхность со всеми необходимыми ассетами. Для веба проверь реальные CTA, якоря, меню/FAQ, клавиатуру, focus, reduced motion, шрифты и загрузку изображений. Для обложки или слайдов проверь заданный размер, читаемость и экспорт. Зафиксируй результаты `check`, полноту контента и ограничения в `result.md`.

Открой фактический рендер всей поверхности, исправь видимые дефекты и пересними затронутые кадры. Веб-скриншоты у всех вариантов в одном масштабе: desktop viewport минимум 1200 px, по умолчанию 1440×900; длинная страница — последовательность таких кадров. Явно заданный человеком размер обложки или слайда имеет приоритет. На узких ширинах отдельно проверь DOM, overflow и порядок блоков. После исправлений повторяй затронутые проверки.

## 6. Галерея и показ

Координатор собирает `redesign/index.html` рядом с вариантами. На первом экране — визуальные карточки в одинаковом масштабе: имя, референс, гипотеза, компромисс, фактический screenshot, ссылки на preview и design.md. Подписывай происхождение визуала: референс, эскиз или рендер реализации. Ссылки на процесс и файлы идут после сравнения. Список и счётчик вариантов строятся по текущей матрице. Для командного выбора можно добавить согласованное голосование.

Картинки каждого варианта отправляй в чат по готовности, не дожидаясь остальных. Когда готовы все: сравнение в 2–4 строки и рекомендация — что читается сильнее, что ближе к смыслу, где риск. Выбирает человек. Визуальный QA подтверждает качество реализации; конверсия требует отдельного измерения.

## 7. Выбор, второй раунд и канон

После выбора 1–3 победителей предложи 1–2 направления второго раунда, смешивающие сильные элементы выбранных вариантов: например, сетка одного и типографика другого. Запиши происхождение решений и компромиссы. У каждого нового варианта своя папка, автор, полный design.md, freeze, проверка и картинки. Первый раунд сохраняется. Выбор итоговой версии остаётся за человеком; если он просит сразу перенести победителя, переходи к канону.

Выбранную версию перенеси в исходник проекта с настоящими данными и рабочими CTA. Убери демонстрационную обвязку из продукта. Выполни сборку и проверки проекта, открой живую страницу и сверь её с финальными кадрами; при старой версии обнови с обходом кеша. Финальные картинки покажи в чате. В коммит входят только свои пути. Внешняя публикация выполняется в пределах разрешения человека.