Presentation Storyteller: продающая презентация, которую можно защитить

Привет! Этот курс — про пакет @dzhechkov/skills-presentation-storyteller: набор навыков для Claude Code, который превращает просьбу «сделай продающую презентацию» в готовые файлы и в речь, которую ты произнесёшь со сцены.

Знакомься: Мира. Ты уже видел её в курсах по harness-cli и feature-adr — там она осваивала команды и вела первую функцию через конвейер. Сегодня задача другая: через неделю ей выступать перед заказчиком, и от этих двадцати минут зависит контракт. Слайды Мира делала и раньше — и каждый раз спотыкалась об один и тот же вопрос из зала: «а откуда цифра?»

Пакет отвечает на этот вопрос заранее. Он собирает три артефакта презентации:
1. presentation-outline.md — план: по одному тезису на каждый слайд;
2. presentation-full.md — полная презентация в Markdown, где рядом с каждым фактом стоит ссылка на источник;
3. sources-index.md — индекс всех проверенных источников.

Сверх этого — подстрочник «Как рассказывать?»: живая речь на каждый слайд, с паузами, переходами и заготовками ответов на возражения.

Исходники и публичное зеркало: github.com/djd1m/dz-harness.

Компромиссы: ты получаешь презентацию, каждую цифру которой можно защитить в споре, но платишь временем на исследование — черновик «на коленке» за пять минут так не собрать.

💬 Просто попроси.
- «Расскажи, что делает пакет presentation-storyteller» → ассистент откроет README пакета и перескажет раздел What It Does.
- «Сделай продающую презентацию про наш сервис онбординга» → ассистент запустит навык и начнёт не со слайдов, а с уточняющих вопросов о задаче.

Прежде чем вызывать навык, его надо положить в проект. Установка набора в проект идёт одной командой, без глобальных пакетов и без правки конфигов:

npx @dzhechkov/skills-presentation-storyteller init

Мира выполняет её в корне своего репозитория. Вот что там появляется:
- .claude/skills/presentation-storyteller/ — сам навык вместе со справочниками по аркам, типам слайдов и речевым приёмам;
- .claude/skills/explore/ — навык уточнения задачи;
- .claude/skills/goap-research-ed25519/ — навык исследования с проверкой источников;
- .claude/commands/presentation-storyteller.md — команда /presentation-storyteller.

Дальше в Claude Code достаточно написать /presentation-storyteller питч для сервиса онбординга на ИИ — и запустится первая фаза.

Если у тебя уже стоит @dzhechkov/harness-cli, тот же набор ставится через него: dz init --select presentation-storyteller, а dz info presentation-storyteller покажет состав. Это удобство, а не требование: пакет самодостаточен.

Компромиссы: установка кладёт файлы прямо в репозиторий проекта — это видно в git и требует решения, коммитить их или держать локально; зато навык всегда рядом с кодом и не зависит от глобального окружения машины.

💬 Просто попроси.
- «Поставь набор presentation-storyteller в этот проект» → ассистент выполнит npx @dzhechkov/skills-presentation-storyteller init и покажет, какие файлы появились.
- «Что за файлы появились в .claude после установки?» → ассистент перечислит навыки и слэш-команду и объяснит роль каждого.

Мира привыкла, что «сделай презентацию» сразу превращается в слайды. Здесь не так. Четыре фазы конвейера презентации идут строго по порядку, и каждая следующая опирается на выход предыдущей.

1. Explore — бриф. Кто в зале, какое действие нужно после выступления, сколько минут, что нельзя говорить.
2. Research — источники. Рынок, конкуренты, подтверждение болей, доказательства решения, регуляторика, экспертные мнения.
3. Structure — арка и план. Выбор повествовательной арки под цель, разбивка на блоки, тезис на каждый слайд, хронометраж.
4. Content — слайды и подстрочник. Полный текст слайдов со ссылками плюс речь спикера.

Между фазами стоят три остановки — после брифа, после исследования и после плана. На каждой ты подтверждаешь результат, прежде чем навык потратит силы на следующую фазу. Смысл остановок простой: ошибка в брифе стоит одну минуту, а та же ошибка, обнаруженная на готовых слайдах, стоит всю работу.

Компромиссы: порядок фаз дисциплинирует и отсекает «слайды ради слайдов», но три остановки означают, что полностью без человека набор не отработает — это осознанный выбор в пользу управляемости.

💬 Просто попроси.
- «Покажи план работы по презентации, прежде чем писать слайды» → ассистент остановится после фазы структуры и покажет план с тезисами по каждому слайду.
- «Бриф подтверждаю, иди дальше» → ассистент перейдёт к фазе исследования источников.

Первая фаза называется explore, и её девиз — «никогда не решай, пока не понял». Мира приносит одну строчку: «расскажи про нашу платформу, минут на двадцать». Из неё ничего не сделать: непонятно, кому рассказывать и зачем.

Бриф презентации собирается по шести измерениям:
- Аудитория — кто в зале: роли, уровень, боли. Что они уже знают?
- Цель — что слушатели должны *сделать* после выступления. Не «понять», а действие: подписать пилот, выделить бюджет, назначить встречу.
- Контекст — где выступление: конференция, разговор один на один, вебинар. Что было до и что будет после?
- Хронометраж — сколько минут и есть ли вопросы из зала.
- Ограничения — запретные темы, обязательные темы, корпоративный стиль.
- Критерий успеха — по чему поймём, что выступление удалось.

Почему цель обязана быть действием. «Чтобы они поняли, какие мы молодцы» — это состояние в чужой голове, его нельзя проверить. «Чтобы технический директор согласился на двухнедельный пилот» — это событие, которое либо произошло, либо нет. Проверяемая цель задаёт и последний слайд, и всю арку до него.

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

💬 Просто попроси.
- «Задай мне вопросы по будущей презентации» → ассистент проведёт фазу explore и соберёт бриф.
- «Цель — чтобы заказчик согласился на пилот на две недели» → ассистент зафиксирует цель как действие и подстроит под неё финальный слайд.

Вторая фаза — исследование. Мира ищет не «что-нибудь красивое», а шесть заранее названных вещей: размер рынка, что делают конкуренты, подтверждение болей цифрами, доказательства решения (кейсы, ROI, бенчмарки), регуляторный контекст и экспертные мнения.

Ключевая идея фазы — минимум источников на тип факта. Планка зависит от природы самого утверждения:

• Статистика — два источника: отраслевые отчёты, государственные данные, исследовательские фирмы.
• Размер рынка — два источника: Gartner, IDC, McKinsey, локальные аналитики.
• Регуляторика — достаточно одного, но обязательно официального государственного.
• Технические утверждения — два: документация производителя, бенчмарки, академические работы.
• Кейс клиента — один, но с названной компанией и конкретными метриками.

Почему у регуляторики планка ниже, а не выше. У закона есть единственный официальный держатель текста; второй пересказ не добавляет достоверности, он добавляет шум. У рыночной цифры держателя нет — каждый аналитик считает по-своему, поэтому две независимые оценки показывают разброс, а одна выдаёт мнение за факт.

Отдельное правило: у статистики есть срок годности. Цифра старше двух лет требует пометки о дате — Мира ставит её прямо в слайд, а не прячет в индекс источников.

Компромиссы: планка отсекает эффектные, но неподтверждаемые цифры и делает исследование дольше; зато ни один вопрос «откуда это?» не застаёт врасплох.

💬 Просто попроси.
- «Найди подтверждение этой цифре из двух независимых источников» → ассистент проведёт поиск и покажет обе ссылки.
- «Проверь, не устарела ли статистика на четвёртом слайде» → ассистент сверит дату публикации и предложит пометку или замену.

Дальше — самое неочевидное место набора, и в нём стоит разобраться один раз навсегда.

У навыка исследования две независимые оси проверки источника.

Ось первая — доверие к записи (подпись Ed25519). Ed25519 — это способ поставить под текстом криптографическую подпись: любой может убедиться, что подписанные байты не менялись после подписи. Классы: ISSUER_SIGNED — подпись сходится с закреплённым ключом заявленного издателя (потолок уверенности 0.95); SELF_ATTESTED — исследователь подписал сам себя, это защита журнала от подделки задним числом (потолок 0.60); UNVERIFIED — неизвестный издатель, отозванный ключ или битая подпись (0.0).

Ось вторая — доказательность (открывал ли кто-нибудь ссылку). FETCH_VERIFIED — скрипт реально сходил по адресу и получил тело ответа, зафиксировав его хеш и дату (потолок 1.0); LISTING_ONLY — адрес известен из перечня, но никто по нему не ходил (потолок 0.50); ASSERTED — сказано по памяти, источник не открывали (0.0).

Зачем две оси, а не одна. Первая отвечает на вопрос «не подменили ли запись», вторая — «а читал ли её вообще кто-нибудь». Опасное сочетание видно, только когда осей две: факт может быть безупречно подписан и при этом ASSERTED — то есть криптографически идеальная запись выдумки. Одна ось такое состояние скрыла бы.

Итоговая уверенность = минимум по всем потолкам, не среднее. Слабое звено решает: подписанный факт, который никто не открывал, стоит ноль. Третий потолок задаёт класс домена: A — 0.90, B — 0.80, C — 0.60, D — 0.40 для всего остального.

Мира запомнила это так: подпись говорит «текст не подменили», доказательность — «текст открывали», и ни то, ни другое не говорит «текст верен».

Компромиссы: две оси дают честную картину и делают состояние «красиво подписанная выдумка» видимым, но требуют привыкнуть к тому, что уверенность считается по худшему звену, а не по лучшему.

💬 Просто попроси.
- «Покажи, какие факты в презентации никто не открывал» → ассистент отберёт утверждения класса LISTING_ONLY и ASSERTED.
- «Объясни, почему у этого факта уверенность ноль, он же подписан» → ассистент разберёт обе оси и назовёт слабое звено.

Классы доказательности из прошлого раздела были бы вежливым пожеланием, если бы их никто не проверял. Поэтому в наборе есть гейт отчёта по классам доказательности — небольшой скрипт, который читает готовый текст вместе с журналом фактов и выносит вердикт кодом возврата:

python3 scripts/check_report_evidence.py --report report.md --facts facts.json

Что он требует:
1. Утверждения класса ASSERTED — сказанные по памяти — не должны попадать в отчёт вообще.
2. Утверждения класса LISTING_ONLY попадают только с видимым маркером рядом с самим утверждением: «источник напрямую не открывался — проверьте».
3. Нарушение — это код возврата 1, а не примечание мелким шрифтом.

Отдельно про код возврата 2. Так гейт сообщает, что не смог прочитать входные данные. Это не «всё хорошо» — это «проверка не состоялась». Гейт, который не смог выполниться, ничего не подтвердил, и различать эти два случая обязательно: молчание прибора легко принять за зелёный свет.

Мира держит в голове простое правило: отсутствие жалобы — не доказательство. Зелёный вердикт означает ровно то, что перечислено в трёх пунктах выше, и ничего сверх.

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

💬 Просто попроси.
- «Прогони проверку отчёта перед тем, как я отправлю презентацию» → ассистент запустит гейт и покажет код возврата вместе с нарушениями.
- «Найди утверждения без открытого источника и пометь их» → ассистент отберёт факты LISTING_ONLY и расставит видимые маркеры.

Факты собраны — пора решать, в каком порядке их произносить. Здесь набор не отдаёт выбор на волю вкуса: арка повествования под цель подбирается по таблице, а не по настроению.

Пять рамок и их назначение:
- AIDA — продать продукт: внимание → интерес → желание → действие.
- Путь героя — поменять взгляд аудитории: как было → вызов → превращение → новый мир.
- Проблема-Решение — объяснить сложное: боль → причина → решение → доказательство → призыв.
- Мотивационная последовательность Монро — побудить к действию: внимание → потребность → удовлетворение → картина будущего → действие.
- Пирамида Минто — техническое решение: ответ сразу, затем аргументы, затем детали.

Почему рамка выводится из цели, а не выбирается по вкусу. Каждая арка задаёт, где в выступлении находится точка наибольшего напряжения. У AIDA она в начале — иначе внимание не удержать. У пирамиды Минто её нет вовсе: ответ звучит первым, потому что технический руководитель не станет ждать развязки. Возьмёшь арку не под ту цель — и напряжение окажется не там, где нужно залу.

Поверх арки ложатся типы слайдов: титульный (обещание), повестка, проблема, решение, продукт, доказательство, сравнение, призыв к действию, контакты. Каждый тип превращается в конкретный слайд с тезисом — это и есть выход третьей фазы, файл presentation-outline.md, который Мира показывает заказчику до того, как написан хоть один полный слайд.

Компромиссы: готовые рамки экономят часы и защищают от бессвязного набора слайдов, но выступление в чужой рамке звучит шаблонно — арку стоит осознанно подстроить под свой голос.

💬 Просто попроси.
- «Цель — продать пилот, подбери арку и покажи план слайдов» → ассистент выберет AIDA и выдаст план слайдов с тезисами.
- «Перестрой презентацию под пирамиду Минто, слушатели технические» → ассистент вынесет ответ на первый слайд и переупорядочит остальные.

Здесь набор расходится с обычным генератором слайдов. Кроме содержания он выдаёт подстрочник спикера на каждый слайд — то, что человек произносит вслух, стоя перед залом.

Мира однажды сделала безупречную презентацию и провалила выступление: она читала слайды. Подстрочник существует ровно против этого.

Что в нём делают:
- начинают с вопроса, истории, неожиданной цифры или смелого утверждения — но не со слов «на этом слайде вы видите»;
- говорят «вы» и «мы», а не «компания предлагает»;
- ставят пометки пауз прямо в текст: после ключевой цифры зал должен успеть её осознать;
- заканчивают слайд фразой-переходом к следующему;
- закрывают блок коротким резюме.

Чего не делают: не читают слайд вслух, не произносят «как вы видите на слайде», не сыплют цифрами подряд, не извиняются («извините за мелкий шрифт») и не заканчивают выступление словом «вопросы?».

Как проверить, что выступление влезает в хронометраж. Темп речи — примерно 130 слов в минуту. Значит, подстрочник на двадцать минут — это около 2600 слов, и посчитать их можно до репетиции, а не после. Ориентир по объёму: питч на 10 минут — 8–12 слайдов, стандартные 20 минут — 15–20 слайдов.

Компромиссы: написанная речь снимает страх пустоты и держит хронометраж, но выученный наизусть текст звучит механически — подстрочник задуман как опора, а не как суфлёр.

💬 Просто попроси.
- «Напиши, как рассказывать четвёртый слайд, у меня на него полторы минуты» → ассистент выдаст речь нужного объёма с паузами и переходом.
- «Придумай начало посильнее — сейчас слайд открывается словами „здесь мы видим“» → ассистент заменит открытие на вопрос, историю или неожиданную цифру.

Этот раздел выглядит как сноска мелким шрифтом — и именно поэтому он здесь. Мира дважды теряла полдня на «навык почему-то не срабатывает», хотя причина была одна: файлы в проекте разъехались после ручной правки.

У пакета пять команд жизненного цикла:
- init — установка (действие по умолчанию);
- update — обновить установленные файлы до версии пакета;
- remove — удалить установленное;
- list — показать, что именно установлено;
- doctor — диагностика.

Команда doctor проверяет набор на целостность: все ли файлы из манифеста на месте, лежит ли каталог навыка там, где его ищет Claude Code, цел ли SKILL.md. По каждой неудачной проверке она печатает не только диагноз, но и способ починки — обычно это update.

Флаги общие: --force перезаписывает существующие файлы, --dry-run показывает, что произошло бы, ничего не меняя, --help и --version — справка и версия.

Почему это не мелочь. Первое подозрение при странном поведении навыка — не модель и не формулировка запроса, а состав файлов на диске. Диагностика стоит секунду и снимает половину гипотез; догадки стоят часы.

Компромиссы: проверка отвечает на вопрос «файлы на месте и целы», но не на вопрос «навык даст хороший результат» — качество ответа она не измеряет и не обещает.

💬 Просто попроси.
- «Проверь, всё ли на месте с набором presentation-storyteller» → ассистент запустит doctor и разберёт каждую неудачную проверку.
- «Обнови навыки до последней версии, но сначала покажи, что изменится» → ассистент сделает прогон update с --dry-run.

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

Границы применимости пакета:

1. Он не рисует слайды. На выходе Markdown: содержание, ссылки и речь. Перевод в презентационный формат — отдельный шаг отдельным инструментом.
2. Подпись — не истина. Ed25519 доказывает, что байты не подменили. Класс FETCH_VERIFIED доказывает, что байты пришли. Ни то, ни другое не доказывает, что источник прав, что вывод следует из текста и что читавший понял прочитанное.
3. Гейт проверяет происхождение, а не смысл. Уместность цифры, честность сравнения с конкурентом, реалистичность обещания — это твои решения, и никакая проверка их не примет за тебя.
4. Навыки explore и goap-research-ed25519 — отслеживаемые копии. Канонические версии живут в @dzhechkov/skills-analyst-manual; расхождение чинится командой dz sync-upstream. Канонический артефакт этого пакета — сам presentation-storyteller.
5. Самообучение исследования — необязательное. Оно включается, только если dz доступен в PATH, и уроки уходят в отдельное хранилище. Без dz навык работает как раньше и сообщает об этом один раз.
6. Подпись пакета описывает ровно то, что уезжает в опубликованный архив. В этом релизе манифест приведён в соответствие со списком публикуемых файлов: раньше он подписывал и то, что в архив не попадало, и у каждого получателя проверка честно ругалась на «отсутствующий файл». Содержимое не менялось — изменилось описание.

Компромиссы: такой честный список ограничений уменьшает соблазн доверять инструменту слепо, но требует от тебя держать в голове, где кончается машина и начинается твоё суждение.

💬 Просто попроси.
- «Что этот набор точно не сделает за меня?» → ассистент перечислит границы применимости и предложит, чем закрыть каждую.
- «Синхронизируй скопированные навыки с каноническими версиями» → ассистент проверит расхождение и запустит dz sync-upstream.