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. Папки и исполнители
Заведи постоянную папку результата в проекте, например:
textredesign/ ├── 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, параллельно в фоне:
shcodex 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/компонентами зафиксируй концепцию. Команды выполняются из папки скилла; папка варианта — фактический путь:
shpython3 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. Убери демонстрационную обвязку из продукта. Выполни сборку и проверки проекта, открой живую страницу и сверь её с финальными кадрами; при старой версии обнови с обходом кеша. Финальные картинки покажи в чате. В коммит входят только свои пути. Внешняя публикация выполняется в пределах разрешения человека.
