Skills вместо промптов

Иллюстрация. Skills становятся активом компании, когда у них есть владелец, ревью и понятный путь публикации.

Первые пользователи ИИ почти всегда начинают с промптов.

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

Все это полезно.

Но для компании промпт — слишком слабая единица управления.

Промпт помогает одному человеку получить ответ в одном диалоге. Skill помогает компании воспроизводить хороший способ работы.

Это различие принципиально.

Если руководитель путает skill с промптом, он получает набор личных подсказок. Если понимает skill как рабочий протокол, он начинает строить новый слой операционной системы компании.

Почему промпта недостаточно

Промпт обычно отвечает на вопрос: что попросить у модели?

Например:

• «Проанализируй договор и найди риски»;
• «Подготовь письмо клиенту после встречи»;
• «Составь план проекта».

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

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

Промпт не отвечает на ключевые вопросы:

• кто владелец результата;
• какие данные можно использовать;
• где source of truth;
• какие поля нужно проверить;
• какие обещания нельзя давать;
• какие действия запрещены без человека;
• какой формат результата нужен;
• где сохраняется итог;
• как улучшить процесс после ошибки.

Поэтому промпт может быть частью skill, но не заменяет его.

Skill как рабочий протокол

Skill — это описанный способ выполнения повторяемой задачи с помощью ассистента.

Он соединяет человека, ассистента, данные, правила качества и контроль.

Хороший skill похож на рабочий договор внутри компании:

• что мы делаем;
• для какой роли;
• какие входы нужны;
• где брать правду;
• что можно и нельзя делать;
• как выглядит хороший результат;
• где человек проверяет;
• что сохраняется после выполнения.

Skill нужен не модели. Skill нужен компании.

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

Когда skill описан, его можно:

• дать новому сотруднику;
• встроить в ассистента;
• проверить на тестовых сценариях;
• улучшить после ошибок;
• передать другой команде;
• адаптировать под закрытый контур;
• использовать с разными моделями и агентными средами.

Именно поэтому skills становятся новым организационным слоем.

Из чего состоит хороший skill

Минимальная структура skill выглядит так:

• название: короткое имя задачи;
• для кого: роль или группа ролей;
• задача: какой результат нужно получить;
• когда использовать: ситуации, где skill применим;
• входы: какие данные нужны ассистенту;
• source of truth: где лежат актуальные факты;
• действия ассистента: что ассистент делает по шагам;
• правила качества: как проверить результат;
• ограничения: что нельзя делать;
• граница человека: где ассистент обязан остановиться;
• результат: формат выхода;
• память: что нужно сохранить после работы.

Эта структура кажется длинной только в первый раз.

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

Skill делает неявную работу явной.

Пример: skill для счета

Возьмем простой документ — счет.

Наивный промпт: «Сделай счет для клиента».

Такой запрос опасен. Ассистент может перепутать реквизиты, сумму, НДС, договор, номер счета, получателя, дату или основание платежа.

Skill должен быть устроен иначе.

• Название: подготовка черновика счета.
• Для кого: финансовый менеджер, аккаунт-менеджер.
• Задача: подготовить черновик счета на оплату по согласованным данным.
• Когда использовать: когда условия сделки согласованы и нужно подготовить счет для проверки человеком.

Входы:

• название клиента;
• договор или основание платежа;
• сумма;
• валюта;
• ставка НДС;
• услуга или товар;
• период оказания услуги;
• реквизиты клиента, если они не подтягиваются автоматически.

Source of truth:

• карточка клиента;
• реестр реквизитов;
• договор;
• актуальный шаблон счета;
• учетная система или согласованная выгрузка.

Действия ассистента:

• проверить полноту входных данных;
• подсветить отсутствующие поля;
• сверить реквизиты с source of truth;
• подготовить черновик счета;
• выделить поля, требующие проверки человеком.

Правила качества:

• не придумывать реквизиты;
• не менять сумму без подтверждения;
• не выбирать ставку НДС самостоятельно, если она не указана;
• показывать источник реквизитов;
• отмечать все допущения.

Ограничения:

• ассистент не выставляет счет в учетной системе и не отправляет его клиенту.

Граница человека:

• финансовый менеджер проверяет сумму, реквизиты, НДС и основание платежа.

Результат: черновик счета и список полей для проверки.

Такой skill помогает финансовому менеджеру убрать ручную подготовку и снизить риск пропущенных полей.

Пример: skill для протокола встречи

Другой частый сценарий — протокол встречи.

Наивный промпт: «Сделай summary встречи».

На выходе получится текст, но не обязательно управленческий артефакт.

Skill должен задавать структуру.

• Название: протокол встречи и контроль договоренностей.
• Для кого: руководитель проекта, продавец, аккаунт-менеджер, руководитель отдела.
• Задача: превратить запись или заметки встречи в управляемый протокол.

Входы:

• транскрипт встречи;
• список участников;
• цель встречи;
• проект или клиент;
• предыдущие договоренности, если доступны.

Source of truth:

• карточка проекта или клиента;
• предыдущие протоколы;
• список задач;
• календарь;
• решения, уже зафиксированные в базе знаний.

Действия ассистента:

• выделить принятые решения;
• отделить решения от обсуждений;
• собрать открытые вопросы;
• определить ответственных;
• предложить задачи;
• подготовить follow-up письмо.

Правила качества:

• не превращать спорные обсуждения в решения;
• явно помечать неуверенные места;
• не назначать ответственного, если он не прозвучал;
• отделять факты от интерпретаций.

Граница человека: владелец встречи утверждает решения, ответственных и сроки.

Результат: протокол, список задач, список открытых вопросов, черновик follow-up.

Такой skill важен не потому, что экономит время на пересказе. Он превращает встречу в управляемое действие: решения, ответственные, сроки и память компании.

Кто должен создавать skills

Skills не должны создаваться только технической командой.

Техническая команда может помочь оформить, встроить, подключить source of truth, настроить MCP, права и проверку. Но содержание skill должно приходить от владельцев роли.

Лучшие авторы первых skills:

• сильные сотрудники, у которых уже есть рабочая практика;
• руководители функций, отвечающие за качество результата;
• методологи или операционные руководители;
• технические специалисты, если skill связан с кодом или инфраструктурой;
• служба безопасности и юристы, если есть чувствительные данные или внешние действия.

Skill создается на пересечении трех знаний:

1. профессиональное знание роли;
2. знание данных и систем;
3. знание возможностей и ограничений ассистента.

Если убрать первое, получится технически красивый, но бесполезный skill.

Если убрать второе, ассистент будет гадать.

Если убрать третье, skill будет требовать от модели невозможного.

Жизненный цикл skill

Skill не пишется один раз навсегда.

Он проходит жизненный цикл.

Сначала появляется личная практика. Один сотрудник находит хороший способ работать с ассистентом.

Потом практика описывается как черновик skill.

Затем skill проверяется на нескольких реальных или тестовых сценариях.

После проверки добавляются правила качества, ограничения и примеры.

Потом skill передается другим сотрудникам.

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

После этого skill улучшается.

Так компания превращает работу с ИИ в накопление организационного знания.

Это важный момент.

В обычном режиме каждый сотрудник улучшает свой личный способ общения с моделью. В AI-Native режиме компания улучшает общий skill.

Как проверять skill

Skill без проверки качества быстро превращается в красивый документ.

Минимальная проверка должна отвечать на несколько вопросов:

• дает ли skill стабильный результат на разных примерах;
• понятно ли сотруднику, когда его использовать;
• хватает ли входных данных;
• не требует ли skill доступа к данным, которых у роли нет;
• видит ли ассистент source of truth;
• не делает ли ассистент запрещенных выводов;
• понятно ли, где решение принимает человек;
• сокращает ли skill время работы;
• повышает ли качество результата.

Для проверки полезно собрать небольшой набор тестовых сценариев.

Например, для skill «подготовка счета»:

• обычный счет с полными данными;
• счет с неполными реквизитами;
• счет с нестандартной ставкой НДС;
• счет по старому договору;
• счет, где клиент изменил реквизиты;
• счет, где сумма не совпадает с договоренностью.

Если skill проходит только идеальный сценарий, он еще не готов для работы.

Ошибки при создании skills

Первая ошибка — писать skill как длинный промпт.

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

Вторая ошибка — не указывать source of truth.

Ассистенту говорят «проверь договор», но не дают актуальный шаблон, список запрещенных условий, историю согласований и правила компании.

Третья ошибка — не задавать границу человека.

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

Четвертая ошибка — не описывать плохие случаи.

Многие skills пишутся под идеальный сценарий. Но ценность появляется именно там, где данные неполные, источник противоречивый, клиент просит нестандартное условие или модель не уверена.

Пятая ошибка — не назначать владельца.

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

Skills как библиотека компании

Со временем у компании появляется библиотека skills.

Она может быть устроена по ролям:

• skills продавца;
• skills руководителя проекта;
• skills инженера;
• skills юриста;
• skills финансиста;
• skills закупщика;
• skills руководителя.

Или по процессам:

• входящий запрос;
• коммерческое предложение;
• договор;
• встреча;
• счет;
• проектный статус;
• разработка задачи;
• тендер;
• закупочные переговоры.

Главное, чтобы библиотека не превращалась в кладбище инструкций.

У каждого skill должен быть владелец, версия, дата обновления, примеры использования, правила качества и связь с source of truth.

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

Что сделать руководителю

Выберите одну сильную личную практику в компании.

Например:

• как лучший продавец готовится к встрече;
• как опытный юрист проверяет договор;
• как сильный руководитель проекта готовит статус;
• как инженер описывает задачу для ассистента;
• как закупщик готовится к переговорам;
• как финансист проверяет счет.

Не пытайтесь сразу автоматизировать процесс.

Сначала опишите практику как skill:

1. Для какой роли?
2. Какой результат?
3. Какие входы?
4. Где source of truth?
5. Что делает ассистент?
6. Какие правила качества?
7. Где граница человека?
8. Какой результат должен остаться?
9. Кто владелец skill?
10. Как будем проверять, что skill работает?

После этого протестируйте skill на трех-пяти реальных примерах.

Если он помогает автору и другим сотрудникам, вы начали превращать личное мастерство в актив компании.

Вопросы для руководителя

• Какие удачные промпты в компании на самом деле должны стать skills?
• Где сильные сотрудники уже имеют личные рабочие протоколы, но они не оформлены?
• Какие skills нужны первой волне AI-Native внедрения?
• Кто будет владельцем каждого skill?
• Где находится source of truth для каждого skill?
• Как вы будете проверять качество skill?
• Как skill будет обновляться после ошибок?

Главная мысль главы

Промпт помогает одному человеку поговорить с моделью.

Skill помогает компании воспроизводить хороший способ работы.

Если компания хочет получить от ИИ системный эффект, ей нужна библиотека skills: с владельцами, source of truth, правилами качества, ограничениями, примерами и проверкой.

Именно skills превращают личные находки сотрудников в операционное знание компании.