Claude Cowork, Codex и другие агенты уже неплохо делают офисную работу — тексты, анализ, брейншторм, планирование, ... Многие из вас это с ними умеют.
Но попробуйте дать такого агента нетехническому сотруднику — он застрянет или откажется. Git? Бэклог задач? Разбираться с тем, почему агент так сделал, чтобы в следующий раз не вставать на грабли? Всё это «не для нас».
На GitHub полно skills для Git flow и организации работы — но они для разработчиков и заточены под сложные кейсы. Простых скиллов для не-кодерской работы почти нет. Но вот 3 скилла, которые во многом снимают возражение «не для нас»:
1️⃣ git-commit-flow — агент сам коммитит результаты, разделяя ИИ-коммиты и правки человека. И даже с понятными сообщениями (ну, если вы переведете скилл на русский). Сотруднику не нужно ни понимать git, ни помнить о сохранении. Почти так же, как ему не нужно помнить про автосохранение в Word. А к кнопке push можно привыкнуть: это как отправить файл коллегам.
2️⃣ task-file-updater — агент ведёт краткий бриф каждой сессии: что сделано, какие решения приняты и почему. Та самая прозрачность, которую вы как менеджер ждёте от команды, — только «команда» здесь это агент, а сотрудник примеряет роль менеджера.
Как и первый скилл, это мой личный (пишу вам я, Алексей Евдокимов). Он не претендует на удобство для всех, но показывает, как легко можно делать подобные скиллы "под конкретную команду".
3️⃣ planning-and-task-breakdown — декомпозиция + критерии приёмки. Лучший "не слишком технический" скилл для ведения бэклога, что я нашёл. С «душком» разработчиков — но вы со своим агентом легко сделаете из этого скилла упрощённую версию для своих сотрудников (все равно переводить на русский).
Мое мнение: не-технарям недостаточно дать «конкретные» #skills — нужны «процессные скиллы», организующие работу (сильно упрощенный аналог того harness, который технари делают для себя сами).
🔗 Больше таких скиллов с более подробными объяснениями — в моей июньской статье про прозрачность и другие Scrum-принципы для агентов.
Но попробуйте дать такого агента нетехническому сотруднику — он застрянет или откажется. Git? Бэклог задач? Разбираться с тем, почему агент так сделал, чтобы в следующий раз не вставать на грабли? Всё это «не для нас».
На GitHub полно skills для Git flow и организации работы — но они для разработчиков и заточены под сложные кейсы. Простых скиллов для не-кодерской работы почти нет. Но вот 3 скилла, которые во многом снимают возражение «не для нас»:
1️⃣ git-commit-flow — агент сам коммитит результаты, разделяя ИИ-коммиты и правки человека. И даже с понятными сообщениями (ну, если вы переведете скилл на русский). Сотруднику не нужно ни понимать git, ни помнить о сохранении. Почти так же, как ему не нужно помнить про автосохранение в Word. А к кнопке push можно привыкнуть: это как отправить файл коллегам.
2️⃣ task-file-updater — агент ведёт краткий бриф каждой сессии: что сделано, какие решения приняты и почему. Та самая прозрачность, которую вы как менеджер ждёте от команды, — только «команда» здесь это агент, а сотрудник примеряет роль менеджера.
Как и первый скилл, это мой личный (пишу вам я, Алексей Евдокимов). Он не претендует на удобство для всех, но показывает, как легко можно делать подобные скиллы "под конкретную команду".
3️⃣ planning-and-task-breakdown — декомпозиция + критерии приёмки. Лучший "не слишком технический" скилл для ведения бэклога, что я нашёл. С «душком» разработчиков — но вы со своим агентом легко сделаете из этого скилла упрощённую версию для своих сотрудников (все равно переводить на русский).
Мое мнение: не-технарям недостаточно дать «конкретные» #skills — нужны «процессные скиллы», организующие работу (сильно упрощенный аналог того harness, который технари делают для себя сами).
🔗 Больше таких скиллов с более подробными объяснениями — в моей июньской статье про прозрачность и другие Scrum-принципы для агентов.