--- name: n-llm-patch description: >- Підготовка самодостатнього текстового промпта для іншого Claude/Cursor-агента — read-only аналіз CWD без жодних змін у поточному репо --- # Підготовка 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-блок у відповіді чату, готовий до копіювання. ## Виклик ``` /n-llm-patch <вільний опис завдання> ``` Аргумент має містити: **що треба зробити**, опційно — **назву пакета / підмодуля** для контексту. Якщо аргумент порожній — попроси користувача сформулювати завдання, не вгадуй. Приклад: ``` /n-llm-patch підготуй для проекту @nitra/eslint-config щоб він врахував останню версію node ``` ## Workflow 1. **Розпарсити аргумент** — виокремити суть завдання та (якщо є) назву пакета / шлях. Аргумент = намір користувача, передається у промпт як розділ "Завдання". 2. **Зібрати read-only контекст з CWD:** - `package.json` — поля `name`, `version`, `engines`, `peerDependencies`, `dependencies`, `devDependencies`, `scripts`, `type`, `exports`. - Структура репо: `tree -L 2 -I 'node_modules|.git|dist|build|.next|.nuxt'` (або `ls -la` коли `tree` недоступний). - `README.md` — перші 40-60 рядків (head). - `CLAUDE.md` / `AGENTS.md` / `.cursor/rules/*.mdc` — якщо є, відмітити їх існування й перелік. - **Релевантні до завдання config-файли** — підбирати за ключовими словами з аргументу (наприклад, "node" → `engines`, `.nvmrc`, `.node-version`; "eslint" → `eslint.config.*`, `.eslintrc*`; "vite" → `vite.config.*`; "ts" → `tsconfig.json`). 3. **Визначити "точку патчу"** — короткий список файлів, які найімовірніше доведеться правити цільовому агенту, з обґрунтуванням. 4. **Сформувати промпт за шаблоном нижче.** Дрібні релевантні файли (≤ ~80 рядків) вбудовуй **повністю**; великі — цитуй фрагмент з посиланням на шлях:рядки. 5. **Вивести один markdown-блок у чат** — без додаткових коментарів поза блоком, окрім однорядкового підпису "готово до копіювання". ## Шаблон вихідного промпта ````markdown ```markdown # Завдання <нормалізований опис з аргументу — 1-3 речення без води> # Контекст проєкту - Назва / версія: `@` - Тип: - Стек: Node ``, , <ключові залежності> - Документи правил: ## Структура (skim) ``` <вивід tree -L 2> ```` # Релевантні файли ## `package.json` ```text <повний вміст або ключові поля> ``` ## `<інший релевантний файл>` ``` <вміст або фрагмент з посиланням на шлях:рядки> ``` # Що треба зробити - крок 1 — у файлі `X` (`<коротке пояснення>`) - крок 2 — у файлі `Y` - крок 3 — оновити `CHANGELOG.md` / bump `version`, якщо це npm-пакет # Обмеження - Не ламати публічний API - =22, треба >=25"> - Дотриматись правил репо (CLAUDE.md / .cursor/rules — посилання вище) # Як перевірити - `<команда з scripts — npm test / bun test / lint>` - <конкретні acceptance-checks: "у `engines.node` має бути `>=25`", "CI зелений" тощо> ``` ``` ```` ## Правила - **Мова промпту:** українська за замовчуванням; якщо аргумент англійською — можна англійською. Технічні терміни — англійською. - **Обсяг:** прагни вмістити промпт у ~200-500 рядків. Якщо релевантних файлів багато — обери 3-5 найважливіших, решту згадай посиланнями. - **Без галюцинацій:** не вигадуй полів `package.json`, версій, шляхів — лише те, що реально прочитав з CWD. Якщо чогось бракує — явно так і напиши ("`engines.node` відсутнє"). - **Без імперативного тону до користувача:** промпт адресований **іншому агенту**, не людині. Використовуй "зроби", "онови", "додай". - **Без секцій-пустушок:** якщо немає `Обмежень` — пропусти секцію. - **Не вмикай у промпт:** секрети, `.env`, `node_modules`, бінарні файли, довгі логи. - **Усе в одному блоці:** результат — це **один** ` ```markdown ` блок; ніяких додаткових міркувань поза ним (крім фінального підпису "готово до копіювання"). ## Що скіл **не** робить - Не завантажує tarball з npm registry, не клонує git-репозиторії. - Не редагує жоден файл у поточному проєкті (і поза ним). - Не виконує сам "патч" — лише готує промпт для іншого агента. - Не оптимізує під Gemini / GPT — лише Claude / Cursor agent. ## Приклад виклику й результату Виклик: ``` /n-llm-patch у @nitra/eslint-config підняти engines.node до >=25 ``` Очікуваний вивід (схематично): ```` ````markdown # Завдання Підняти `engines.node` у `@nitra/eslint-config` до `>=25` і переглянути сумісність peer-залежностей з новою версією. # Контекст проєкту - Назва / версія: `@nitra/eslint-config@2.4.0` - Тип: shared eslint preset (library) - Стек: Node `>=22` (поточне), ESM, eslint `^9` - Документи правил: `.cursor/rules/n-js-lint.mdc` ## Структура (skim) … # Релевантні файли ## `package.json` ```json { "engines": { "node": ">=22" }, "peerDependencies": { "eslint": "^9" } } ``` ```` # Що треба зробити - `package.json` → `engines.node`: `>=22` → `>=25` - Перевірити, чи `peerDependencies.eslint ^9` сумісне з Node 25 - Bump `version` (minor) + запис у `CHANGELOG.md` # Як перевірити - `bun test` - `node -v` у CI ≥ 25 ``` готово до копіювання — встав у чат з агентом у цільовому проєкті ```