#мнение
Чем любят грешить менеджеры

Здравствуй, дорогой читатель. Это пост про фундаментальное правило управления изменениями и внедрениями, которое часто игнорируют руководители

В целом проджекты/коучи/продакты и любый 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; хочешь требовать прозрачности, стань прозрачным сам. Проживание и непосредственный опыт кроме большего погружения и понимания дают еще одно фундаментальное преимущество - тебя больше уважают сотрудники, это наиболее полно демонстрирует что тебе не все равно и тебе важна их работа

Любое внедрение должно начинаться с руководителя не потому, что руководитель умнее всех, а потому что он первым платит маленькую цену: пробует, ошибается, показывает где было больно и только потом приходит к людям с предложением что-то менять. Не “я придумал, теперь вы живите”, а “я попробовал, вот что понял, давайте проверим вместе”

#рецепт
В чём настоящая ценность 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. Часть 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/чата ваших фанатов в телеграм