#мнение
Место менеджмента AI-native оргструктуре
Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний
Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает:
1. Экономика
AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения
2. Таланты и новые роли
AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения
Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности
3. Структура команд
Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы
Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца
4. Операционная модель
Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже
5. Управление и контекст
Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными
6. Проджект-функция
Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми
Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь
Место менеджмента AI-native оргструктуре
Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний
Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает:
1. Экономика
AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения
2. Таланты и новые роли
AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения
Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности
3. Структура команд
Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы
Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца
4. Операционная модель
Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже
5. Управление и контекст
Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными
6. Проджект-функция
Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми
Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь
YouTube
A leader’s guide to advanced team structures in an agentic world | AWS Events
As AI agents transform the workplace, organizations must adapt their structures and methodologies to harness new opportunities. The probabilistic nature of AI requires continuous iteration and intelligent oversight, creating new ways of working across business…
🔥5👎2
Всем привет!
Напоминаю, в рамках AI Engineers Guild x Bereke Bank делаем сегодня в 18:30 по Алматы состоится Agentic Harness Meetup: что под капотом.
💻 Онлайн: если не успели зарегистрироваться, присоединяйтесь по ссылке
📍 Офлайн: если вы проходили офлайн-регистрацию, ждём вас, адрес вы знаете https://luma.com/48q2s0f5
Сегодня обсудим:
▪️ Павел Королев -> как кастомизировать AI-агентов под реальные инженерные задачи и выстраивать эффективные workflow.
▪️ Родион Мостовой -> как устроены контекстный движок и AI-агент CodeAlive, а также подходы к code exploration и оценке моделей.
▪️ Артем Летюшев -> почему agent skills это не просто промпты, а важный слой для создания гибких и масштабируемых AI-систем.
До встречи вечером!😉
Напоминаю, в рамках AI Engineers Guild x Bereke Bank делаем сегодня в 18:30 по Алматы состоится Agentic Harness Meetup: что под капотом.
Сегодня обсудим:
▪️ Павел Королев -> как кастомизировать AI-агентов под реальные инженерные задачи и выстраивать эффективные workflow.
▪️ Родион Мостовой -> как устроены контекстный движок и AI-агент CodeAlive, а также подходы к code exploration и оценке моделей.
▪️ Артем Летюшев -> почему agent skills это не просто промпты, а важный слой для создания гибких и масштабируемых AI-систем.
До встречи вечером!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5👎2
#мнение
Чем любят грешить менеджеры
Здравствуй, дорогой читатель. Это пост про фундаментальное правило управления изменениями и внедрениями, которое часто игнорируют руководители
В целом проджекты/коучи/продакты и любый IT-менеджеры достаточно часто жалуются что внедрения буксуют, команды сопротивляются чему-то правильному и очевидно нужному. Меня давно раздражает ситуация, когда человек сходил на курс, посмотрел вебинар, словил инсайт, а затем через день несёт его как новый порядок жизни: теперь у нас OKR, переходим на Kanban, ИИ агент для логов и вообще всем курсор! И классика провести через ретро под соусом "tech excellence/улучшения инструментов/команда не знала о таком"
Правило простое: не внедрять в команду то, что хотя бы минимально не пощупал сам. Не "прочитал", не "было на прошлом месте", не "знаю, как должно быть", а попробовал, пожил внутри и понял где бесит
Первые пару лет бытности проджектом почти все мои внедрения и улучшения проваливались. Спасибо большое Жене из Яндекс Денег с позицией "ну ты сам научись дашборды делать в повербиай, а потом команде затирай как правильнее". Отсюда выросло огромное количество разных инициатив, которые я предварительно тестировал на себе. Вот несколько примеров
1) Когда я хотел больше прозрачности и нормальной гигиены задач, я сначала несколько месяцев кошмарил самого себя в Notion: цели, инициативы, месячные планы, задачи, статусы, прогресс, декомпозиция и связи задач
2) С OKR было так же: несколько лет связки годовые->квартальные->месячные цели, с полным трекингом и всеми OKR ритуалами
3) С ИИ безопасностью я несколько раз жестко косячил, собрал ai-repo-safety-skill и внедрял сканеры скиллов
4) С быстрым фронтом через ИИ я пошёл в OpenDesign, сделал несколько прототипов, а потом на внутреннем демо Twinby с автономными целями
5) С Text2SQL история такая же. Можно красиво сказать “давайте сделаем агента, чтобы менеджеры и аналитики сами спрашивали базу”, но потом приходят вопросы: как актуализировать метаданные, как объяснить агенту бизнесовый смысл полей, как ограничить доступы, как понять что ответ не бред и тп. Я поковырял VannaAI (царствие ему), сделал семантическую разметку и CLI на Rust. На скрине тот самый "txttsql" : агентик RAG, файловый семантический слой и защищённый read only SQL исполнитель для аналитики. Только после этого у меня появился сильный голос по таким вопросам
Я не верю в менеджера, который должен уметь всё лучше команды. Если ПМ пишет код за разработчиков, дизайнит за дизайнеров, считает за аналитиков и ещё модерирует все созвоны, то он не молодец, а узкое место с конечной емкостью календаря
Я уже писал про то что хороший менеджер должен хотя бы один раз зайти в чужую реальность ногами: хочешь понять разработчиков, сделай маленькую инженерную задачу; хочешь понять аналитиков, сам достань ответ из данных. Я поднимал вопрос вопрос нужны ли менеджеры, аналогичный тому что пишет Аня https://t.me/proproduct/1585 и поднимал вопрос какие менеджеры нужны https://t.me/junior_pm/464. Но тут про другое
Если ты хочешь внедрить и что-то изменить, например OKR, поживи квартал со своими OKR; хочешь требовать прозрачности, стань прозрачным сам. Проживание и непосредственный опыт кроме большего погружения и понимания дают еще одно фундаментальное преимущество - тебя больше уважают сотрудники, это наиболее полно демонстрирует что тебе не все равно и тебе важна их работа
Любое внедрение должно начинаться с руководителя не потому, что руководитель умнее всех, а потому что он первым платит маленькую цену: пробует, ошибается, показывает где было больно и только потом приходит к людям с предложением что-то менять. Не “я придумал, теперь вы живите”, а “я попробовал, вот что понял, давайте проверим вместе”
Чем любят грешить менеджеры
Здравствуй, дорогой читатель. Это пост про фундаментальное правило управления изменениями и внедрениями, которое часто игнорируют руководители
В целом проджекты/коучи/продакты и любый IT-менеджеры достаточно часто жалуются что внедрения буксуют, команды сопротивляются чему-то правильному и очевидно нужному. Меня давно раздражает ситуация, когда человек сходил на курс, посмотрел вебинар, словил инсайт, а затем через день несёт его как новый порядок жизни: теперь у нас OKR, переходим на Kanban, ИИ агент для логов и вообще всем курсор! И классика провести через ретро под соусом "tech excellence/улучшения инструментов/команда не знала о таком"
Правило простое: не внедрять в команду то, что хотя бы минимально не пощупал сам. Не "прочитал", не "было на прошлом месте", не "знаю, как должно быть", а попробовал, пожил внутри и понял где бесит
Первые пару лет бытности проджектом почти все мои внедрения и улучшения проваливались. Спасибо большое Жене из Яндекс Денег с позицией "ну ты сам научись дашборды делать в повербиай, а потом команде затирай как правильнее". Отсюда выросло огромное количество разных инициатив, которые я предварительно тестировал на себе. Вот несколько примеров
1) Когда я хотел больше прозрачности и нормальной гигиены задач, я сначала несколько месяцев кошмарил самого себя в Notion: цели, инициативы, месячные планы, задачи, статусы, прогресс, декомпозиция и связи задач
2) С OKR было так же: несколько лет связки годовые->квартальные->месячные цели, с полным трекингом и всеми OKR ритуалами
3) С ИИ безопасностью я несколько раз жестко косячил, собрал ai-repo-safety-skill и внедрял сканеры скиллов
4) С быстрым фронтом через ИИ я пошёл в OpenDesign, сделал несколько прототипов, а потом на внутреннем демо Twinby с автономными целями
/goal и админкой на Angular знатно облажался. Полезная лужа, после которой я перестал лезть к разработчикам с советами в зоне, где сам ещё не прожил достаточно боли5) С Text2SQL история такая же. Можно красиво сказать “давайте сделаем агента, чтобы менеджеры и аналитики сами спрашивали базу”, но потом приходят вопросы: как актуализировать метаданные, как объяснить агенту бизнесовый смысл полей, как ограничить доступы, как понять что ответ не бред и тп. Я поковырял VannaAI (царствие ему), сделал семантическую разметку и CLI на Rust. На скрине тот самый "txttsql" : агентик RAG, файловый семантический слой и защищённый read only SQL исполнитель для аналитики. Только после этого у меня появился сильный голос по таким вопросам
Я не верю в менеджера, который должен уметь всё лучше команды. Если ПМ пишет код за разработчиков, дизайнит за дизайнеров, считает за аналитиков и ещё модерирует все созвоны, то он не молодец, а узкое место с конечной емкостью календаря
Я уже писал про то что хороший менеджер должен хотя бы один раз зайти в чужую реальность ногами: хочешь понять разработчиков, сделай маленькую инженерную задачу; хочешь понять аналитиков, сам достань ответ из данных. Я поднимал вопрос вопрос нужны ли менеджеры, аналогичный тому что пишет Аня https://t.me/proproduct/1585 и поднимал вопрос какие менеджеры нужны https://t.me/junior_pm/464. Но тут про другое
Если ты хочешь внедрить и что-то изменить, например OKR, поживи квартал со своими OKR; хочешь требовать прозрачности, стань прозрачным сам. Проживание и непосредственный опыт кроме большего погружения и понимания дают еще одно фундаментальное преимущество - тебя больше уважают сотрудники, это наиболее полно демонстрирует что тебе не все равно и тебе важна их работа
Любое внедрение должно начинаться с руководителя не потому, что руководитель умнее всех, а потому что он первым платит маленькую цену: пробует, ошибается, показывает где было больно и только потом приходит к людям с предложением что-то менять. Не “я придумал, теперь вы живите”, а “я попробовал, вот что понял, давайте проверим вместе”
👍17💅8👎3
#рецепт
В чём настоящая ценность Agent Skills. Часть 1
Здравствуй, дорогой читатель. Скиллы до сих почти никто не понял. Я уже писал вводный пост про скиллы и почему менеджерам стоит смотреть на них как на святой грааль: https://t.me/junior_pm/422
После доклада про Agentic Harness хочу докрутить мысль инженернее. Скилл - это не "промпт в папочке", а слой поведения агента. MCP, API и CLI дают агенту руки, а skill объясняет, когда этими руками не стоит случайно уронить запросом БД, переписать ТЗ или сделать ревью уровня "в целом норм"
1) Agent Skill - это workflow package
Если давать адекватное определение, скилл -> самодостаточный пакет процедурного знания, который агент динамически загружает для решения задачи
Если разложить по-честному, то prompt - это разовая инструкция, script - детерминированный код, MCP tool - доступ к действию, subagent - отдельный worker, AGENTS.md/rules - фоновые правила проекта. Skill находится между всем этим: он говорит агенту, когда применять процесс, как идти по шагам, какие артефакты читать, какие проверки делать и где остановиться за апрувом
Реализуется в формате папка с SKILL.md (YAML + Markdown) +
опциональные файлы. Skill.md = metadata + instructions + optional references + usage policy. Открытый формат лежит тут: https://github.com/agentskills/agentskills, реальные примеры от Anthropic тут: https://github.com/anthropics/skills, у OpenAI Codex механика описана тут: https://developers.openai.com/codex/skills
2) Skill хорошо ложится на BPMN-мышление процессников
description - триггер процесса, тело SKILL.md - шаги, When to use / When not - гейты, scripts/ - подпроцессы, references/ - политики и справка, assets/ - шаблоны, examples/ - эталонные входы/выходы, allowed-tools - права. Те это уже не markdown с советами, а почти исполняемая процедура
Менеджерский кайф тут простой: можно перестать пересказывать агенту как у нас принято и начать версионировать это в Git. Не Тимлид Петя знает как делать ревью, а code-review/SKILL.md, пошаренный на всех и прописанный хуком всем перед отправкой MRa
3) Скиллы органично зарождаются и эволюционируют:
0. Замечаешь что пару раз в неделю делаешь одно и то же. Ctrl + c - Ctrl + v инструкция аля в Claude Code
1. Описываешь повторяющееся действие и структурируешь в промпт
2. Переносишь промпт в формат agent skills, чисто враппер
3. Добавляешь в скилл воркфлоу с гейтами что, после чего и как проверять
4. Объясняешь скилл как писать скрипты для решения задачи в моменте
5. Делаешь готовые шаблоны и скрипты и прикладываешь их в скилл, чтобы он их вызывал
6. Выносишь весь дактайпинг, шейрд и прочее из скриптов в общие ассеты, энвы и конфиги
7. Оборачиваешь скрипты в MCP или CLI
7. Переписываешь проект на чистовой бойлерплейт и правильную структуру
8. Распространяешь
В twinby я смотрю на это именно так: не заменим людей агентами, а вытащим повторяемые куски работы в управляемый слой. Например, как собирать апдейты по джире, как проверять на корректность ТЗ, как автоматизировать ручные тесты в браузере и тд
Практический вывод
Первый skill стоит делать не про агенты, инстаграм инфоцыганщину про Agent OS/Second brain/AI native team, а про маленькую повторяемую проверку: backlog hygiene, PR review precheck, release readiness, spec quality checker, repo safety scan. Чем уже граница, тем проще проверить качество и тем меньше шанс собрать очередной карго-культ в красивой папке, нужный 1 человеку
В чём настоящая ценность Agent Skills. Часть 1
Здравствуй, дорогой читатель. Скиллы до сих почти никто не понял. Я уже писал вводный пост про скиллы и почему менеджерам стоит смотреть на них как на святой грааль: https://t.me/junior_pm/422
После доклада про Agentic Harness хочу докрутить мысль инженернее. Скилл - это не "промпт в папочке", а слой поведения агента. MCP, API и CLI дают агенту руки, а skill объясняет, когда этими руками не стоит случайно уронить запросом БД, переписать ТЗ или сделать ревью уровня "в целом норм"
1) Agent Skill - это workflow package
Если давать адекватное определение, скилл -> самодостаточный пакет процедурного знания, который агент динамически загружает для решения задачи
Если разложить по-честному, то prompt - это разовая инструкция, script - детерминированный код, MCP tool - доступ к действию, subagent - отдельный worker, AGENTS.md/rules - фоновые правила проекта. Skill находится между всем этим: он говорит агенту, когда применять процесс, как идти по шагам, какие артефакты читать, какие проверки делать и где остановиться за апрувом
Реализуется в формате папка с SKILL.md (YAML + Markdown) +
опциональные файлы. Skill.md = metadata + instructions + optional references + usage policy. Открытый формат лежит тут: https://github.com/agentskills/agentskills, реальные примеры от Anthropic тут: https://github.com/anthropics/skills, у OpenAI Codex механика описана тут: https://developers.openai.com/codex/skills
2) Skill хорошо ложится на BPMN-мышление процессников
description - триггер процесса, тело SKILL.md - шаги, When to use / When not - гейты, scripts/ - подпроцессы, references/ - политики и справка, assets/ - шаблоны, examples/ - эталонные входы/выходы, allowed-tools - права. Те это уже не markdown с советами, а почти исполняемая процедура
Менеджерский кайф тут простой: можно перестать пересказывать агенту как у нас принято и начать версионировать это в Git. Не Тимлид Петя знает как делать ревью, а code-review/SKILL.md, пошаренный на всех и прописанный хуком всем перед отправкой MRa
3) Скиллы органично зарождаются и эволюционируют:
0. Замечаешь что пару раз в неделю делаешь одно и то же. Ctrl + c - Ctrl + v инструкция аля в Claude Code
1. Описываешь повторяющееся действие и структурируешь в промпт
2. Переносишь промпт в формат agent skills, чисто враппер
3. Добавляешь в скилл воркфлоу с гейтами что, после чего и как проверять
4. Объясняешь скилл как писать скрипты для решения задачи в моменте
5. Делаешь готовые шаблоны и скрипты и прикладываешь их в скилл, чтобы он их вызывал
6. Выносишь весь дактайпинг, шейрд и прочее из скриптов в общие ассеты, энвы и конфиги
7. Оборачиваешь скрипты в MCP или CLI
7. Переписываешь проект на чистовой бойлерплейт и правильную структуру
8. Распространяешь
В twinby я смотрю на это именно так: не заменим людей агентами, а вытащим повторяемые куски работы в управляемый слой. Например, как собирать апдейты по джире, как проверять на корректность ТЗ, как автоматизировать ручные тесты в браузере и тд
Практический вывод
Первый skill стоит делать не про агенты, инстаграм инфоцыганщину про Agent OS/Second brain/AI native team, а про маленькую повторяемую проверку: backlog hygiene, PR review precheck, release readiness, spec quality checker, repo safety scan. Чем уже граница, тем проще проверить качество и тем меньше шанс собрать очередной карго-культ в красивой папке, нужный 1 человеку
🔥5👍4👏1💩1
#рецепт
В чём настоящая ценность Agent Skills. Часть 2
В прошлой части я докрутил мысль, что skill - это workflow package, а не промпт в папочке. Теперь о том, почему у одних скиллы работают, а у других превращаются в markdown-папку с надеждой на чудо или вообще не вызываются
Главный подвох: настоящий прикол не только в SKILL.md, а в связке Skill + Agent Harness. Harness - это рантайм вокруг модели: поиск skills, выбор нужного, загрузка инструкций, запуск tools/MCP/shell, права, traces, approvals. Хороший инженерный разбор есть у Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/
1) Progressive disclosure - причина почему скиллы масштабируются
Агент не должен держать в контексте всю корпоративную библиотеку знаний. Сначала он видит только name + description, потом при выборе грузит SKILL.md, а уже после этого читает references/, assets/, examples/ или исполняет scripts/
Именно поэтому skill лучше гигантского AGENTS.md на 3000 строк. AGENTS.md - always-on фон, skill - on-demand способность. У Codex это описано тут: https://developers.openai.com/codex/skills, у Claude Code тут: https://code.claude.com/docs/en/skills (с CC конечно есть нюансы)
Практический совет: в SKILL.md оставляй короткую процедуру, а длинные политики, API-доки, JQL-справки, шаблоны отчетов и примеры выноси в references/assets/examples. Если SKILL.md раздулся в трактат, вероятность его работы крайне низка
2) description - главный триггер, а не аннотация для красоты
Частая ошибка: красивое тело скилла и бесполезный description. Агент выбирает skill именно по description, поэтому "Helps with code" - мусор. Это как задача в Jira с названием "Сделать нормально"
Нормальный description отвечает: какую задачу делает skill, когда применять, какие слова его триггерят, какие входы нужны, какой результат вернуть и когда НЕ использовать. Пиши скиллы на 1 языке, не используй англорусский, шалоказахский и хинглиш
Плохой пример: Helps with project management
Лучше: Checks Jira sprint health, finds blocked issues, stale tasks, missing owners and release risks. Use before daily status update or weekly project report. Do not use for backlog prioritization
Для проектирования смотри skill-creator от Anthropic: https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md
3) Anti-rationalization надо писать прямо в инструкции
Агент любит срезать углы не хуже менеджера перед пятничным демо. Он легко скажет изменение маленькое, визуально норм, тест-ран тут большой не надо запускать и тд. Поэтому в skill надо писать правила против отговорок
Примеры:
- - -
- если есть diff, сначала inspect, потом summary, потом plan
- если действие меняет внешнюю систему, сначала dry-run
- если есть write/delete/update, нужен explicit approval
- если нет данных, верни missing context, а не додумывай
- если scanner не запускался, не пиши что проверка пройдена
- - -
В twinby я бы такие штуки паковал в jira-daily-radar, spec-quality-checker, release-readiness, browser-manual-test и confluence-sync. Не "агент, расскажи статус", а процедура: откуда читать, что считать риском, какой формат отчета, где нужен человек
4) Skill надо тестировать не только на результат, но и на срабатывание
Минимальный набор:
- explicit activation test: вызвался руками
- implicit activation test: вызвался по естественному запросу
- negative test: не вызвался там, где не должен
- golden samples: вход -> ожидаемый выход
- unit tests для scripts/
- trace review: видно какие шаги реально прошли
- with/without skill: есть ли прирост качества, времени или стабильности
По evals полезны OpenAI материалы: https://developers.openai.com/blog/eval-skills и разбор Phil Schmid: https://www.philschmid.de/testing-skills
Хороший skill скучный: он умеет только 1 штуку делать, явно триггерится, явно проверяет, явно падает и явно просит апрув. Всё остальное обычно демка для LinkedIn/X/чата ваших фанатов в телеграм
В чём настоящая ценность Agent Skills. Часть 2
В прошлой части я докрутил мысль, что skill - это workflow package, а не промпт в папочке. Теперь о том, почему у одних скиллы работают, а у других превращаются в markdown-папку с надеждой на чудо или вообще не вызываются
Главный подвох: настоящий прикол не только в SKILL.md, а в связке Skill + Agent Harness. Harness - это рантайм вокруг модели: поиск skills, выбор нужного, загрузка инструкций, запуск tools/MCP/shell, права, traces, approvals. Хороший инженерный разбор есть у Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/
1) Progressive disclosure - причина почему скиллы масштабируются
Агент не должен держать в контексте всю корпоративную библиотеку знаний. Сначала он видит только name + description, потом при выборе грузит SKILL.md, а уже после этого читает references/, assets/, examples/ или исполняет scripts/
Именно поэтому skill лучше гигантского AGENTS.md на 3000 строк. AGENTS.md - always-on фон, skill - on-demand способность. У Codex это описано тут: https://developers.openai.com/codex/skills, у Claude Code тут: https://code.claude.com/docs/en/skills (с CC конечно есть нюансы)
Практический совет: в SKILL.md оставляй короткую процедуру, а длинные политики, API-доки, JQL-справки, шаблоны отчетов и примеры выноси в references/assets/examples. Если SKILL.md раздулся в трактат, вероятность его работы крайне низка
2) description - главный триггер, а не аннотация для красоты
Частая ошибка: красивое тело скилла и бесполезный description. Агент выбирает skill именно по description, поэтому "Helps with code" - мусор. Это как задача в Jira с названием "Сделать нормально"
Нормальный description отвечает: какую задачу делает skill, когда применять, какие слова его триггерят, какие входы нужны, какой результат вернуть и когда НЕ использовать. Пиши скиллы на 1 языке, не используй англорусский, шалоказахский и хинглиш
Плохой пример: Helps with project management
Лучше: Checks Jira sprint health, finds blocked issues, stale tasks, missing owners and release risks. Use before daily status update or weekly project report. Do not use for backlog prioritization
Для проектирования смотри skill-creator от Anthropic: https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md
3) Anti-rationalization надо писать прямо в инструкции
Агент любит срезать углы не хуже менеджера перед пятничным демо. Он легко скажет изменение маленькое, визуально норм, тест-ран тут большой не надо запускать и тд. Поэтому в skill надо писать правила против отговорок
Примеры:
- - -
- если есть diff, сначала inspect, потом summary, потом plan
- если действие меняет внешнюю систему, сначала dry-run
- если есть write/delete/update, нужен explicit approval
- если нет данных, верни missing context, а не додумывай
- если scanner не запускался, не пиши что проверка пройдена
- - -
В twinby я бы такие штуки паковал в jira-daily-radar, spec-quality-checker, release-readiness, browser-manual-test и confluence-sync. Не "агент, расскажи статус", а процедура: откуда читать, что считать риском, какой формат отчета, где нужен человек
4) Skill надо тестировать не только на результат, но и на срабатывание
Минимальный набор:
- explicit activation test: вызвался руками
- implicit activation test: вызвался по естественному запросу
- negative test: не вызвался там, где не должен
- golden samples: вход -> ожидаемый выход
- unit tests для scripts/
- trace review: видно какие шаги реально прошли
- with/without skill: есть ли прирост качества, времени или стабильности
По evals полезны OpenAI материалы: https://developers.openai.com/blog/eval-skills и разбор Phil Schmid: https://www.philschmid.de/testing-skills
Хороший skill скучный: он умеет только 1 штуку делать, явно триггерится, явно проверяет, явно падает и явно просит апрув. Всё остальное обычно демка для LinkedIn/X/чата ваших фанатов в телеграм
👍3🔥3👏2💩2