Sketch

Одноразовые HTML-макеты: 2–3 варианта дизайна для сравнения.

Метаданные навыка


Источник	Встроенный (установлен по умолчанию)
Путь	`skills/creative/sketch`
Версия	`1.0.0`
Автор	VibeOS (адаптировано из gsd-build/get-shit-done)
Лицензия	MIT
Платформы	linux, macos, windows
Теги	`sketch`, `mockup`, `design`, `ui`, `prototype`, `html`, `variants`, `exploration`, `wireframe`, `comparison`
Связанные навыки	`spike`, `claude-design`, `popular-web-designs`, `excalidraw`

Справочник: полный SKILL.md

к сведению

Ниже приведено полное описание навыка, которое VibeOS загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.

Sketch

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

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

Когда НЕ использовать

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

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

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

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

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

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

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

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

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

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»
Интерактивность: ссылки кликабельны, ховеры настоящие, хотя бы один переход состояния (открыть/закрыть, фильтр, переключатель). Замороженное статическое изображение — худший вариант, чем неаккуратная анимированная версия.

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

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

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

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

Сброс 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;
}

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

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

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

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

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

Режим Frontier (выбор следующего наброска)

Если наброски уже существуют и пользователь спрашивает «что мне набросать дальше?»:

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

Предложите 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 --vibeos --global.

Метаданные навыка​

Справочник: полный SKILL.md​

Sketch

Когда НЕ использовать​

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

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

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

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

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

4. README варианта​

5. Сравнение​

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

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

Режим Frontier (выбор следующего наброска)​

Результат​

Атрибуция​

Метаданные навыка

Справочник: полный SKILL.md

Когда НЕ использовать

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

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

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

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

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

4. README варианта

5. Сравнение

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

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

Режим Frontier (выбор следующего наброска)

Результат

Атрибуция