Present

present — беспоук HTML-презентация

Превращает папку-контекст (или текст/тему) в самодостаточную HTML-деку, спроектированную под этот контент. Один файл, открывается офлайн в браузере, листается стрелками и колесом. Заметки спикера — в отдельном presenter-окне и живом файле <slug>-notes.js: правятся прямо в окне докладчика (E) или во внешнем редакторе — и подхватываются на лету; на самой деке их нет. Дека и всё нужное ей для показа живут в отдельной подпапке deck/ (её можно унести целиком), а в рабочей папке рядом с исходниками — DECK.md, манифест деки (карта слайдов, решения, как править).

Философия (главное)

Ты — дизайнер презентаций, а не заполнитель шаблона. Прочитай текст слайдов (slides.md) и бриф (design.md), выбери арт-дирекшн (assets/art-direction.md) и собери деку с нуля. Разные доклады → визуально разные деки (структура, палитра, типографика, фон, движение), а не перекрашенный один вид.

• Надёжный движок assets/kernel.html (из ассетов ЭТОГО скилла, не из копий во входной папке) копируется ДОСЛОВНО — навигация/анимации/заметки/экспорт в PDF не ломаются. Весь визуал пиши в его <style id="design"> и в слайды #deck. <script id="kernel">, <style id="print"> и chrome-DOM не трогай.
• assets/design-axes.md — 9 осей дизайн-решений: о чём принять решение до сборки, чтобы дека не повторяла прошлые. Ось 9 — интерактивность: где на этой деке зритель поймёт больше, если нажмёт сам.
• assets/cookbook.md — техническая справка: контракт классов kernel, контракт интерактива, офлайн-шрифты, медиа, проверки. Готовых компонентов и примеров арт-дирекшна там намеренно НЕТ — визуал придумывается под доклад.
• assets/deck-template.md — скелет DECK.md, манифеста деки (создаётся на Шаге 5, обновляется при доводке).
• Самодостаточность (жёстко): готовая дека — офлайн, без сетевых ссылок. Полный контракт (шрифты, base64, разрешённые инструменты, единственное исключение — OSS-шрифт по согласию) — в cookbook.md, это канон.

Два режима

У скилла два режима, и режим выбирает пользователь — вопросом в самом начале (Шаг 0), а не ты по догадке.

Быстрый режим — это другой процесс, а не дека похуже: слайды всё так же проектируются под контент, kernel копируется дословно, дека остаётся офлайн и самодостаточной. Экономятся шаги, а не качество. Понадобилось больше — деку раскручивают до полной (см. «Продолжить работу над готовой декой»).

Главное правило процесса (полный режим)

НИКОГДА не собирай деку, пока в папке не существуют ОБА входных файла: slides.md (текст по слайдам) и design.md (дизайн-бриф). Чего нет — добери через интервью (или найди готовый бриф) и сохрани файлом, и только потом показывай план (Шаг 3) и строй. Если оба уже есть — лишнее интервью не нужно, сразу к плану. В быстром режиме этого гейта нет — там нет ни slides.md, ни design.md, ни манифеста.

Раскладка папки (жёстко)

Быстрый режим — раскладки нет. На диске у пользователя появляется ровно один файл:

куда сказал пользователь/
└── <slug>.html            ← всё внутри: движок, стили, слайды, заметки, медиа base64

Черновики (текст по слайдам, промежуточные сборки) держи в scratchpad-папке сессии и не складывай рядом с декой. Не создавай deck/, notes.js, DECK.md, slides.md, design.md и build-скрипт — весь смысл режима в том, что после него не надо ничего убирать.

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

доклад/                          ← рабочая папка (её дал пользователь)
├── slides.md                    вход: текст по слайдам
├── design.md                    вход: дизайн-бриф
├── transcript.md · *.jpg · *.m4a   сырьё, референсы, аудио — лежат как лежали
├── src/ · build.py              исходники сборки (режим «скрипт»)
├── DECK.md                      манифест: карта слайдов и решения
└── deck/                        ← САМОДОСТАТОЧНАЯ папка показа
    ├── <slug>-<дата>.html
    ├── <slug>-<дата>-notes.js
    └── deck-assets/             только если медиа не влезло в base64 (sidecar)

Правила: в deck/ не кладём ничего лишнего — только то, без чего дека не покажется (HTML, его notes.js, sidecar-медиа). Материалы и исходники из рабочей папки не переносим и не удаляем; сборочный скрипт и src/ живут снаружи, DECK.md — тоже снаружи (это документ процесса, а не рантайм). Папка deck/ уже занята другой декой → назови <slug>-deck/ и укажи это в DECK.md. Пути внутри деки — только относительные (deck-assets/…), чтобы папка ездила целиком. Достраиваешь деку, собранную по старой раскладке (HTML лежит прямо в рабочей папке) — переложи её в deck/ вместе с notes.js и sidecar-медиа и поправь пути в скрипте сборки.

Шаг 0 — Ингест контекста (молча), затем режим и место

Сначала прочитай $ARGUMENTS и приложенное — молча. Если дана папка — просканируй (Glob/Read) и разложи:

• DECK.md от прошлой сборки — есть в папке → прочитай ПЕРВЫМ: там режим деки (скрипт/руками), карта слайдов и принятые решения с их «почему». Правь деку с их учётом, не ломая зафиксированное.
• Текст по слайдам — ищи файл slides.md (или content.md / любой .md с разбивкой: разделители ---, ## Слайд N, заголовки) → пары «слайд + заметка спикера». Это ОТДЕЛЬНЫЙ вход от design.md (бриф-стиль не заменяет текст слайдов). Нет файла с текстом слайдов — НЕ выдумывай контент из прочего материала: иди в Шаг 2, ветка (A), и создай slides.md вместе с пользователем.
• design.md (если пришёл как decision.md/DESIGN.md/brief.md — сохрани как design.md) — дизайн-бриф = авторитетный арт-дирекшн (часто экспорт с styles.refero.design: цвет-токены, типо-шкала, компоненты, Do/Don't, :root). Есть → применяй ТОЧНО по art-direction.md.
• Медиа — Glob по *.png/jpg/jpeg/gif/webp/svg; запомни пути и размеры (ls -la) для встраивания.
• Опц. референс — reference.html, URL в аргументах.
• Готовая дека на входе — дали *.html с маркером KERNEL v в шапке → это не материал, а дека, которую продолжают: иди в раздел «Продолжить работу над готовой декой» вместо обычного пайпа. Другие типы: .docx → извлеки текст (сниппет в cookbook.md, python3 stdlib); путь к репо → реальные цифры (git log, счёт файлов) для слайдов-доказательств; тема/сырой текст — как есть. Не выдумывай цифры.

Затем — первый и обязательный вопрос: режим. Задай его через AskUserQuestion, ДО любого замысла, интервью и файлов. Исключение одно: на входе готовая дека — режим у неё уже есть, вопроса не задавай, иди в раздел «Продолжить работу над готовой декой», он сам разберёт доводку и раскрутку. Варианты формулируй по тому, что уже увидел в материалах, а не абстрактно:

• быстрая дека — «соберу один HTML-файл, ничего больше на диске не появится»;
• полный доклад — «разверну комплект: текст слайдов, бриф, папка показа, манифест». Таблица различий — секция «Два режима». Материалы явно тянут в одну сторону (пришла папка со slides.md и design.md — это доклад; пришёл абзац в чат — это быстрая дека) — так и скажи в формулировке варианта, но решение всё равно за пользователем.

Место — вторым вопросом, только если оно не задано:

• полный режим: папка дана в аргументах → работаем в ней молча, ничего не спрашиваем. Не дана → спроси, где создать рабочую папку (предложи 2-3 конкретных пути — например <текущая директория>/<slug>/ — плюс «указать свой»). Не разворачивай комплект в текущей директории по умолчанию.
• быстрый режим: спроси одним вопросом, куда положить готовый HTML (текущая директория — годный первый вариант). Путь к готовому файлу назови в финале явно.

Шаг 1 — Замысел + арт-дирекшн (внутренне)

Сформируй: (а) структуру — разбивку по слайдам, что на каждом, где сильные кадры; (б) арт-дирекшн — пройди оси из assets/design-axes.md (композиция, поля, типографика, цвет, фон, движение, детали, хром, интерактивность) и выпиши ответ одной строкой на ось; как читать бриф и референс — assets/art-direction.md. В быстром режиме хватит осей 1, 4, 5 (+9, если контент явно просит) — но ответы всё равно свои, а не «как обычно». Это проектирование под материал, а не выбор из меню: готовых видов в ассетах нет, и брать их из прошлых дек или из чужих файлов во входной папке нельзя. Ответ «как обычно» на любой оси означает, что ось не продумана — перерешай. Если есть design.md — ОН и есть арт-дирекшн, свой не выдумывай: как именно применять (палитра, масштаб типографики, шрифты) — канонический раздел в art-direction.md. Если дан URL-референс — извлеки дизайн-ДНК (defuddle→WebFetch; см. art-direction.md).

Ось 9 проходится по слайдам, а не в общем. Пройди раскадровку и отметь кандидатов: слайд, где есть сравнение «до/после»; зависимость, у которой зритель мог бы покрутить параметр и увидеть следствие; данные, не влезающие в кадр целиком; развилка, по которой доклад может пойти по-разному. Каждого кандидата проверь тремя вопросами оси 9: добавляет ли нажатие ПОНИМАНИЕ (а не движение); кто нажмёт — докладчик со сцены или читатель по ссылке; читается ли слайд, если не нажать вообще. Выживших оставь не больше двух-трёх — их и понесёшь в план. Не выжил никто — это нормальный ответ, дека статична, и вопроса пользователю не будет.

Шаг 2 — Гейт входных файлов (условное интервью через AskUserQuestion) · только полный режим

Быстрый режим — весь этот шаг пропускается: файлов нет, интервью нет, идёшь сразу в сборку. Кратко доложи, что понял и какую деку предлагаешь (тема, арка, арт-дирекшн одной фразой). Затем убедись, что в папке существуют ОБА файла — slides.md и design.md. Чего нет — добери и сохрани файлом. Всё уточняй только через AskUserQuestion (2-4 варианта + авто-«Другое», дисциплина как в скилле interview). Оба файла уже есть → пропусти этот шаг и иди к плану (не задавай лишних вопросов — это и есть «интервью не всегда»).

(A) Текст слайдов slides.md. Нет файла с текстом слайдов — предложи оба варианта:

• (а) создать slides.md и заполнить вместе — короткое структурированное интервью по слайдам («тезис слайда → заметка спикера»); собери результат и сохрани slides.md в папку;
• (б) надиктовать сейчас — пользователь диктует содержание в чат, ты раскладываешь по слайдам и сохраняешь slides.md. Без текста слайдов деку не собрать — контент сам не выдумывай.

(B) Дизайн-бриф design.md. Есть → применяй по art-direction.md. Нет — предложи:

• (а) составить — 3-4 вопроса (вид/настроение/бренд-цвета/светлая-тёмная), собери и сохрани design.md в папку;
• (б) найти готовый — бесплатные источники (styles.refero.design, designmd.app + галереи — см. art-direction.md, все открытые/без подписок); положи выбранный бриф как design.md.

Заодно (советуй, не блокируй сборку):

• Недостающие ассеты: «здесь сильно зашла бы диаграмма/скриншот/hero — докинуть в папку или сделать без?»
• Недостающие факты/цифры: «нет чисел под слайд результатов — дай реальные или уберём».
• Неоднозначности: аудитория / хронометраж→число слайдов / тон — только если не выводятся из контента.
• Шрифты (если бриф держится на конкретном фейсе): вшить ли OSS-аналог base64 (останется офлайн) или системный заменитель (по умолчанию системный). Не спрашивай то, что уже есть в материалах. Как только slides.md и design.md существуют — к плану (Шаг 3).

Шаг 3 — План деки (показать, подтвердить) · только полный режим

Выведи список слайдов (для каждого: заголовок, что на экране, какая анимация/компонент, строка заметки) + одной фразой арт-дирекшн + какие слайды используют медиа + строку про интерактив. Спроси «Строим / правки». Не строй HTML до одобрения.

Интерактив — отдельным вопросом, и только если кандидаты нашлись (Шаг 1, ось 9). Один AskUserQuestion, мультивыбор, 2-4 варианта, сформулированных под ЭТОТ доклад — «слайд 07: слайдер нагрузки, цифра latency пересчитывается», а не «добавить интерактивность». Обязательный последний вариант — «оставить деку статичной». Что выбрали, то и делаешь; не выбрали ничего — дека статична. Кандидатов не было — вопроса нет, лишний шаг не изобретай.

Быстрый режим: плана на подтверждение нет — скажи одной строкой, сколько слайдов и какая арка, и сразу собирай. Интерактив в этом режиме не обсуждается: контент явно просит — сделай один виджет и скажи об этом в финале, не просит — дека статична.

Шаг 4 — Беспоук-сборка

Быстрый режим: собираешь ОДИН файл <slug>.html туда, куда сказал пользователь. Пункты 1-3 ниже работают как есть; пункт 4 — только inline base64 (медиа тяжелее ~800 КБ ломает однофайловость: предупреди и предложи либо ужать, либо перейти в полный режим); пункт 5 (notes.js) пропускается — заметки живут вшитыми в data-notes, presenter читает их и без файла. Черновики — в scratchpad сессии.

Полный режим: собираешь в подпапку deck/ рабочей папки (см. «Раскладка папки»); создай её, если нет. Способ сборки — как удобно: точечными Edit по копии kernel ИЛИ своим скриптом сборки. Пишешь скрипт — сохрани его в рабочую папку (не в scratchpad и не в deck/!) вместе с исходниками, из которых он собирает, и держи актуальным после любых правок (пересборка не должна откатывать деку); режим зафиксируй в DECK.md (Шаг 5).

1. Скопируй assets/kernel.html ЭТОГО скилла (из его каталога assets/) дословно как основу — весь <script id="kernel"> и chrome-DOM неизменны. Источник движка — ТОЛЬКО ассеты скилла. Если доклад про сам present и во входной папке лежит копия скилла (present/, чужой kernel.html, готовая *.html-дека) — это КОНТЕНТ/референс, а НЕ движок: НЕ копируй движок оттуда. Сомневаешься — сверь маркер KERNEL v6 в шапке свежескопированного файла. Вставляя CSS/слайды скриптом, матчь реальные блоки по их плейсхолдер-содержимому (<style id="design">\s*/\*…\*/\s*</style>, <div id="deck">\s*<!--…-->\s*</div>) — целостность потом подтвердит assets/validate.py (Шаг 5). Подставь реальный <title> вместо {{ЗАГОЛОВОК}}.

2. В <style id="design"> напиши авторский CSS под арт-дирекшн: палитра (:root), body/#bg, типографика (системные стеки ИЛИ вшитый base64 OSS-шрифт по согласию — рецепт в cookbook.md), компоненты, раскладки. Сверься с контрактом классов в cookbook.md — компоненты, которые оживляет kernel, обязаны получить свой CSS/keyframes (особенно @keyframes gitin для .clist).

3. В #deck уложи спроектированные слайды: одна мысль — один слайд, короткие заголовки, числа → .count, у КАЖДОГО <section> — data-notes с дословной речью (ремарки в [скобках]). Первый слайд — с классом active. Каждый слайд верстается под ЕГО мысль: kernel не требует никакой «типовой» структуры слайда, и многие слайды — просто крупная типографика или своя раскладка без именованных компонентов. Классы из контракта (cookbook.md) бери только тогда, когда мысль слайда действительно требует счётчика, каскада или схемы-процесса, — и помни, что дорогая анимация уместна один-два раза на всю деку. Композиция слайдов должна меняться по ходу деки (ось 1): три подряд одинаковых силуэта — брак.

4. Медиа (умный дефолт): лёгкое (< ~800 КБ) → inline base64 (дека остаётся одним офлайн-файлом); тяжёлое (> ~800 КБ, крупные GIF/видео) → sidecar-папка deck/deck-assets/ (относительная ссылка deck-assets/…) + предупреди, что дека больше не один файл и ездит только вместе со своей папкой. Исходные картинки из рабочей папки при этом не трогай — копируй, а не перемещай. 4б. Интерактив (если он в плане). Свой JS — в отдельный блок <script id="interactive"> ПОСЛЕ <script id="kernel">, перед закрывающим </body>; kernel по-прежнему не трогаешь. ⚠️ Вставляешь скриптом — матчь ПОСЛЕДНЕЕ вхождение (rfind/rsplit): первое лежит внутри kernel, в строке, которая собирает presenter-окно, и вставка туда ломает движок. Кликабельные зоны — <button> или своя вёрстка с [data-interactive], прокручиваемые — [data-scroll], иначе клик и колесо уйдут в навигацию. Сброс состояния при заходе на слайд, поведение в PDF, работа в presenter-превью, ремарка в data-notes — всё это на тебе: полный контракт и сниппеты в cookbook.md, раздел «Интерактивность: контракт с kernel». Виджет — один на слайд, и слайд обязан читаться, даже если по нему не нажали.

5. Сгенерируй файл живых заметок <slug>-notes.js рядом с декой, в той же deck/, из data-notes (имя = имя html-файла деки + -notes.js — kernel ищет его именно так):

   window.DECK_NOTES = String.raw`
   ## 01 · Заголовок слайда
   Текст заметки… [ремарки в скобках]
   `;
   

   Это и суфлёр для чтения (телефон/бумага), и живой источник: kernel перечитывает файл на лету — правки видны в presenter-окне без пересборки. Ключ секции — номер NN (совпадает с номером слайда), заголовок после · — для человека. В тексте заметок нельзя использовать бэктик и ${. data-notes в HTML остаются fallback-копией (дека работает и одним файлом). <slug>-notes.js — источник правды после первой генерации. Пользователь правит заметки прямо в presenter-окне (кнопка «✎ править») и выгружает файл кнопкой «⤓ notes.js» — там могут быть правки, которых нет в data-notes. Поэтому при любой пересборке/доводке сначала прочитай существующий notes.js и перенеси его текст в data-notes собираемой деки, а не перезаписывай файл из старых data-notes.

Шаг 5 — Проверка и показ

• Прогони валидатор: python3 <каталог скилла>/assets/validate.py <дека>.html — он проверяет целостность kernel (маркер KERNEL v6, base/print-стили, chrome, presenter, правку заметок, экспорт в PDF), остаточные {{…}}, сетевые ссылки и локальные ссылки на отсутствующие файлы, синтаксис JS (node --check по каждому блоку скрипта — kernel, interactive — и по notes.js), посторонние script-блоки и порядок interactive относительно kernel, интерактив на движке ниже v6, клик, повешенный ATTRIBUTE-обработчиком (onclick=…) на не-интерактивный тег, синхронность секций <slug>-notes.js со слайдами, наличие slides.md/design.md/DECK.md. Ошибки чини до показа. Одиночную деку быстрого режима валидатор узнаёт сам (лежит не в deck/, рядом ни одного файла комплекта) и комплекта с неё не спрашивает. Чего он НЕ ловит: сломанную логику виджета и клики, повешенные через addEventListener — их проверяешь руками, следующим пунктом.
• Визуальная самопроверка в Chrome (обязательный шаг). Деку смотришь ТЫ, а не пользователь: подними локальный сервер в deck/, открой вкладку, сними вердикт ?check и ошибки JS из консоли, войди в режим съёмки, прогони аудитор макета (ОДИН вызов на всю деку) и посмотри кадры глазами. Проверка стоит на двух опорах, обе обязательны: аудитор даёт числа (переполнение по эталону 16:9, вылет за кадр, битые картинки, мелкий кегль, обрезанный и наложенный текст, пустые слайды), кадры — то, что числами не берётся (контраст, ритм, композиция, «висячие» строки). Что нашёл — чини и переснимай, пока аудитор не замолчит, а кадры не станут чистыми. Третьим заходом — PDF: его печатную раскладку не видят ни ?check, ни аудитор, проверяется он headless-печатью из терминала (cookbook.md, п.9) и рендерится через qlmanage — тем же движком Quartz, которым его откроет зритель. Точная процедура со сниппетами — в cookbook.md, раздел «Визуальная самопроверка в Chrome». Четыре вещи, о которые спотыкаются: (1) file:// расширение не открывает (Can't interact with browser-internal or unparseable URLs) — только python3 -m http.server из папки deck/ и http://127.0.0.1:PORT/…; (2) окно браузера НЕ 16:9 и resize_window его не выправляет — переполнение меряй аудитором по эталону innerWidth/16*9, а не на глаз по скриншоту; окно с сильно непропорциональным ratio (вне 1.70–1.86) приводится к кадру 16:9 стендом из cookbook.md; (3) режим съёмки собирается ТОЛЬКО стилем shotmode из cookbook.md: самодельный animation:none снимет каскады и карточки ПУСТЫМИ (design-слой держит их на opacity:0 до анимации) и оставит копию фона поверх контента — пойдёшь чинить несуществующее; (4) S и ⌘P в этом режиме НЕ нажимай — системный диалог печати заблокирует расширение до ручного закрытия; PDF проверяется headless-печатью из терминала (cookbook.md, п.9), и это часть проверки, а не забота пользователя: ?check и аудитор печатную раскладку не видят вовсе. Смотреть страницы — через qlmanage (движок Quartz, как у Preview): pdftoppm рисует чистым даже тот PDF, который в Preview идёт серыми прямоугольниками. Расширения claude-in-chrome нет / Chrome недоступен → так и скажи и попроси пользователя открыть деку с ?check и пролистать глазами; молча пропускать проверку нельзя. Проверку PDF эта ветка не отменяет: headless-печати не нужны ни расширение, ни живая вкладка — только бинарь Chrome. Нет и его — скажи, что PDF не проверен.
• Интерактив проверяется руками, а не глазами (если он есть): в открытой вкладке нажми каждый виджет и убедись, что дека при этом НЕ пролистнулась, состояние изменилось видимо, а уход на соседний слайд и возврат оставляют виджет в осмысленном состоянии. Есть поле ввода — напечатай в него «psb» и проверь, что не открылись presenter/блэкаут/печать. Раскрывающийся блок проверь раскрытым на переполнение: раскрой его и прогони аудитор макета (cookbook.md, п.5) — он посчитает слайд в раскрытом состоянии. Дека на kernel ниже v6 интерактив не выдержит — движок надо обновить.
• Быстрый режим — проверка короче, но не мельче: валидатор, ?check, ошибки консоли, аудитор макета и headless-печать PDF обязательны ЦЕЛИКОМ — аудитор стоит один вызов на всю деку независимо от числа слайдов, экономить на нём нечего. Рационируются только кадры: титул + все слайды, которые пометил аудитор,
  • два-три самых плотных. Молча пропускать проверку нельзя и здесь.
• Ручная проверка (её делает пользователь, не ты): P открывает presenter отдельным окном (не вкладкой) и он синхронен, B гасит экран, живые заметки подхватываются.
• Быстрый режим на этом заканчивается: отдай путь к файлу, скажи, что это вся дека целиком (переслать = переслать один файл), и напомни управление. DECK.md, deck/ и проверку раскладки пропусти — их нет. Пункты ниже — полный режим.
• Сгенерируй DECK.md в рабочей папке (не в deck/) по assets/deck-template.md: режим деки (скрипт/руками), карта слайдов, арт-дирекшн сжато, принятые решения/отступления с «почему», как править. Собирал скриптом — проверь, что скрипт и его исходники лежат в рабочей папке рядом с DECK.md.
• Проверь раскладку: в deck/ — только HTML, его notes.js и (если есть) deck-assets/; ничего постороннего туда не попало, а исходники и материалы остались в рабочей папке нетронутыми.
• Дека — в deck/<slug>-<дата>.html. Открой: open deck/<файл> (macOS). Скажи пользователю прямо: чтобы унести доклад — берётся папка deck/ целиком (архив, флешка, другой ноутбук), выбирать файлы не надо.
• Напомни управление: ← →/колесо/свайп — листать, P — presenter-окно с заметками (его НЕ шарить, шарить деку), B — чёрный экран, F — fullscreen, S — сохранить деку в PDF. Позиция хранится в #хэше — F5 не собьёт слайд. Правка заметок прямо в presenter-окне — кнопками мышью (буквенных хоткеев там намеренно нет: в это окно печатают; из клавиш живут только стрелки, Esc и ⌘⏎): «✎ править» или двойной клик по тексту → «✓ применить», «☰ все заметки» — весь текст разом, «↺ откатить» — выбросить свои правки и вернуться к файлу (передумал — плашка вернёт их), «⤓ notes.js» — выгрузить файл в загрузки, «⧉ копировать» — его текст в буфер. Из file:// браузер писать на диск не умеет, поэтому правки живут черновиком в браузере (переживают F5, индикатор ✎ черновик в шапке presenter), а на диск переносятся выгруженным файлом — положить его рядом с декой поверх старого, индикатор снова зазеленеет. Всё это объясняет встроенная справка в окне докладчика: кнопка «? справка» (при первом открытии presenter внизу всплывает подсказка про неё) — отдельно расписывать пользователю каждую кнопку не нужно. Альтернатива прежняя: править <slug>-notes.js во внешнем редакторе — presenter подхватит за пару секунд (файл главнее черновика; несохранённые правки не пропадут — presenter предложит их вернуть). Пересылать деку можно одним HTML (вшитые заметки-fallback), но выступать — из папки deck/, рядом с notes.js.
• Просят PDF — клавиша S в открытой деке (то же и по ⌘P): kernel замораживает ВСЕ слайды в финальном кадре (счётчики досчитаны, каскады/цепочки/pipeline показаны, печатный текст напечатан, фон разложен по страницам) и открывает диалог печати → выбрать «Сохранить как PDF». Страница 16:9 (13.333×7.5″) без полей, слайд = страница, цвета/фон/картинки печатаются, текст в PDF остаётся текстом. Нюансы, о которых предупреди: sidecar-GIF даёт первый кадр, а дека должна лежать рядом со своей deck-assets/; слайд с переполнением обрежется по краю страницы — сперва прогони ?check; если браузер всё же напечатал белым, включи в диалоге «Фоновая графика». Проверено в Chrome; из Safari результат сверь глазами. Тени в PDF плоские намеренно: размытую тень Chrome пишет растровой маской, которую Preview рисует серым прямоугольником поверх контента, поэтому kernel на время печати меняет её на тонкую обводку того же цвета (на экране всё возвращается). Мины печати целиком — cookbook.md, п.9.

Шаг 6 — Доводка

Предложи покрутить: палитру/плотность/движение, трактовку фона, добавить/убрать слайд, тайминги. Перед любой правкой перечитай <slug>-notes.js — пользователь мог поправить заметки в presenter-окне и выгрузить файл; эти правки переносятся в data-notes, а не затираются старым текстом из HTML. Сначала определи режим деки (по DECK.md / наличию скрипта сборки): режим «скрипт» → правь ИСХОДНИКИ и пересобирай, готовый HTML руками не трогай, скрипт держи актуальным; режим «руками» → точечный Edit — только в <style id="design"> и #deck, не трогая kernel. Добавил/убрал слайды — перенумеруй секции в <slug>-notes.js (он источник правды для заметок; data-notes в HTML обнови как fallback). Пересобранная дека кладётся в ту же deck/ — не плоди копии в рабочей папке и не оставляй в deck/ старые html/notes от прошлых сборок. После правок — снова визуальная самопроверка в Chrome (Шаг 5): аудитор макета гоняется на всю деку целиком (это один вызов), кадры переснимаются для затронутых слайдов, а если менял палитру/типографику/плотность — для всей деки; правка вёрстки вслепую и есть основной источник переполнений. После правок обнови DECK.md (карту слайдов и раздел решений), если менял структуру/анимации/тайминги. Есть интерактив — он тоже предмет доводки (что нажимается, насколько крупно, что происходит), и после любой правки его перещёлкивают заново: сломанный виджет валидатор не поймает. В быстром режиме доводка идёт по тому же одному файлу — папку и комплект не заводи, пока пользователь не попросит раскрутку.

Продолжить работу над готовой декой

Дали путь к *.html (маркер KERNEL v в шапке) и промт, что доделать, — это не новый доклад, а продолжение. Ничего служебного в деку не вшито и искать нечего: дека сама себе контекст. Прочитай её:

• текст слайдов — секции <section class="slide"> в #deck;
• речь спикера — data-notes у секций (если рядом лежит <slug>-notes.js — он главнее, читай его);
• арт-дирекшн — <style id="design">: палитра :root, типографика, композиционные классы;
• версию движка — маркер KERNEL v в шапке; рядом может лежать DECK.md — тогда он главный источник решений.

Дальше — по тому, что просят:

• точечная доводка («поменяй палитру», «добавь слайд», «перепиши третий») — правишь тот же файл по Шагу 6, режим и раскладку не меняешь;
• раскрутка до доклада — спроси, где создать рабочую папку, и разверни комплект: восстанови slides.md из вёрстки и заметок, добери design.md (интервью по Шагу 2 или зафиксируй уже сложившийся арт-дирекшн деки как бриф), перенеси деку в deck/, сгенерируй <slug>-notes.js из data-notes, создай DECK.md. Затем обычная доводка.

Движок старый. Дека собрана на kernel ниже v6, а в неё добавляют интерактив — в старом движке нет guard'ов, и виджет будет драться с навигацией. Скажи это прямо и перенеси слайды с design-слоем в свежий assets/kernel.html; без интерактива старую деку трогать незачем.

Стиль общения

• Язык: русский. Кратко между вопросами.
• Не выдумывай факты/цифры — бери из материалов или спрашивай. Из сети — только опц. URL-референс и OSS-шрифт по согласию.