@7n/rules 1.0.0

package/skills/lint/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: n-lint
+description: >-
+  Запустити дельта-лінт (npx @7n/rules lint) по змінених файлах vs origin, виправити порушення й підтвердити чистий вихід
+version: '1.0'
+---
+
+# n-lint — лінт проєкту по змінених файлах
+
+## Мета
+
+Прогнати **`npx @7n/rules lint`** (**дельта-режим**: лише файли, змінені vs `origin`), усунути порушення (авто- та вручну) і переконатися, що команда завершується з кодом **`0`**.
+
+> **Чому дельта, не `--full`?** `--full` — CI-режим: сканує весь репо незалежно від змін. Під час задачі це зайво — перевіряємо лише те, що змінили. `lint --full` запускати **не треба**.
+
+## Передумови
+
+- Поточна робоча директорія — **корінь репозиторію**.
+- Залежності встановлені (**`bun i`**) — якщо після правок змінювався **`package.json`** / lockfile, знову виконай **`bun i`** перед наступним запуском лінту.
+
+## Workflow
+
+1. **Запуск** — дельта-лінт по змінених файлах:
+
+```bash
+npx @7n/rules lint
+```
+
+2. **Якщо exit code не 0** — проаналізуй вивід:
+   - Де лінт уже робить **auto-fix** (**`--fix`**, **`oxfmt`** тощо) — перезапусти **`npx @7n/rules lint`** після змін файлів.
+   - Де auto-fix **немає** (наприклад, **jscpd**, **cspell**, **zizmor**) — **за замовчуванням рефактори код проєкту**, щоб усунути порушення. **Не** розширюй конфіги з винятками «мовчки» — див. блок **«Винятки в конфігурації»** нижче.
+   - Якщо спрацьовує **`sonarjs/cognitive-complexity`** — див. окремий блок нижче.
+
+3. **Цикл** — повторюй кроки 1–2, доки **`npx @7n/rules lint`** не завершиться успішно.
+
+4. **Верифікація** — фінальна перевірка (обов'язково з кодом **0**):
+
+```bash
+npx @7n/rules lint
+```
+
+5. **Результат** — коротко опиши, що саме виправлено; якщо щось блокує нульовий exit code — залиш чітке пояснення й наступні кроки для людини.
+
+## Винятки в конфігурації — інтерактивне рішення
+
+Коли порушення **не** зникає auto-fix і перша думка — «додати в ignore / words / minLines» — **STOP**. **Заборонено** мовчки редагувати конфіги лише щоб зеленіти лінт без згоди користувача.
+
+**Конфіги і коментарі, які потребують зупинки** (неповний список — будь-який аналог):
+
+| Інструмент          | Типові файли / зміни                                                                                            |
+| ------------------- | --------------------------------------------------------------------------------------------------------------- |
+| **jscpd**           | `.jscpd.json` → `ignore`, `minLines`                                                                            |
+| **cspell**          | `.cspell.json` → `words`, `ignorePaths`; `.cspellignore`                                                        |
+| **knip**            | `knip.json` → `ignore`, `ignoreDependencies`, `ignoreBinaries`, `entry`                                         |
+| **oxlint / ESLint** | `.oxlintrc.json` → `ignorePatterns`; `eslint.config.js` → `ignores`; `eslint-disable` / `oxlint-disable` у коді |
+| **інше**            | `.v8rignore`, `.stylelintignore`, `.trufflehog-exclude`, розширення `ignores` у workflow-конфігах               |
+
+Політика узгоджена з **`.cursor/rules/`** (зокрема **n-js**, **n-text**): виняток допустимий лише з **обґрунтованою** причиною, не як заміна рефакторингу для справжніх клонів / дублікатів.
+
+### Коли обовʼязково питати користувача
+
+Перед **будь-якою** правкою рядків із таблиці вище (або коментарем-винятком у коді) для **конкретного** порушення з поточного виводу лінту:
+
+1. **Зупини** автоматичні правки конфігів.
+2. **Один** виклик **`AskQuestion`** (або еквівалентне повідомлення з варіантами, якщо інструмент недоступний) — **одне питання на одне порушення** (або на одну логічну групу однакових jscpd-клонів у тому ж файлі).
+3. У тексті питання коротко дай **контекст**: інструмент, файл:рядок, суть порушення (1–2 речення), **що саме** пропонується додати в конфіг (точний glob / слово / ключ).
+
+**Варіанти відповіді** (мінімум такі; `allow_multiple: false`):
+
+| id            | label (українською)                                                                                     | Дія агента                                                                             |
+| ------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
+| `refactor`    | **Рефакторинг коду** — усунути дублікат / помилку в коді (рекомендовано за замовчуванням)               | Рефакторинг; конфіг **не** чіпати                                                      |
+| `ignore-once` | **Точковий виняток у конфігу** — додати ignore/words/minLines з обґрунтуванням у коментарі PR/відповіді | Після вибору — мінімальна зміна конфігу + 1 речення **чому** це не рефакторинг         |
+| `skip`        | **Залишити як є** — не чіпати ні код, ні конфіг зараз                                                   | Не змінювати; у фінальному резюме — що лишилось червоним                               |
+| `explain`     | **Потрібні деталі** — поясни варіанти глибше                                                            | Розгорнути порівняння refactor vs ignore; **знову** запитати той самий набір варіантів |
+
+Якщо користувач обрав **`ignore-once`** — у відповіді після зміни зафіксуй: який ключ конфігу змінено, який glob/слово додано, чому рефакторинг був недоречний (генерований код, формальний шаблон, легітимний термін без перекладу тощо).
+
+Якщо користувач **не** відповів (сесія без інтерактиву) — **не** додавай винятки в конфіг; роби **рефакторинг** або залиш порушення з поясненням у кроці 5 workflow.
+
+### Приклад формулювання (jscpd)
+
+> **jscpd:** клон 42 рядки в `src/foo.ts` ↔ `src/bar.ts` (однакова логіка валідації).  
+> Варіанти: (A) винести спільну функцію; (B) додати `src/bar.ts` у `.jscpd.json` → `ignore`; (C) пропустити зараз.
+
+Не виконуй (B), поки користувач явно не обрав **`ignore-once`**.
+
+## sonarjs/cognitive-complexity
+
+- **Не** додавай **`eslint-disable`** (у т.ч. на **`sonarjs/cognitive-complexity`**) чи інші коментарі-винятки лише щоб приховати порушення — потрібен саме **рефакторинг коду**, щоб зменшити **cognitive complexity**.
+- **Перед будь-яким рефакторингом** перевір, чи є **тести**, які покривають змінювану поведінку:
+  - **unit** — **`bun test`** (або скрипт тестів у відповідному пакеті репозиторію);
+  - **e2e** — **Playwright**, якщо в проєкті він використовується для UI/потоків.
+- Якщо тестів **немає** або вони **не покривають** блок, який змінюєш — **спочатку** додай/розшир тести, переконайся, що вони стабільно проходять, **потім** роби рефакторинг, **потім** знову прогони тести й **`npx @7n/rules lint`**, щоб підтвердити, що функціональність коректна й лінт чистий.
+- Якщо після рефакторингу тести або лінт падають — **не** залишай «половинчастий» рефакторинг: відкотись або доведи зміни до зеленого стану.
+
+## Паралелізм і навантаження на macOS
+
+**Дельта-лінт — без черги.** `npx @7n/rules lint` (дельта, типовий задачний прогін) не бере лока: паралельні запуски по різних файлах дозволені й не конфліктують.
+
+**`lint --full` — вбудована глобальна черга** (spec 2026-07-03): у кожен момент виконується один full-прогін на машину. Запуск у черзі сам показує свою позицію, решту черги і живий прогрес-бар активного прогону (`⏳ lint --full у черзі #2/3 · працює pid … [██████░░] 5/12 концернів · знайдено … · виправлено … · js/eslint`). Ідентичний повтор --full на незміненому дереві дедуплікується (`♻️ … пропускаю`). Агенту нічого координувати вручну.
+
+### Що робити агенту під час виконання цього скілу
+
+1. **Дельта-лінт** (`npx @7n/rules lint`) — можна запускати повторно; паралелізм із субагентами по різних файлах — OK.
+2. **`lint --full`** у цьому скілі **не запускати** — це CI-команда, не задачна.
+3. Якщо `--full`-запуск показує `⏳ lint --full у черзі…` — інший full-прогін ще працює; це штатна черга, не зависання. Fail-closed таймаут черги — 45 хв.
+
+**Що можна змінити у проєкті (локально або в `package.json`)**
+
+- **ESLint** (CLI): за потреби явно **`--concurrency off`** (див. **`eslint --help`**).
+- **oxlint**: **`--threads=1`**, якщо потрібно зменшити навантаження на CPU.
+- **ESLint cache**: **`--cache`** / **`--cache-location .eslintcache`** — менше повторного читання з диска.
+
+Канонічний рядок **`lint-js`** у репозиторіях з **`check js`** фіксований; додаткові прапорці — з узгодженням канону або в споживацькому проєкті окремо.
+
+## Примітка
+
+Окремих команд **`check`** / **`fix`** немає — **`npx @7n/rules lint`** це unified lint surface: detect + fix-by-default (авто-fix лінтерів/формату і програмних правил пакета **`@7n/rules`** в одному проході). **`--no-fix`** — лише detect, без записів.
+
+Для CI або явного повного сканування всього репо незалежно від змін — `npx @7n/rules lint --full`. Але в рамках задачі це **зайво**.

package/skills/lint/main.json

@@ -0,0 +1 @@
+{ "auto": "завжди", "worktree": true }

package/skills/llm-patch/SKILL.md

@@ -0,0 +1,260 @@
+---
+name: n-llm-patch
+description: >-
+  Підготовка самодостатнього текстового промпта для іншого Claude/Cursor-агента —
+  read-only аналіз CWD без жодних змін у поточному репо
+version: '1.0'
+---
+
+<!-- markdownlint-disable-file MD024 MD025 -->
+<!-- Файл демонструє шаблон промпта з кількома H1 (`# Завдання`, `# Релевантні файли` тощо)
+     — це інтенціональна частина showcase, а не порушення one-title-per-document. -->
+
+# Підготовка LLM-патчу (текстова комунікація між агентами)
+
+Скіл готує **самодостатній текстовий промпт** ("патч") для іншої LLM-сесії
+(Claude / Cursor agent у цільовому проєкті). Користувач копіює готовий блок
+з відповіді чату й вставляє його в розмову з іншим агентом — той виконує
+запитані зміни вже у своєму середовищі.
+
+## Принципи
+
+- **Read-only:** скіл нічого не пише в поточне репо. Лише читає CWD.
+- **Тимчасові артефакти — лише в `/tmp`** (наприклад, `tree`-вивід чи
+  проміжні чернетки промпту); ніколи не у CWD.
+- **Цільова LLM:** Claude / Cursor agent — припускаємо, що читач знається
+  на XML-тегах, file refs (`path/to/file.ts:42`), markdown.
+- **Один блок виводу:** результат — це **один** markdown-блок у відповіді
+  чату, готовий до копіювання.
+- **Лаконічність — головне:** промпт містить **інтент + покажчики**, а не
+  цитати + готовий код. Цільова LLM має повний доступ до свого CWD через
+  `Read`/`Grep`/`Glob` і прочитає актуальний стан сама — наш патч не повинен
+  дублювати те, до чого вона додумається з 2-3 файлів.
+
+## Що **не** включати у промпт (cut list)
+
+Цільова LLM сама прочитає файли — не дублюй їх. Викидай:
+
+- **Великі цитати коду** з файлів, які LLM знайде за file ref. Замість блоку
+  з 30 рядками функції — один рядок: `див. rules/foo/bar.mjs:120-150 (collect)`.
+  Цитуй **тільки**: вже видалений код (тобто LLM його не знайде), або фрагмент
+  з зовнішнього джерела (логи, stderr, помилка з CI).
+- **Готові імплементації** ("ось як має виглядати новий `defaultRunner`")
+  з повним кодом. Опиши інтент і обмеження — LLM напише код сама й краще
+  під поточний стиль файлу. Виняток: один-два рядки, які важко описати словами
+  (наприклад, точна назва прапора CLI).
+- **Покрокові підказки рівня "крок 1: import X, крок 2: split into a) і b)…"**
+  з псевдо-кодом. Це передчасна архітектура — описуй **бажану поведінку**
+  (input → output, edge cases), а декомпозицію довір LLM.
+- **Повний вміст `package.json`, конфігів, helpers** — досить імені поля та
+  значення, що змінюється: `engines.node: ">=22" → ">=25"`. Якщо значення
+  специфічне (peer ranges, exports map) — цитуй **тільки цей фрагмент**.
+- **Огляд альтернатив, які ти відкинув,** із розгорнутими аргументами. Один
+  рядок: "розглянутий варіант X відкинуто — Y" або взагалі прибрати, якщо
+  LLM сама дійде того самого висновку.
+- **Списки існуючих helpers ("вже є addCoverage у rules/test/coverage")** —
+  досить рядка-покажчика; LLM зайде `Grep`'ом і прочитає сигнатуру сама.
+- **Дублювання правил репо** (`CLAUDE.md`, `.cursor/rules/*.mdc`) — досить
+  згадки "дотриматись n-test.mdc"; LLM прочитає файл сама.
+- **Готовий `tree -L 2`-дамп** — досить рядка "монорепо з workspaces
+  cf/_, run/_, gt (bun)"; повна структура майже завжди шум.
+- **Самоочевидні acceptance-checks** ("тести зелені", "лінтер чистий") —
+  пиши тільки специфічні до завдання ("на репо `ai`: `bun run coverage`
+  не падає з `JS coverage exit 1`").
+
+## Що **обов'язково** включити
+
+- **Інтент** — 1-3 речення, що саме треба і чому (1 речення на причину).
+- **Симптом / репро,** якщо це bugfix: справжній stderr, точна команда,
+  exit code. Це **не** виводиться з коду — без нього LLM не знає, що
+  саме ламається.
+- **File refs** на ключові точки правки: `path:line` або `path:line-range`,
+  з одним рядком пояснення кожна.
+- **Реальні обмеження,** які не виводяться з коду: версії в репо-споживачі,
+  inflight-міграції, breaking-change політика, зовнішні залежності.
+- **Change-file flow,** якщо завдання змінює файли у пакетному workspace (код,
+  правила, скіли, конфіги, тести — не лише `docs/`): промпт має вимагати
+  `npx @7n/n ch [--bump <major|minor|patch>] [--section <Added|Changed|Fixed|Removed>] [--message "<опис>"]`
+  і `npx @7n/rules lint changelog`. **Ніколи** не інструктуй ручне редагування
+  `CHANGELOG.md` чи bump `version` — це робить release flow / CI (деталь —
+  `.cursor/rules/n-changelog.mdc`, не дублюй її текст). Якщо потрібна реліз-нота —
+  це change-файл `<ws>/.changes/<timestamp>-<rand>.md` з `bump:` і `section:`,
+  який створює `@7n/n ch`, а не редагування файлу вручну.
+- **Як перевірити** — конкретні команди й специфічні до завдання сигнали
+  успіху.
+
+## Виклик
+
+```
+/n-llm-patch <вільний опис завдання>
+```
+
+Аргумент має містити: **що треба зробити**, опційно — **назву пакета /
+підмодуля** для контексту. Якщо аргумент порожній — попроси користувача
+сформулювати завдання, не вгадуй.
+
+Приклад:
+
+```
+/n-llm-patch підготуй для проекту @nitra/eslint-config щоб він врахував останню версію node
+```
+
+## Workflow
+
+1. **Розпарсити аргумент** — виокремити суть завдання та (якщо є) назву
+   пакета / шлях. Аргумент = намір користувача, передається у промпт
+   як розділ "Завдання".
+
+2. **Зібрати read-only контекст з CWD — мінімум, потрібний для опису
+   інтенту й покажчиків:**
+   - `package.json` — лише поля, релевантні до завдання (напр., для "node"
+     — `engines`, `name`, `version`; для "eslint" — `peerDependencies`,
+     `exports`). Не читай поля, які потім не з'являться у промпті.
+   - Структура репо — швидкий огляд (`ls` верхнього рівня), щоб згадати
+     **тип** ("монорепо bun з 7 workspaces" — рядком, не дампом).
+   - **Релевантні файли** — відкривай саме ті, що потрібні щоб знайти
+     `file:line` покажчики на точки правки. Не читай "про запас".
+   - `CLAUDE.md` / `.cursor/rules/*.mdc` — лише **перевір наявність**
+     і назви файлів-правил, які стосуються завдання (LLM прочитає сама).
+
+3. **Визначити "точку патчу"** — 1-5 `path:line` покажчиків на місця, які
+   найімовірніше треба правити, з одним рядком пояснення на кожен.
+
+4. **Сформувати промпт за шаблоном нижче.** Цитуй код **тільки** коли він
+   зовнішній (stderr, лог CI) або уже видалений. Існуючий код у CWD не
+   цитуй — давай `path:line` ref.
+
+5. **Прорахуй cut list:** перед видачею пройдись по секції "Що **не**
+   включати" вище і видали все, що цільова LLM може отримати з 2-3
+   `Read`/`Grep`-викликів у своєму CWD.
+
+6. **Вивести один markdown-блок у чат** — без додаткових коментарів
+   поза блоком, окрім однорядкового підпису "готово до копіювання".
+
+## Шаблон вихідного промпта
+
+Тільки секції, які несуть навантаження. Порожніх не залишай. Зразок:
+
+````markdown
+```markdown
+# Завдання
+
+<1-3 речення: що треба і яка причина (баг / новий стек / requirement).
+Якщо bugfix — вкажи симптом одним рядком.>
+
+# Симптом / репро
+
+<тільки для bugfix: точна команда + ключовий рядок stderr/exit code.
+Пропусти секцію, якщо не bugfix.>
+
+# Точки правки
+
+- `path/to/file.mjs:120` — <одне речення: що тут не так / що зробити>
+- `path/to/other.mjs:34-50` — <…>
+
+# Що треба зробити
+
+<бажана поведінка input → output, edge cases, без псевдо-коду й
+покрокових імплементаційних підказок. 3-8 буллетів.>
+
+# Обмеження
+
+<тільки реальні, не виводяться з коду: версії у репо-споживачі, breaking-change політика, inflight-міграції. Пропусти секцію, якщо їх нема.>
+
+# Як перевірити
+
+- `<команда>` — <специфічний до завдання сигнал успіху>
+```
+````
+
+### Контр-приклад (так робити не треба)
+
+- Секція `# Контекст проєкту` з name/version/stack/docs — LLM прочитає
+  `package.json` сама за 1 виклик.
+- `## Структура (skim)` з `tree -L 2` дампом — шум.
+- `## package.json` з повним JSON — досить рядка про конкретне поле
+  у `Що треба зробити` або `Обмеження`.
+- `## <функція>` з 30 рядками існуючого коду — давай `path:line` ref
+  у `Точки правки`.
+- Покрокові підказки з кодом ("крок 1: import X, крок 2: split…") —
+  опиши поведінку, код напише LLM.
+
+## Правила
+
+- **Мова промпту:** українська за замовчуванням; якщо аргумент англійською —
+  можна англійською. Технічні терміни — англійською.
+- **Обсяг:** прагни до **30-100 рядків**. Якщо вийшло більше — пройдись
+  по cut list і викинь усе, до чого LLM додумається з кількох
+  `Read`/`Grep`. Більше 150 рядків — майже завжди ознака, що ти цитуєш
+  код, який LLM прочитає сама.
+- **Без галюцинацій:** не вигадуй полів `package.json`, версій, шляхів,
+  номерів рядків — лише те, що реально прочитав з CWD. Якщо чогось
+  бракує — явно так і напиши ("`engines.node` відсутнє").
+- **Без імперативного тону до користувача:** промпт адресований **іншому
+  агенту**, не людині. Використовуй "зроби", "онови", "додай".
+- **Без секцій-пустушок:** якщо немає `Обмежень` чи `Симптому` — пропусти
+  секцію цілком.
+- **Без ручного changelog/version у промпті:** не формулюй у виводі інструкції
+  на кшталт "додати запис у `CHANGELOG.md`", "bump `version` вручну" чи
+  "оновити `package.json#version`". Зміни у workspace фіксуються винятково
+  через change-file flow (`npx @7n/n ch` → `npx @7n/rules lint changelog`);
+  `version`/`CHANGELOG.md` формує CI.
+- **Не вмикай у промпт:** секрети, `.env`, `node_modules`, бінарні файли,
+  довгі логи, дампи `tree`, повні JSON конфігів, цитати існуючих
+  helpers/функцій з CWD.
+- **Усе в одному блоці:** результат — це **один** ` ```markdown ` блок;
+  ніяких додаткових міркувань поза ним (крім фінального підпису
+  "готово до копіювання").
+
+## Що скіл **не** робить
+
+- Не завантажує tarball з npm registry, не клонує git-репозиторії.
+- Не редагує жоден файл у поточному проєкті (і поза ним).
+- Не виконує сам "патч" — лише готує промпт для іншого агента.
+- Не оптимізує під Gemini / GPT — лише Claude / Cursor agent.
+
+## Приклад виклику й результату
+
+Виклик:
+
+```
+/n-llm-patch у @nitra/eslint-config підняти engines.node до >=25
+```
+
+Очікуваний вивід:
+
+````markdown
+```markdown
+# Завдання
+
+Підняти `engines.node` у `@nitra/eslint-config` з `>=22` до `>=25`,
+переконатися що peer `eslint ^9` сумісний з Node 25.
+
+# Точки правки
+
+- `package.json:18` — `engines.node`
+
+# Що треба зробити
+
+- Підняти `engines.node` до `>=25`; якщо peer `eslint ^9` несумісний —
+  підняти range.
+- Зафіксувати зміну change-файлом (НЕ редагувати `CHANGELOG.md` чи `version`
+  вручну): `npx @7n/n ch --bump minor --section Changed --message "engines.node >=25"`.
+
+# Обмеження
+
+- Дотриматись `.cursor/rules/n-js.mdc` і `.cursor/rules/n-changelog.mdc`
+  (зміни у workspace = change-файл, не ручний CHANGELOG/version bump).
+- Якщо `eslint ^9` офіційно не підтримує Node 25 — підняти peer range.
+
+# Як перевірити
+
+- `bun test` — зелений
+- `node -p "require('./package.json').engines.node"` → `>=25`
+- `npx @7n/rules lint changelog` → exit `0`
+```
+````
+
+```
+готово до копіювання — встав у чат з агентом у цільовому проєкті
+```

package/skills/llm-patch/main.json

@@ -0,0 +1 @@
+{ "auto": "завжди", "worktree": false, "requireRoot": false }

package/skills/publish-telegram/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: n-publish-telegram
+description: >-
+  Підготовка матеріалу з поточного контексту для публікації в Telegram-каналі команди
+version: '1.0'
+---
+
+# Публікація в Telegram
+
+Підготовка матеріалу для публікації в Telegram-каналі команди (розробники + менеджери).
+
+## Формат Telegram
+
+Telegram підтримує Markdown-форматування безпосередньо в клієнті:
+
+- `**bold**` — жирний (заголовки, мітки секцій)
+- `_italic_` — курсив (акценти)
+- `` `inline code` `` — inline-код, команди, назви файлів/пакетів
+- ` ```block``` ` (потрійні backticks) — блок коду, коли є реальний код
+- `~~strikethrough~~` — закреслення (опціонально)
+
+Секції (Проблема:, Рішення: тощо) виділяй `**жирним**`. Технічні терміни (назви файлів, пакетів, команди) — в `` `inline code` ``.
+
+## Workflow
+
+1. **Визнач контекст** — проаналізуй поточну розмову: яка проблема вирішувалась, що було зроблено, який результат.
+
+2. **Сформуй пост** за шаблоном нижче.
+
+3. **Виведи готовий текст** — користувач копіює його в Telegram.
+
+## Шаблон посту
+
+```
+#тег
+
+📌 **<Короткий заголовок>**
+
+**Проблема:**
+<1-3 речення — що було не так / яке завдання>
+
+**Рішення:**
+<2-5 речень — що зробили, який підхід>
+
+**Деталі:**
+• <ключовий момент 1>
+• <ключовий момент 2>
+• <ключовий момент 3>
+
+**Результат:**
+<1-2 речення — що отримали, яка вигода>
+```
+
+Тег (один хештег першим рядком поста) — підбір за темою:
+
+- якщо публікація стосовно AI, то `#ai`
+- якщо публікація стосовно npm модуля, то `#npm`
+- якщо публікація стосовно розробки, то `#dev`
+- якщо публікація стосовно інфраструктури, скриптів, налаштувань, ефективності коду чи безпеки, то `#sre`
+
+## Правила
+
+- Мова: українська, технічні терміни — англійською
+- Обсяг: 500–1500 символів (оптимально для Telegram)
+- Без зайвих вступів і водянистих фраз
+- Конкретика: назви файлів, бібліотек, команд — якщо доречно
+- Тег: рівно 1 хештег першим рядком поста (#devops, #frontend, #bugfix, #refactoring, #CI, #performance тощо)
+- Emoji: лише структурні (📌 для заголовка, • для списку), не перевантажувати
+- Цільова аудиторія: розробники та менеджери — тому пояснюй простою мовою, без надмірного жаргону
+- Назви файлів, пакетів, команди — у `` `inline code` ``
+- Блок коду (потрійні backticks) — лише якщо є реальний код/конфіг, не для всього тексту
+
+## Приклад
+
+```
+#dev
+
+📌 **Міграція з Prettier на oxfmt**
+
+**Проблема:**
+Prettier повільно форматував великі файли і конфліктував з ESLint при роботі з Vue SFC.
+
+**Рішення:**
+Замінили Prettier на `oxfmt` — нативний форматер від OXC. Оновили VS Code settings, видалили prettier-конфіги, додали `.oxfmtrc.json`.
+
+**Деталі:**
+• `oxfmt` працює в 10-50x швидше за Prettier
+• Єдиний конфіг `.oxfmtrc.json` у корені
+• CI перевіряє форматування через `lint-js`
+
+**Результат:**
+Форматування працює миттєво при збереженні, зникли конфлікти між форматером і лінтером.
+```

package/skills/publish-telegram/main.json

@@ -0,0 +1 @@
+{ "auto": "завжди", "worktree": false, "requireRoot": false }

package/skills/taze/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: n-taze
+description: >-
+  Оновлення версій модулів проекту з аналізом major-змін і автоматичним
+  рефакторингом несумісного коду
+version: '1.0'
+---
+
+# n-taze — Оновлення версій проекту
+
+## Мета
+
+Оновити всі модулі проекту до останніх версій, виявити major-оновлення, перевірити сумісність змін з кодом проекту і за потреби зрефакторити несумісні місця.
+
+## Передумови
+
+- Чисте робоче дерево (`git status` без незакомічених змін у `package.json` / `bun.lock` / `node_modules`) — інакше різницю не відрізнити від оновлення.
+- Встановлений `bun` і доступний `bunx`.
+- Запуск з кореня проекту (де лежить `package.json` / `bun.lock`).
+
+## Workflow
+
+### 1. Зафіксувати стартовий стан
+
+Перед оновленням зберегти список поточних версій, щоб потім обчислити, які модулі стрибнули через major:
+
+```bash
+cp package.json package.json.taze-bak
+cp bun.lock bun.lock.taze-bak
+```
+
+(У monorepo — також усі `*/package.json` воркспейсів. Файли тимчасові, видалити в кінці.)
+
+### 2. Запустити оновлення
+
+```bash
+bunx taze -w -r latest
+bun install
+```
+
+- `-w` — записати нові версії у `package.json`.
+- `-r` — рекурсивно по всіх воркспейсах.
+- `latest` — піднімати навіть major.
+
+### 3. Виявити major-оновлення
+
+> **Не порівнюй `package.json` вручну.** Класифікацію semver несе CLI — детерміновано, по всіх воркспейсах.
+
+```bash
+n-rules taze diff
+```
+
+Друкує компактний JSON: `{ "major": [{workspace, pkg, from, to}], "minorPatch": <N>, "totalChanged": <N> }`. `major` — список залежностей, у яких змінилась найлівіша ненульова компонента semver (`1.x→2.x`, `0.4.x→0.5.x`, `0.0.3→0.0.4`); саме він іде в кроки 4–6. `minorPatch` — лічба сумісних (для звіту в кроці 8).
+
+Покриває **прямі** залежності з `package.json` (root + воркспейси). Транзитивні major-стрибки (`bun.lock`) — за потреби переглянь окремо; основний ризик breaking-змін — у прямих.
+
+### 4. Зібрати breaking changes по кожному major-оновленню
+
+Для кожного модуля зі списку зібрати фактичні відмінності одним з джерел (у порядку пріоритету):
+
+1. **CHANGELOG / Releases репозиторію модуля** — найшвидше і найточніше. Адресу репозиторію взяти з `package.json` модуля у `node_modules/<name>/package.json` (поле `repository`). Дістати релізи між старою і новою версією.
+2. **Git-різниця в `node_modules/<name>`** — якщо CHANGELOG відсутній або неінформативний, порівняти попередню версію (з кешу bun: `~/.bun/install/cache/<name>@<old-version>/`) з новою (`node_modules/<name>/`) через `diff -r` по `dist/` / `*.d.ts` / публічних entry-points з `exports`.
+3. **Якщо немає кешованої старої версії** — встановити її окремо в тимчасову теку (`mkdir -p /tmp/taze-old && cd /tmp/taze-old && bun add <name>@<old-version>`) і порівняти.
+
+Цікавлять: видалені/перейменовані експорти, змінені сигнатури функцій, змінені типи, змінена поведінка за замовчуванням, видалені CLI-прапорці.
+
+### 5. Перевірити сумісність з кодом проекту
+
+Для кожного breaking change знайти його використання в коді проекту:
+
+```bash
+rg -n "<імпорт|функція|опція>" --type ts --type js --type vue
+```
+
+Класифікувати:
+
+- **сумісно** — проект не використовує зачеплене API → нічого не робити.
+- **несумісно** — використання знайдено → перейти до п. 6.
+
+### 6. Рефакторинг несумісних місць
+
+Для кожного несумісного місця — застосувати міграцію згідно з changelog модуля (перейменувати імпорт, оновити сигнатуру виклику, замінити видалену опцію еквівалентом тощо). Після правок:
+
+```bash
+npx @7n/rules lint
+bun run typecheck   # якщо є
+bun test            # якщо є
+```
+
+Якщо міграція нетривіальна або неоднозначна — **не вгадувати**, залишити TODO у коді з посиланням на CHANGELOG і винести в підсумковий звіт як ручну дію.
+
+### 7. Прибрати тимчасові файли
+
+```bash
+rm package.json.taze-bak bun.lock.taze-bak
+```
+
+(І решту бекапів воркспейсів, якщо створювались.)
+
+### 8. Звіт користувачу
+
+Коротко в одному повідомленні:
+
+- **Оновлено (minor/patch):** кількість пакетів (`minorPatch` із кроку 3), без деталей.
+- **Major-оновлення:** список `<name>: <old> → <new>` з посиланням на release notes.
+- **Зрефакторено автоматично:** список файлів і коротко що саме змінено.
+- **Потребує ручного втручання:** список TODO з причиною (нетривіальна міграція / неоднозначність / падіння тестів).
+- **Стан перевірок:** `lint` / `typecheck` / `test` — pass/fail з номером рядка, де впало.
+
+## Примітка
+
+- Не запускати `npx @7n/rules lint` паралельно з іншими ESLint-задачами — діє правило з кореневого `CLAUDE.md`.
+- Якщо проект — `npm/` пакет цього репо, після змін у `package.json` / коді треба підняти `version` і додати запис у `CHANGELOG.md` згідно з `npm/CLAUDE.md`.
+- При великій кількості major-оновлень розбити PR по одному модулю на коміт — щоб `git bisect` залишався корисним.