/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. Папки и исполнители

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

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, параллельно в фоне:

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/компонентами зафиксируй концепцию. Команды выполняются из папки скилла; папка варианта — фактический путь:

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 перед генерацией; сохраняются промпт и итоговый файл. Читаемый текст и инт