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

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. Убери демонстрационную обвязку из продукта. Выполни сборку и проверки проекта, открой живую страницу и сверь её с финальными кадрами; при старой версии обнови с обходом кеша. Финальные картинки покажи в чате. В коммит входят только свои пути. Внешняя публикация выполняется в пределах разрешения человека.