@nitra/cursor 1.13.74 → 1.13.75

package/CHANGELOG.md

@@ -4,6 +4,13 @@
 
 Формат — [Keep a Changelog](https://keepachangelog.com/uk/1.1.0/), нумерація — [SemVer](https://semver.org/lang/uk/).
 
+## [1.13.75] - 2026-05-22
+
+### Removed
+
+- **Скіли `abie-clean` та `abie-kustomize`** прибрано з пакета — abie-специфічні скіли перенесено до `@nitra/abie-docs` і перейменовано на `clean` / `kustomize` (запуск через `npx @nitra/abie-docs skill <id>`). Автоактивація цих скілів за правилом `abie` більше не діє. Зачеплено: [auto-skills.mjs](scripts/auto-skills.mjs), [auto-skills.test.mjs](scripts/auto-skills.test.mjs), `skills/abie-clean/`, `skills/abie-kustomize/`.
+- **Скіл `efes-create-env`** прибрано з пакета — efes-специфічний скіл перенесено до `@nitra/efes-docs` і перейменовано на `create-env` (запуск через `npx @nitra/efes-docs skill create-env`). Автоактивація за правилом `efes` більше не діє. Зачеплено: [auto-skills.test.mjs](scripts/auto-skills.test.mjs), `skills/efes-create-env/`.
+
 ## [1.13.73] - 2026-05-21
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nitra/cursor",
-  "version": "1.13.74",
+  "version": "1.13.75",
   "description": "CLI для завантаження cursor-правил (префікс n-) у локальний репозиторій",
   "keywords": [
     "cli",
@@ -43,6 +43,7 @@
   "types": "./types/bin/n-cursor.d.ts",
   "scripts": {
     "test": "bun test",
+    "start": "bun ./bin/n-cursor.js",
     "rename-yaml-extensions": "bun ./bin/n-cursor.js rename-yaml-extensions"
   },
   "dependencies": {

package/scripts/auto-skills.mjs

@@ -6,7 +6,7 @@
  *  - `завжди` — скіл активується незалежно від інших правил
  *    (приклади: `fix`, `lint`, `llm-patch`, `publish-telegram`).
  *  - `[rule, rule, …]` — скіл активується, якщо ВСІ перелічені правила вже виявлені
- *    auto-rules (приклади: `abie-clean - [abie]`, `taze - [bun]`).
+ *    auto-rules (приклади: `adr-normalize - [adr]`, `taze - [bun]`).
  *  - файл відсутній або формат не розпізнано — скіл opt-in лише через `.n-cursor.json:skills`.
  *
  * Сканування `npm/skills/` — sync під час завантаження модуля (детермінізм + sync API

package/skills/start-check/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: n-start-check
+description: >-
+  Smoke-перевірка bun-монорепо: зайти в кожен воркспейс зі `start`-скриптом, прогнати
+  `start` і зафіксувати, чи проєкт взагалі запускається без негайного краху
+---
+
+# n-start-check — чи запускається кожен воркспейс
+
+## Мета
+
+Прогнати `start`-скрипт у кожному воркспейсі bun-монорепо й зафіксувати, чи проєкт **взагалі стартує**. Це smoke-перевірка: ціль — спіймати негайний крах (синтаксична помилка, відсутній модуль, падіння на старті), а не протестувати поведінку.
+
+## Передумови
+
+- Bun-монорепо: кореневий `package.json` має поле `workspaces`.
+- Залежності встановлені (`bun i`) — інакше `start` упаде на відсутньому модулі, а не на реальній проблемі.
+- Запуск з кореня репозиторію (де лежить кореневий `package.json` / `bun.lock`).
+
+## Workflow
+
+### 1. Зібрати список воркспейсів
+
+Прочитай поле `workspaces` з кореневого `package.json`. Воно може містити glob-патерни (`packages/*`, `apps/*`) — розгорни кожен у конкретні директорії. Для кожної директорії прочитай її `package.json`.
+
+### 2. Відфільтрувати воркспейси зі `start`-скриптом
+
+Воркспейс перевіряється, лише якщо в його `package.json` є `scripts.start`. Решту — пропусти й познач у звіті як `SKIP (немає start)`.
+
+### 3. Класифікувати `start` і зафіксувати стан репо
+
+Скіл прогоняє **кожен** воркспейс зі `start` — запуск не пропускається. Але `start` буває двох типів, і це впливає і на трактування коду виходу, і на ризик побічних ефектів:
+
+- **Запуск сервера/застосунку** (`vite`, `next dev`, `nuxt dev`, `node`/`bun <server>`, `nodemon` тощо) — успіх визначається за живучістю процесу.
+- **CLI/разова дія** (зокрема ті, що мутують репо — sync, генерація коду, міграції, розгортання, перезапис конфігів) — успіх визначається за кодом виходу; такий `start` може **виконати реальну роботу** й лишити зміни в репозиторії.
+
+Щоб прогін мутаційного `start` не лишив сміття, зафіксуй стан робочого дерева **перед** запусками:
+
+```bash
+git status --porcelain > /tmp/n-start-check.before
+```
+
+Цей знімок — база, щоб відкотити побічні ефекти (крок 5).
+
+### 4. Прогнати `start` послідовно
+
+Запускай воркспейси **по черзі, НЕ паралельно**: dev-сервери конфліктують за портами, а послідовний прогон дає однозначну причину краху.
+
+`start` буває двох типів — скіл має їх розрізняти:
+
+- **Довгий процес** (dev-сервер, демон): успіх = процес живий через grace-період без краху. Бажано дочекатися рядка готовності в логу (`ready`, `listening`, `Local:`, `started` тощо).
+- **Короткий процес** (CLI, разова дія): успіх = вихід із кодом `0`.
+
+macOS не має `timeout` як стандартної утиліти. Обмеж час через `perl` + `alarm`: `alarm` зводить SIGALRM, а `exec` зберігає той самий PID, тож таймер спрацьовує на справжньому процесі й знімає його після grace-періоду:
+
+```bash
+cd <workspace-dir>
+perl -e 'alarm shift; exec @ARGV' 12 bun run start > /tmp/n-start-check.log 2>&1
+CODE=$?
+```
+
+Інтерпретація `CODE`:
+
+- `142` — процес дожив до кінця grace-періоду й був знятий SIGALRM (`128 + 14`). Для **довгого процесу** (dev-сервер) це **успіх** — стартував і не впав.
+- `0` — процес завершився сам без помилки. Для **короткого процесу** (CLI, разова дія) це **успіх**.
+- будь-що інше — **FAIL**: крах або ненульовий вихід ще до кінця grace-періоду.
+
+Звір також лог: для dev-сервера — рядок готовності (`ready`, `listening`, `Local:`); для CLI — відсутність трас помилок.
+
+Альтернатива `cd` — `bun run --filter '<package-name>' start` (запуск за іменем пакета).
+
+`bun run start` прибирає свій дочірній процес при завершенні; якщо `start` у репо форкає демонів окремо — переконайся, що після перевірки нічого не лишилось висіти.
+
+### 5. Відкотити побічні ефекти прогону
+
+Після кожного запуску звір поточний `git status --porcelain` зі знімком `/tmp/n-start-check.before` і відкоти **лише те, що з'явилося через прогін**:
+
+- нові невідстежувані файли/директорії (яких не було у знімку) — видали;
+- відстежувані файли, що стали зміненими, а у знімку були чисті — `git checkout -- <path>`;
+- усе, що було брудним **до** прогону, — НЕ чіпай: це зміни користувача, не пов'язані з прогоном.
+
+Gitignored-артефакти (кеші, `node_modules`, логи) у `git status` не з'являються — їх чіпати не треба. Коли побічні ефекти прибрано, дерево повертається до стану знімка, тож наступний воркспейс стартує з чистої бази.
+
+### 6. Зафіксувати результат
+
+Для кожного воркспейсу — статус і примітка:
+
+- `OK` — стартував (живий dev-сервер або вихід `0`).
+- `FAIL` — крах або ненульовий код. Додай витяг із логу: останні значущі рядки з помилкою.
+- `SKIP` — у воркспейсі немає `start`-скрипта (крок 2). Сам запуск `start` не пропускається.
+
+Якщо мутаційний `start` лишив побічні ефекти (крок 5) — познач це в примітці: проєкт стартує, але `start` не є чистим запуском сервера.
+
+Розрізняй у звіті **помилку коду** (синтаксис, відсутній імпорт, падіння при ініціалізації) і **середовищний збій** (немає `.env`, недоступна БД/сервіс, зайнятий порт) — останній не означає, що проєкт зламаний.
+
+### 7. Звіт
+
+Підсумкова таблиця: `воркспейс | статус | примітка`. Якщо є хоч один `FAIL` — винеси його окремо й покажи помилку повністю.
+
+Скіл лише **діагностує** запуск. Виправлення коду — поза скоупом; якщо причина FAIL очевидна, познач її у звіті, але не правь, поки про це не попросять окремо.

package/skills/start-check/auto.md

@@ -0,0 +1 @@
+[bun]

package/skills/abie-clean/SKILL.md

@@ -1,216 +0,0 @@
----
-name: n-abie-clean
-description: >-
-  Очистка проєкту від ru-середовища: гілка `ru`, директорії `ru/`, файли з суфіксом
-  `-ru`/`values-ru.*`, гілки `endsWith(...'ru')` у GitHub Actions, ru-умови у
-  Dockerfile/nginx, посилання на `cr.yandex` та раннер `ya`
-version: '1.1'
----
-
-Скіл прибирає з проєкту все, що належить **ru-середовищу**. Залишаються тільки `dev` (як база) та `ua` як активне продакшн-середовище. Працюй послідовно по секціях нижче — після кожної секції перевіряй, що проєкт лишається консистентним (`kustomization.yaml` посилається лише на наявні файли, GitHub Actions-вирази синтаксично коректні).
-
-## 0. Що НЕ чіпати
-
-**`node_modules/`** (і будь-які `**/node_modules/`) — повністю виключаються з аналізу й модифікацій. Це згенеровані залежності: збіги на `ru`, `values-ru.*`, `cr.yandex` тощо там нерелевантні і відновляться при наступному `install`. Усі `find` / `git grep` / автозаміни мають пропускати ці шляхи. Аналогічно не чіпай `.git/`, `dist/`, `build/`, `.next/`, `.nuxt/`, `.output/`, `coverage/`.
-
-## 1. Директорії з назвою `ru`
-
-Видали всі директорії з назвою `ru` у проєкті (крім тих, що всередині `node_modules`):
-
-```bash
-find . -type d \( -name node_modules -o -name .git \) -prune -o -type d -name "ru" -print -exec rm -rf {} +
-```
-
-Це чистить як `country/ru/`, так і `k8s/<...>/ru/` (overlay у kustomize). Після видалення overlay `ru/` обов’язково прибери відповідний запис у `resources:` у батьківському `kustomization.yaml`, якщо він там лишився.
-
-## 2. Файли з ru-суфіксом
-
-Видали файли, у назві яких є явний ru-маркер:
-
-- `values-ru.ini`, `values-ru.yaml`, `values-ru.*` (Helm/абстракції values на середовище)
-- будь-які файли, що закінчуються на `-ru` або `-ru.<ext>`, наприклад `site/.env.prod-ru`, `*.env.prod-ru`, `*.prod-ru.conf`
-
-```bash
-find . -type d \( -name node_modules -o -name .git \) -prune -o \
-  -type f \( -name "values-ru.*" -o -name "*-ru" -o -name "*.prod-ru" -o -name "*.prod-ru.*" \) -print -delete
-```
-
-## 3. `.github/workflows/*.yml`
-
-### 3.1. Тригери `on.push.branches`
-
-Прибирай `ru` зі списку гілок.
-
-Було:
-
-```yaml
-on:
-  push:
-    branches: [dev, ru, ua]
-```
-
-Стало:
-
-```yaml
-on:
-  push:
-    branches: [dev, ua]
-```
-
-### 3.2. Тернарні вирази `endsWith(github.ref_name, …)`
-
-У ланцюжках `endsWith(...)` залишай тільки гілки `dev` та `ua`. Гілку `ru` (а також пов’язаний з нею fallback на раннер `ya`, реєстр `cr.yandex/...`, NATS `cluster.local` тощо) — прибирай. Останнє значення в ланцюжку стає fallback’ом для всього, що не `dev`.
-
-`runs-on` — було:
-
-```yaml
-runs-on: ${{ endsWith(github.ref_name, 'dev') && 'dev' || ( endsWith(github.ref_name, 'ua') && 'ua' || 'ya' ) }}
-```
-
-Стало:
-
-```yaml
-runs-on: ${{ endsWith(github.ref_name, 'dev') && 'dev' || 'ua' }}
-```
-
-`NATS_URL` — було:
-
-```yaml
-NATS_URL: ${{ endsWith(github.ref_name, 'dev') && 'nats.nats.svc.abie-dev.internal:4222' || ( endsWith(github.ref_name, 'ua') && 'nats.nats.svc.abie-ua.internal:4222' || 'nats.nats.svc.cluster.local:4222' ) }}
-```
-
-Стало:
-
-```yaml
-NATS_URL: ${{ endsWith(github.ref_name, 'dev') && 'nats.nats.svc.abie-dev.internal:4222' || 'nats.nats.svc.abie-ua.internal:4222' }}
-```
-
-`NATS_STREAM` — було:
-
-```yaml
-NATS_STREAM: ${{ endsWith(github.ref_name, 'dev') && 'dev' || ( endsWith(github.ref_name, 'ua') && 'ua' || 'ru' ) }}
-```
-
-Стало:
-
-```yaml
-NATS_STREAM: ${{ endsWith(github.ref_name, 'dev') && 'dev' || 'ua' }}
-```
-
-`REGISTRY` — було:
-
-```yaml
-REGISTRY: ${{ endsWith(github.ref_name, 'ru') && 'cr.yandex/crpaerfcq9t16fse5onm' || ( endsWith(github.ref_name, 'ua') && 'europe-west4-docker.pkg.dev/abie-ua/c' || 'europe-north1-docker.pkg.dev/abie-dev/c' ) }}
-```
-
-Стало:
-
-```yaml
-REGISTRY: ${{ endsWith(github.ref_name, 'ua') && 'europe-west4-docker.pkg.dev/abie-ua/c' || 'europe-north1-docker.pkg.dev/abie-dev/c' }}
-```
-
-Загальне правило: у фінальному виразі мають лишитися лише `endsWith(github.ref_name, 'dev')` та `endsWith(github.ref_name, 'ua')` (або лише один із них, якщо середовище одне). Будь-яка згадка `'ru'`, `'ya'`, `cr.yandex`, `cluster.local`-fallback для ru — прибирається.
-
-### 3.3. `ignore_branches` / `branches-ignore`
-
-У всіх workflow-файлах та конфігах (включно з тими, що використовуються правилом **abie** `clean_merged_ignore_branches`) прибирай `ru` зі списків ignore-гілок.
-
-## 4. Dockerfile / nginx / build-скрипти
-
-Прибирай умовні гілки `if [ "$BRANCH" = "ru" ]; then …` та копіювання `country/ru/*`. Лишається лише той код, що працює для `dev`/`ua`.
-
-Було:
-
-```dockerfile
-RUN if [ "$BRANCH" = "ru" ]; then cp -r country/ru/* public/ || true; fi && \
-    bun install && \
-    if [ "$BRANCH" = "ru" ]; then BASE="/itool/"; else BASE="/contract/"; fi && \
-    bun vite build --mode "prod-$BRANCH" --base="$BASE"
-```
-
-Стало:
-
-```dockerfile
-RUN bun install && bun vite build --mode "prod-$BRANCH" --base="$BASE"
-```
-
-Те саме стосується `nginx`-конфігів (`server_name`, `proxy_pass` з ru-доменами), `*.sh`-скриптів та `package.json` scripts (`build:ru`, `deploy:ru`, `prod-ru` тощо).
-
-## 5. Переклади
-
-Замінити переклад з російської на англійську в @nitra/tfm, @nitra/tf та @nitra/tfm-node. Якщо англійська вже є, то прибираємо російську:
-
-Приклад БУЛО:
-
-```vue
-<template>
-  <h5>{{ t`Привіт` }}</h5>
-</template>
-
-<script setup>
-import tf from '@nitra/tf/webpack'
-
-// Translate
-const tr = {
-  Привіт: 'Привет'
-}
-
-const t = tf.bind({ tr })
-</script>
-```
-
-СТАЛО:
-
-```vue
-<template>
-  <h5>{{ t`Привіт` }}</h5>
-</template>
-
-<script setup>
-import tf from '@nitra/tf/webpack'
-
-// Translate
-const tr = {
-  Привіт: 'Hello'
-}
-
-const t = tf.bind({ tr })
-</script>
-```
-
-або
-
-import { tf } from '@nitra/tfm'
-
-const tr = {
-Так: { ru: 'Да' },
-Ні: { ru: 'Нет' }
-}
-
-на
-
-import { tf } from '@nitra/tfm'
-
-const tr = {
-Так: { ru: 'Yes' },
-Ні: { ru: 'No' }
-}
-
-### 5.1. Апострофи та спецсимволи в рядках перекладу
-
-Український текст рідко містить апостроф у сенсі JS-рядка; у **англійських** перекладах часті скорочення з `'` (`today's`, `can't`, `don't`, `you're` тощо). Після кожної зміни `tr` переглянь результат на символи `'`, `"` та `\` і переконайся, що **роздільники рядка** парсяться коректно.
-
-**Одинарні лапки.** Якщо англійський переклад містить апостроф і рядок обгорнуто в `'…'`:
-
-- **Неправильно:** `'today\\'s route'` — подвійний backslash + кінець рядка, синтаксична помилка.
-- **Правильно:** `'today\'s route'` — один backslash екранує апостроф.
-- **Краще:** `"today's route"` — подвійні лапки, екранування не потрібне.
-
-**Безпечне правило:** якщо в англійському перекладі є апостроф — переходь на **подвійні** лапки як роздільник рядка.
-
-## 6. Після очистки
-
-- Переконайся, що `kustomization.yaml` у кожній директорії `k8s/` не посилається на видалені overlay або файли.
-- Пройдись `git grep` по репозиторію на залишки: `git grep -n -i -e '\bru\b' -e cr\.yandex -e country/ru -e prod-ru -e values-ru -e "'ya'"` — переглянь усі знахідки вручну, бо `ru` як слово може траплятися в легітимних контекстах (наприклад, `truncate`, `Aurum`, `cruft`). Видаляй лише ті входження, що належать ru-середовищу. `git grep` за замовчуванням пропускає невідстежувані шляхи, тож `node_modules/` у вихід не потрапить, поки воно у `.gitignore`.
-- Перевір CI локально: `npx @nitra/cursor check abie` (якщо правило **abie** ввімкнене у проєкті).
-- Після змін у вихідних файлах (особливо рядках перекладу) переконайся, що збірка **компілюється**: `bun vite build` у корені відповідного пакета (або там, де в проєкті налаштований Vite). Синтаксична помилка в об’єкті `tr` ламає всі три CI-пайплайни (android, ios, site) — локальний build ловить її до коміту.

package/skills/abie-clean/auto.md

@@ -1 +0,0 @@
-[abie]

package/skills/abie-kustomize/SKILL.md

@@ -1,75 +0,0 @@
----
-name: n-abie-kustomize
-description: >-
-  Трансформація дерев k8s у Kustomize (base + overlays): dev → base, без окремої dev/; директорія
-  users/ у середовищах не входить у kustomization (окремі маніфести між середовищами); дерево з
-  CNPG Cluster (postgresql.cnpg.io/v1) не трансформувати
-version: '1.2'
----
-
-Спочатку знайди всі директорії `k8s/` у проєкті. Виконуй трансформацію лише для тих, у яких **немає** директорії `base/`. Якщо `base/` вже існує — пропускай цю директорію і рухайся далі.
-
-Якщо в дереві тієї директорії `k8s/`, яку збираєшся трансформувати (рекурсивно по `*.yaml`), є маніфест з **`apiVersion: postgresql.cnpg.io/v1`** і **`kind: Cluster`** (CloudNativePG) — **не застосовуй** до цього дерева описану трансформацію base/overlays: залиш структуру як є і переходь до наступної директорії `k8s/`.
-
-Трансформуй директорії, щоб виділити спільне за допомогою kustomize. За основу беремо все, що в середовищі dev, і саме в такому вигляді з dev воно має стати **base**; якщо вже є base і немає dev — це нормально, рухайся далі.
-
-У інших середовищах має бути лише `kustomization.yaml` і зміни через оверрайди.
-
-У **base** у всіх ресурсів (окрім `base/kustomization.yaml`) має бути namespace **dev**.
-
-Окремої директорії **dev** не має бути — за середовище dev відповідає **base**.
-
-README має бути в директорії **k8s**.
-
-Рядки в маніфестах у **base**, які змінюватимуться в інших середовищах, позначай коментарем на тому самому рядку: `# буде замінено через kustomize`.
-
-Патчів лише на namespace не роби — namespace задається в `kustomization.yaml`.
-
-Застарілі файли прибирай.
-
-Для overlay **ua** `namespace` задавай у `kustomization.yaml` (без окремих patch лише на зміну namespace). Деталі — **n-k8s** / **abie** у `.cursor/rules/`, якщо ці правила увімкнені в проєкті.
-
-## Виключення: CNPG `Cluster`
-
-Ресурс **`Cluster`** оператора CloudNativePG (`postgresql.cnpg.io/v1`) має власні правила життєвого циклу та іменування; шаблон «dev → base + overlays» для нього не застосовується.
-
-## Виключення: директорії `users/`
-
-Директорія `users/` у кожному середовищі — **окремий шар маніфестів**, який **не входить у Kustomize**. Так зроблено навмисно: вміст часто **різний між середовищами**, тож немає сенсу виносити його в `base` чи патчити через overlays.
-
-Правила:
-
-- Файли з `users/` **не додавай** до жодного `kustomization.yaml` (ні `base`, ні overlay) — вони **не підключаються** до kustomize.
-- Директорію `users/` **не переміщуй** у `base` — вона **залишається** в своєму середовищі (`dev`, `ua`, інше overlay тощо), поруч з `kustomization.yaml` цього середовища (або після рефакторингу — поруч з overlay, де вона була логічно прив’язана).
-- У файлах у `users/` **може не бути** `metadata.namespace` — це нормально, **не нав’язуй** namespace лише заради kustomize.
-- Якщо `users/` є в кількох середовищах з різним набором файлів (наприклад, 29 yaml у одному й інша кількість в іншому) — **залишай незалежними**, не намагайся уніфікувати через base.
-
-Приклад **до** трансформації (фрагмент):
-
-```
-k8s/db/
-├── dev/                         # namespace: dev
-│   ├── kustomization.yaml
-│   ├── cluster-db.yaml          # instances: 1, поля з # буде замінено через kustomize
-│   ├── secret-auth.yaml
-│   └── secret-source-db.yaml
-└── ua/                          # або інше середовище
-    ├── kustomization.yaml
-    └── users/
-        └── *.yaml               # без metadata.namespace; не в kustomization.resources
-```
-
-Приклад **після** трансформації (той самий принцип для `users/`):
-
-```
-k8s/db/
-├── base/
-│   ├── kustomization.yaml
-│   ├── cluster-db.yaml          # namespace: dev, поля з # буде замінено через kustomize
-│   ├── secret-auth.yaml
-│   └── secret-source-db.yaml
-└── ua/
-    ├── kustomization.yaml       # namespace, patches — без users/
-    └── users/                   # лишається тут; kustomize їх не бачить
-        └── *.yaml
-```

package/skills/abie-kustomize/auto.md

@@ -1 +0,0 @@
-[abie]

package/skills/efes-create-env/SKILL.md

@@ -1,185 +0,0 @@
----
-name: n-efes-create-env
-description: >-
-  Створення нового середовища (env) в репозиторії efes/manager — приймає назву
-  середовища як аргумент (наприклад `kz`, `kz-qa`, `tr-stage`, `ua-dev`).
-  Генерує .env.prod-<env>, .env.remote-<env>, оверлей site/k8s/<env>/,
-  додає скрипт start-remote-<env> у site/package.json і реєструє <env> у
-  списках branches GitHub Actions та Azure Pipelines. Якщо назва закінчується
-  на dev або -qa — non-production (база: md-qa); інакше — production (база: md).
-  Тригери: «створи середовище», «новий env», «add environment», «n-efes-create-env».
----
-
-# n-efes-create-env — створення нового середовища
-
-Скіл генерує всі конфіги для нового середовища `manager`, спираючись на існуюче як шаблон. Запуск: `/n-efes-create-env <env>` або «створи середовище `<env>`».
-
-## Існуючі середовища (станом на створення скіла)
-
-`dev` · `md` · `md-qa` · `tr` · `tr-qa`
-
-## Аргумент
-
-Назва середовища — `$ARGUMENTS` (kebab-case, без пробілів). Якщо аргументу немає — спитай користувача.
-
-## Класифікація та джерело
-
-| Закінчення      | Тип            | Базове середовище | Базовий домен               |
-| --------------- | -------------- | ----------------- | --------------------------- |
-| `dev` або `-qa` | non-production | `md-qa`           | `mayamd-qa.anadoluefes.com` |
-| інше            | production     | `md`              | `mayamd.anadoluefes.com`    |
-
-Перед роботою зафіксуй у себе:
-
-- `ENV` — `$ARGUMENTS`
-- `BASE` — `md-qa` або `md` згідно з таблицею вище
-- `BASE_DOMAIN` — домен бази
-- `DOMAIN` — `maya${ENV}.anadoluefes.com` (шаблон: префікс `maya` + env). Якщо ENV вже містить країну з дефісом (наприклад `kz-qa`) — домен буде `mayakz-qa.anadoluefes.com`. Якщо користувач хоче інший домен — підтверди.
-- `COUNTRY` — країна без суфіксу `-qa`/`-dev`/`-stage` (наприклад `kz-qa` → `kz`). Потрібно для ACR-шляхів.
-
-## Кроки
-
-### 0. Перевірити, що середовище ще не існує
-
-```bash
-test ! -f site/.env.prod-$ENV \
-  && test ! -f site/.env.remote-$ENV \
-  && test ! -d site/k8s/$ENV \
-  || { echo "Середовище $ENV вже існує — припини"; exit 1; }
-```
-
-### 1. Інтерактивне опитування — зібрати country-specific дані
-
-**ОБОВ'ЯЗКОВО** перед будь-якими `cp`/`sed` запитай користувача через `AskUserQuestion` (у Cursor — звичайним повідомленням з варіантами). Не виконуй кроки 2–5, поки не отримав усі відповіді.
-
-Запитай **одним викликом** `AskUserQuestion` із кількома запитаннями:
-
-1. **Тип середовища** — заголовок «Тип env»:
-   - «Нова країна» — env вводить нову країну (новий VITE_COUNTRY, своя SAP-tenant, свій бакет)
-   - «Новий етап існуючої країни» — env є додатковим етапом md/tr (інший суфікс, але та сама країна та tenant)
-
-2. **Домен** — заголовок «Domain»:
-   - `maya${ENV}.anadoluefes.com` (default, рекомендований)
-   - «Інший» — користувач введе власний
-
-3. **SAP-credentials** — заголовок «SAP auth»:
-   - «Залишити як у бази (`$BASE`)» — для нових етапів існуючої країни
-   - «Заглушки `TODO_SAP_*`» — для нової країни, реальні значення додасть devops/security окремим commit
-   - «Введу зараз» — користувач передасть значення в `Other` (формат: `ENDPOINT=…; CLIENT_ID=…; CLIENT_SECRET=…`)
-
-4. **Storage account (`VITE_BUCKET`)** — заголовок «Bucket»:
-   - «Залишити як у бази» — той самий storage account (`stmdmayasfaprod001`/`stmdmayasfadev001`)
-   - «Власний для нової країни» — користувач введе ім'я storage account в `Other` (наприклад `stkzmayasfaprod001`)
-
-Якщо «Нова країна» — окремо (у тому ж або наступному виклику) запитай:
-
-5. **VITE_COUNTRY** — заголовок «Country»: `md`, `tr`, інше (через `Other`)
-6. **VITE_TFM_DEFAULT** — заголовок «TFM default»: `ru`, `en`, `tr`, `ro`, інше
-7. **VITE_TFM_LIST** — заголовок «TFM list»: набір популярних варіантів (`ru,en,ro,tr`, `en,tr`, `ru,en`) + `Other`
-
-Збережи відповіді у змінні `DOMAIN`, `COUNTRY`, `TFM_DEFAULT`, `TFM_LIST`, `BUCKET_ACCOUNT`, `SAP_MODE` (`keep`/`stub`/`custom`), `SAP_VALUES` (якщо `custom`).
-
-### 2. Створити `.env.prod-$ENV` та `.env.remote-$ENV`
-
-Скопіюй файли бази:
-
-```bash
-cp site/.env.prod-$BASE   site/.env.prod-$ENV
-cp site/.env.remote-$BASE site/.env.remote-$ENV
-
-# домен
-sed -i '' "s|$BASE_DOMAIN|$DOMAIN|g" site/.env.prod-$ENV site/.env.remote-$ENV
-
-# bucket path (maya-files-<base> → maya-files-$ENV)
-sed -i '' "s|maya-files-$BASE|maya-files-$ENV|g" site/.env.prod-$ENV site/.env.remote-$ENV
-```
-
-Далі **застосуй відповіді з кроку 1** (через `Edit`):
-
-- Якщо `BUCKET_ACCOUNT` != base — заміни storage account host у `VITE_BUCKET`.
-- Якщо тип = «Нова країна»:
-  - `VITE_COUNTRY=$COUNTRY`
-  - `VITE_TFM_DEFAULT=$TFM_DEFAULT`
-  - `VITE_TFM_LIST=$TFM_LIST`
-- Якщо `SAP_MODE=stub` — заміни значення на:
-  - `VITE_SAP_AUTH_ENDPOINT=TODO_SAP_ENDPOINT`
-  - `VITE_SAP_AUTH_CLIENT_ID='TODO_SAP_CLIENT_ID'`
-  - `VITE_SAP_AUTH_CLIENT_SECRET=TODO_SAP_CLIENT_SECRET`
-- Якщо `SAP_MODE=custom` — підстав `SAP_VALUES`.
-
-Інваріанти, які мають лишитися після всіх правок:
-
-- У `.env.remote-$ENV` — `VITE_DOMAIN=localhost`, `VITE_UPLOADER=/file-link/`, `VITE_EXPORT_EXCEL=/export-table/`.
-- У `.env.prod-$ENV` — `VITE_DOMAIN=$DOMAIN`, `VITE_UPLOADER=https://$DOMAIN/file-link/`, `VITE_EXPORT_EXCEL=https://$DOMAIN/export-table/`.
-
-### 2. Створити `site/k8s/$ENV/kustomization.yaml`
-
-```bash
-mkdir -p site/k8s/$ENV
-cp site/k8s/$BASE/kustomization.yaml site/k8s/$ENV/kustomization.yaml
-```
-
-Відредагуй новий файл:
-
-- `namespace: $ENV`
-- `images[].newName`:
-  - **production** → `aefes.azurecr.io/mayasfa-$ENV/$ENV/manager-site`
-  - **non-production** → `aefes.azurecr.io/mayasfa-$COUNTRY-dev/$ENV/manager-site`
-- `HTTPRoute` патч → `hostnames: ["$DOMAIN"]`
-- Для **production** залиш блок `components: [../components]` (HPA/PDB).
-- Для **non-production** видали `components` блок і HPA/PDB-патчі (як у `md-qa`).
-
-Перевір: запусти `kubectl kustomize site/k8s/$ENV --output /dev/null` (якщо `kubectl` доступний) — має пройти без помилок.
-
-### 3. Додати `start-remote-$ENV` у `site/package.json`
-
-У секцію `"scripts"` додай рядок (зберігай порядок поряд із сусідніми `start-remote-*`):
-
-```json
-{ "scripts": { "start-remote-$ENV": "vite dev --mode remote-$ENV" } }
-```
-
-### 4. Зареєструвати `$ENV` у CI/CD branch-списках
-
-Додай `$ENV` у такі місця (зберігай існуючий порядок: dev → md-qa → md → tr → tr-qa → нові):
-
-| Файл                                        | Поле                           |
-| ------------------------------------------- | ------------------------------ |
-| `.github/workflows/sync-to-azure.yml`       | `on.push.branches`             |
-| `.github/workflows/clean-merged-branch.yml` | `ignore_branches` (через кому) |
-| `.azurepipelines/apply-k8s.yml`             | `trigger.branches.include`     |
-| `.azurepipelines/site.yml`                  | `trigger.branches.include`     |
-
-Якщо існують інші `**/k8s/`-проекти у репозиторії — переконайся, що `$ENV` потрібен і там (на момент створення скіла є тільки `site/k8s/`).
-
-### 5. Попередження користувачу про зовнішні залежності
-
-Скіл **не** створює ці артефакти — повідом про них користувача:
-
-- У repo `MayaSFA/k8s` має існувати шаблон `.azurepipelines/azure-pipeline-templates/$ENV.yml` (його використовує `apply-k8s.yml` і `site.yml`).
-- Гілка `$ENV` має бути створена в обох remote (GitHub + Azure DevOps).
-- DNS-запис для `$DOMAIN` та health-check у gateway мають бути налаштовані відповідною командою.
-- Якщо ENV — нова країна: ACR-репозиторій `mayasfa-$ENV` (для prod) або `mayasfa-$COUNTRY-dev` (для non-prod) має бути створений.
-
-### 6. Перевірка результату
-
-```bash
-ls site/.env.prod-$ENV site/.env.remote-$ENV site/k8s/$ENV/kustomization.yaml
-grep -n "$ENV" \
-  .github/workflows/sync-to-azure.yml \
-  .github/workflows/clean-merged-branch.yml \
-  .azurepipelines/apply-k8s.yml \
-  .azurepipelines/site.yml \
-  site/package.json
-git status
-```
-
-Виведи користувачу короткий звіт: що створено, що змінено, які зовнішні дії потрібні (з кроку 5). **Не комітити автоматично** — користувач сам перегляне через `git diff` і закомітить.
-
-## Нюанси та пастки
-
-- **Доменний шаблон `maya${ENV}.anadoluefes.com`** працює для існуючих країн (md/tr). Якщо нова країна має інший публічний URL — підтверди в користувача _до_ запуску `sed`.
-- **ACR-шлях суворо за шаблоном**: prod → `mayasfa-$ENV/$ENV/manager-site`, non-prod → `mayasfa-$COUNTRY-dev/$ENV/manager-site`. Жодних додаткових сегментів між ACR-namespace та `$ENV` бути не повинно.
-- **`ENV=dev`**: гілка `dev` — спеціальний випадок (вживає `base/`, без оверлею). Скіл не призначений для перестворення `dev`.
-- **`.env.development`** — лише для локального запуску без бекенду; скіл його не чіпає.
-- **Не запускай `bun run lint` / `lint-ga`** в один потік з іншими — дивись CLAUDE.md «Лінт і ESLint». Перевір лише потрібний файл (`bunx eslint <path>` або точково).

package/skills/efes-create-env/auto.md

@@ -1 +0,0 @@
-[efes]