1. Внутренний инструмент — не всегда плагин
После такого набора helpers легко впасть в другую крайность: раз у нас всё серьёзно и по-взрослому, значит, любой повтор надо упаковать в plugin — с красивым названием и чуть пугающим YAML. На практике это очень быстрый способ открыть небольшой музей забытых automation-экспонатов.
Когда команда работает над Commerce OS, у неё постоянно всплывают мелкие, но раздражающие повторы. Кто-то перед review снова собирает список затронутых модулей. Кто-то перед релизом вручную просматривает merged PR и пишет черновик release notes. Кто-то копирует номер issue из трекера, вставляет в запрос к Claude, потом перепроверяет статус.
Каждая такая боль выглядит как приглашение: «давайте сделаем инструмент». Но у инструмента есть скрытая цена: его надо хранить, запускать, объяснять, поддерживать, иногда — отключать. Боль случилась раз, а вы убили полдня на автоматизацию? Победы не случилось. Поэтому первый вопрос всегда один и тот же: какой минимальный уровень сложности реально решает задачу? Не «что солиднее», а «что минимально достаточно». Для этого полезно держать в голове простую лестницу решений.
flowchart TD
A[Появилась повторяющаяся задача] --> B{Она одноразовая?}
B -- Да --> C[Делаем вручную]
B -- Нет --> D{Вы повторяете её сами больше 3 раз?}
D -- Нет --> C
D -- Да --> E[Простой скрипт]
E --> F{Инструмент нужен нескольким людям?}
F -- Нет --> E
F -- Да --> G[Skill]
G --> H{Нужны живые данные внешнего сервиса?}
H -- Да --> I[MCP]
H -- Нет --> J{Нужно распространять между repo и версиями?}
J -- Нет --> G
J -- Да --> K[Plugin]
Эта схема хороша тем, что она сбивает лишний пафос. Одноразовая — руками. Повторяете сами четвёртый раз — скрипт. Тот же шаг нужен нескольким людям как процедура — skill. Без внешнего сервиса инструмент бесполезен — MCP. А plugin появляется не потому, что «мы доросли», а потому, что уже есть что упаковывать и версионировать между репозиториями или командами.
Не делайте plugin для того, что решает простой скрипт.
Плагин ради одного локального ритуала — это как строить аэропорт, чтобы раз в месяц летать за хлебом.
2. Простой скрипт: недооценённый internal tool
Скрипт часто кажется слишком простым: несолидно, всего пара строк shell или Python, ни витрины, ни каталога расширений. Но именно поэтому он так полезен — решает одну узкую боль без обещания, что вы построили внутреннюю платформу уровня космодрома.
Представьте типичную ситуацию в Commerce OS. Есть PR с изменёнными файлами, и reviewer каждый раз хочет понять, какие зоны затронуты: orders, payments, dashboard, support. Смотреть git diff руками можно — один раз. Но если это на каждом review — вот кандидат на маленький helper-скрипт в Workflow Kit.
#!/usr/bin/env bash
git diff --name-only origin/main...HEAD \
| cut -d/ -f1-2 \
| sort -u
# Вывод:
# backend/orders
# frontend/adminТакой скрипт не пытается быть умным: не анализирует архитектуру, не выносит суждений, не обещает одобрить PR. Он даёт reviewer быстрый список зон, куда потом смотреть внимательнее. Скрипт не обязан быть великим. Экономит несколько минут и запускается без шаманства — уже полезен.
Именно на этом уровне внутренний инструмент чаще всего и должен оставаться локальным. Не превращайте его в must-pass check, блокирующий merge: это не quality gate, а supporting helper — ускоряет чтение изменения, но не заменяет решение человека. В QUALITY_GATES.md упоминайте его как вспомогательный: достаточно короткой секции про supporting tools, отдельный файл ради одного helper только раздувает систему.
## Поддерживающие инструменты
- `scripts/changed-modules.sh` — helper для reviewer, informational
- `skills/release-notes/` — advisory-черновик release notesЭто не gate и не must-pass check — просто честная пометка для команды: рядом с границей видно, какие инструменты помогают её проходить. Здесь есть тонкая, но важная дисциплина: как только у вас появляется полезный скрипт, возникает соблазн наделить его властью — «раз уж есть, пусть будет обязательным». Но наличие automation ещё не делает её gate. Скрипт может быть помощником и оставаться просто помощником.
Хороший практический критерий такой: вход детерминированный, выход механический и понятный — начинайте со скрипта. Позже проблема окажется уже не в запуске команды, а в повторяющемся анализе и одинаковом формате результата, — тогда поднимайтесь выше.
3. Скрипт превращается в skill
Бывает, что команда повторяет не просто команду, а целый мыслительный ритуал: открыть diff, выделить risky files, описать риски, не забыть про совместимость, отметить непроверенное. Скрипта мало — он умеет запускаться, но не умеет объяснять, как думать и в каком виде вернуть результат.
Возьмём продолжение того же сценария с Commerce OS. Перед каждым маленьким релизом кто-то просматривает merged PR, собирает заголовки, просит Claude сделать черновик release notes. Формально это один prompt снова и снова. Но если вся команда повторяет один ход и каждый раз ждёт одинаковую структуру ответа — это уже не «команда на запуск», а повторяемый workflow. Пора думать про skill.
В Workflow Kit у такого инструмента появляется не только команда, но и контракт: когда использовать, что считать входом, что вернуть.
---
name: release-notes
description: Собирает черновик release notes из git log и merged PR.
---
Верни:
1. изменения для пользователя,
2. внутренние изменения,
3. известные риски.Почему здесь лучше skill, а не скрипт? Потому что проблема уже не в том, чтобы достать данные из Git, а в том, чтобы Claude каждый раз мыслил одинаково: не расползался на подробности, не забывал про риски, не путал user-facing изменения с внутренними. Полезно заметить, что скрипт и skill не конкурируют, а часто работают в паре: скрипт соберёт сырой материал, например список merged PR за диапазон, а skill объяснит Claude, как его интерпретировать и оформить. Скрипт — за механику, skill — за структуру мышления и форму результата. Здоровее, чем заставлять один shell-файл быть и сборщиком данных, и аналитиком, и редактором.
Ещё одна хорошая новость: на этом уровне вам всё ещё не нужен plugin. Workflow полезен одной команде, живёт рядом с проектом, не требует distribution между кодовыми базами — хватит project-level skill. Не так эффектно, как «мы сделали внутренний плагин». Зато пользоваться можно сегодня, а не после недели упаковки, README, namespace и споров, как назвать папку.
4. MCP и plugin: разделение зон ответственности
Самая частая инженерная драма звучит так: «Появился внешний сервис, значит нужен plugin». Нет, не значит. Внешний сервис говорит лишь о том, что понадобился доступ к живым данным или действию. Это территория MCP. Plugin — про другое: он нужен, когда готовый workflow надо упаковать, версионировать и раздать между репозиториями или командами.
Продолжим ту же линию с release notes для Commerce OS. Допустим, команде уже мало локального Git-лога — она хочет подтягивать статусы issues из трекера: закрыта ли задача, какой приоритет, не висит ли пометка blocked. Ни скрипт, ни skill этого не решат: скрипт работает с локальным, skill направляет Claude, а доступа к внешнему источнику актуальных данных не даёт ни один. Здесь появляется read-only MCP для issue tracker.
Если сказать совсем коротко, разделение получается таким:
| Сигнал | Минимально достаточный выбор | Почему |
|---|---|---|
| Вы повторяете локальную команду | |
Нужна механика, а не сложная логика |
| Команда повторяет один и тот же Claude-workflow | |
Нужен воспроизводимый результат и формат |
| Нужны живые данные внешнего сервиса | |
Без внешнего источника инструмент слепой |
| Один и тот же набор инструментов нужен нескольким repo | |
Нужна упаковка, versioning и распространение |
Теперь о plugin. Представьте, что тот же release workflow вдруг становится нужен не только в Commerce OS, но и во второй кодовой базе — например, в legacy-сервисе с финансовыми расчётами. У вас уже зрелый набор: skills/release-notes/, helper-скрипт, README, одобренный командой read-only MCP для issue tracker. Вот теперь plugin имеет смысл: workflow придуман, задача — доставлять один набор в несколько репозиториев одинаково, с понятной версией и owner.
И вот это главное различие:
- MCP отвечает на вопрос: как дать контролируемый доступ к внешним данным и действиям.
- Plugin отвечает на вопрос: как упаковать и распространить уже полезный workflow.
Если этот разрез у вас в голове не размазан, вы почти автоматически перестаёте городить лишнюю сложность. Статический Markdown-шаблон не требует MCP. Один локальный shell-helper не требует plugin. Сначала решаем боль минимально достаточным способом, потом усложняем форму.
5. Tool-readiness checklist: helper → team asset
Почти у каждого разработчика есть личный helper, который «у меня работает»: иногда это alias в shell, иногда папка scripts/, иногда skill, который понимаете только вы и, может, ваш ноутбук. Но командным инструментом такая вещь становится не в момент коммита, а когда ей может пользоваться другой человек без шаманского танца.
Вот здесь и нужен tool-readiness checklist. Он короткий, но очень приземлённый:
- есть README с запуском и хотя бы одним примером;
- есть явный владелец — один человек, а не абстрактное «команда разберётся»;
- инструмент попробовал хотя бы один человек, кроме автора;
- у него более-менее стабильный интерфейс, который не ломается каждую неделю;
- у него есть понятный способ отключения или отката.
На первый взгляд это выглядит почти скучно. Где тут магия? Нигде. И именно поэтому checklist так полезен. Внутренний инструмент разваливается не от недостатка вдохновения, а от прозы: никто не понимает, как его запускать, неясно, кто чинит поломку, второй человек его ни разу не открывал, а отключить можно только через археологические раскопки в конфиге. Даже простой README резко повышает шансы дожить до следующего месяца. Для release helper это буквально четыре строки.
# workflow-kit-release
Запуск: skill `release-notes` + read-only MCP `issue-tracker`
Пример: weekly release notes для Commerce OS
Владелец: @release-owner
Отключение: убрать инструмент из проекта и вернуться к локальному запускуОбратите внимание на тон: здесь нет пафоса и нет попытки выдать helper за платформу вселенского масштаба. Но уже есть всё, что нужно другому человеку — как запустить, на каком сценарии проверить, кто отвечает, как выключить. Это и отделяет зрелый инструмент от личного секрета разработчика.
Очень важно, что checklist проверяет не красоту архитектуры, а готовность к использованию. Можно написать изящный tool, который никто, кроме автора, не запустит. И можно сделать скромный skill или скрипт, который команда использует каждый день. Второй — куда более ценный артефакт.
Поэтому, когда вы в следующий раз почувствуете желание «поднять уровень» и упаковать всё в более солидную форму, попробуйте начать не с вопроса «а не сделать ли plugin?», а с вопроса «если другой разработчик откроет этот README, он поймёт, как этим пользоваться и как это выключить?». Уверенное «да» — и инструмент перестал быть вашим личным амулетом.
А как только им пользуется команда, кроме README и owner почти сразу нужны ещё две прозаичные вещи: где смотреть логи и как выключить сам инструмент, если сломается уже он. Без этого даже хороший script или skill остаётся хрупким helper-инструментом, который прекрасно живёт ровно до первого плохого дня.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ