Скетчер HTML-макетов

Эскиз

Используйте этот навык, когда пользователь хочет увидеть направление дизайна прежде чем утвердить его — исследование идей UI/UX в виде одноразовых HTML-макетов. Смысл в том, чтобы сгенерировать 2-3 интерактивных варианта, чтобы пользователь мог сравнивать визуальные направления бок о бок, а не создавать готовый к отправке код.

Загружайте этот навык, когда пользователь говорит что-то вроде: "набросай этот экран", "покажи, как может выглядеть X", "сравни макет A и B", "дай мне 2-3 варианта этого UI", "позволь мне увидеть несколько вариантов", "сделай макет до того, как я начну строить".

Когда НЕ использовать этот навык

• Пользователь хочет продакшен-компонент — используй claude-design или построй нормально
• Пользователь хочет отполированный одноразовый HTML-артефакт (лендинг, презентацию) — claude-design
• Пользователь хочет диаграмму — excalidraw, architecture-diagram
• Дизайн уже утверждён — просто построй это

Если у пользователя установлена полная система GSD

Если gsd-sketch появляется как родственный навык (установленный через npx get-shit-done-cc --hermes), предпочтительно использовать gsd-sketch для полного рабочего процесса: постоянная директория .planning/sketches/ с MANIFEST, анализ в режиме фронтира, аудиты согласованности по предыдущим эскизам и интеграция с остальной частью GSD. Этот навык — облегчённая автономная версия — одноразовое создание эскизов без машины состояний.

Основной метод

сбор данных  →  варианты  →  прямое сравнение  →  выбор победителя (или итерация)

1. Сбор данных (пропустите, если пользователь уже дал достаточно)

Перед созданием вариантов получите три вещи — по одному вопросу за раз, не все сразу:

1. Ощущение. "Каким должно быть ощущение? Прилагательные, эмоции, вайб." — "спокойный, редакторский, как Linear" говорит вам больше, чем "минималистичный".
2. Референсы. "Какие приложения, сайты или продукты передают ощущение, которое вы себе представляете?" — реальные референсы лучше абстрактных описаний.
3. Основное действие. "Что самое важное делает пользователь на этом экране?" — варианты должны хорошо это обслуживать; если нет, то это просто украшение.

Кратко обдумывайте каждый ответ перед следующим вопросом. Если пользователь уже предоставил все три заранее, сразу переходите к вариантам.

2. Варианты (2-3, никогда 1, редко 4+)

Создайте 2-3 варианта за один раз. Каждый вариант — это полный, самодостаточный HTML-файл. Не описывайте варианты — стройте их. Смысл в сравнении.

Каждый вариант должен занимать разную дизайнерскую позицию, а не отличаться значениями пикселей. Три хорошие оси для вариантов:

• Плотность: компактный / воздушный / сверхплотный (выберите два контрастных полюса)
• Акцент: контент-первый / действие-первый / инструмент-первый
• Эстетика: редакторский / утилитарный / игривый
• Макет: одноколоночный / сайдбар / разделённая панель
• Основа: на карточках / чистый контент / документный стиль

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

Именование вариантов: описывайте позицию, а не номер.

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. Сделайте их настоящим HTML

Каждый вариант — это один самодостаточный HTML-файл:

• Встроенный <style> — никакого шага сборки, никакого внешнего CSS
• Системные шрифты или один Google Font через <link>
• Tailwind через CDN (<script src="https://cdn.tailwindcss.com"></script>) допустим
• Реалистичный фейковый контент — настоящие предложения, настоящие имена, не "Lorem ipsum"
• Интерактивный: ссылки кликабельны, ховеры работают, хотя бы один переход состояния (открыть/закрыть, фильтр, переключение). Застывшее статичное изображение хуже, чем небрежное анимированное.

Откройте его в браузере. Если выглядит сломанным, исправьте перед показом пользователю.

Проверьте варианты визуально — используйте браузерные инструменты Hermes. Не просто пишите HTML и надейтесь, что он отрендерится; загрузите каждый вариант и посмотрите на него:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Выглядит ли этот макет чистым и читаемым? Есть ли видимые ошибки (наложение текста, нестилизованные элементы, сломанные изображения)?")

browser_vision возвращает AI-описание того, что фактически на странице, плюс путь к скриншоту — ловит ошибки вёрстки, которые чистый осмотр исходников упускает (например, шрифт не подгрузился без ошибки, флекс-контейнер схлопнулся). Исправляйте и переходите снова, пока каждый вариант не будет выглядеть правильно.

Сброс CSS по умолчанию + стек системных шрифтов для быстрого старта:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README варианта

README.md каждого варианта отвечает на:

## Вариант: {название позиции}

### Дизайнерская позиция
Одно предложение о принципе, движущем этим вариантом.

### Ключевые решения
- Макет: ...
- Типографика: ...
- Цвет: ...
- Взаимодействие: ...

### Компромиссы
- Силён в: ...
- Слаб в: ...

### Лучше всего для
- Тип пользователя или сценарий использования, который этот вариант на самом деле обслуживает

5. Прямое сравнение

После построения всех вариантов представьте их как сравнение. Не просто перечисляйте — высказывайте мнение:

## Три взгляда на главный экран

| Измерение | Спокойный редакторский | Утилитарный плотный | Игривый разделённый |
|-----------|----------------|-------------------|---------------|
| Плотность   | Низкая            | Высокая              | Средняя        |
| Заметность основного действия | Низкая | Высокая | Средняя |
| Сканируемость | Высокая | Средняя | Низкая |
| Ощущение | Спокойное, доверительное | Резкое, как инструмент | Приглашающее, энергичное |

**Моё мнение:** Утилитарный плотный для опытных пользователей, спокойный редакторский для аудитории, ориентированной на контент. Игривый разделённый слабее всех — пытается делать и то, и другое, и ни к чему не приходит.

Позвольте пользователю выбрать победителя, или объединить два в гибрид, или запросить ещё один раунд.

Тематизация (когда у проекта есть визуальная идентичность)

Если у пользователя есть существующая тема (цвета, шрифты, токены), поместите общие токены в sketches/themes/tokens.css и @import их в каждом варианте. Минимизируйте токены:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Не переусердствуйте с токенизацией для одноразового эскиза — трёх цветов и одного шрифта обычно достаточно.

Планка интерактивности

Эскиз достаточно интерактивен, когда пользователь может:

1. Кликнуть по основному действию и происходит что-то видимое (изменение состояния, модальное окно, уведомление, имитация перехода)
2. Увидеть один осмысленный переход состояния (фильтрация списка, переключение режима, открытие/закрытие панели)
3. Навести на узнаваемые аффордансы (кнопки, строки, вкладки)

Больше этого — переинжиниринг одноразового. Меньше этого — просто скриншот.

Режим фронтира (выбор, что заскетчить следующим)

Если эскизы уже существуют и пользователь говорит "что мне набросать следующим?":

• Пробелы в согласованности — два победивших варианта из разных эскизов приняли независимые решения, которые ещё не были скомпонованы вместе
• Незаскетченные экраны — упоминались, но не исследованы
• Покрытие состояний — "счастливый путь" заскетчен, но не пустое / загрузка / ошибка / 1000 элементов
• Адаптивные пробелы — проверено в одном viewport; держится ли на мобильном / сверхшироком?
• Паттерны взаимодействия — статические макеты есть; переходы, перетаскивание, поведение скролла отсутствуют

Предложите 2-4 именованных кандидата. Дайте пользователю выбрать.

Вывод

• Создайте sketches/ (или .planning/sketches/ если пользователь использует соглашения GSD) в корне репозитория
• По одной поддиректории на вариант: NNN-stance-name/index.html + README.md
• Сообщите пользователю, как их открыть: open sketches/001-calm-editorial/index.html на macOS, xdg-open на Linux, start на Windows
• Держите варианты одноразовыми — эскиз, который вы почувствовали необходимость сохранить, должен быть повышен до реального кода проекта, а не курироваться как актив

Типичная последовательность инструментов для одного варианта:

terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Вариант: Спокойный редакторский\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="Как это выглядит? Есть ли очевидные проблемы с макетом?")

Повторите для каждого варианта, затем представьте сравнительную таблицу.

Атрибуция

Адаптировано из рабочего процесса /gsd-sketch проекта GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Полная система GSD поставляется с постоянным состоянием эскизов, ссылками на шаблоны тем/вариантов и рабочими процессами аудита согласованности; установите с помощью npx get-shit-done-cc --hermes --global.