Скрипт, skill, MCP або plugin

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.

Якщо сказати зовсім коротко, розділення виходить таким:

script

skill

MCP

plugin

Тепер про 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-інструментом, який прекрасно живе рівно до першого поганого дня.