cc-viewer 1.6.182 → 1.6.183

package/concepts/uk/Tool-CronCreate.md

@@ -0,0 +1,57 @@
+# CronCreate
+
+Планує постановку промпту в чергу на майбутній момент часу — одноразово або за розкладом. Використовує стандартний 5-польний формат cron у місцевому часовому поясі користувача, без необхідності конвертації часових поясів.
+
+## Коли використовувати
+
+- **Одноразові нагадування**: Коли користувач хоче отримати нагадування у конкретний час ("нагадай мені завтра о 15:00"). При `recurring: false` завдання автоматично видаляється після виконання.
+- **Повторювані розклади**: Коли щось повинно відбуватися регулярно ("кожного будня о 9:00", "кожні 30 хвилин"). Стандартне значення `recurring: true` охоплює цей випадок.
+- **Автономні агентські цикли**: Для побудови робочих процесів, що самостійно перезапускаються за розкладом — наприклад, щоденні дайджести або періодичні перевірки стану.
+- **Постійні завдання**: Коли розклад повинен зберігатися після перезапуску сесії. При передачі `durable: true` завдання записується в `.claude/scheduled_tasks.json`.
+- **Приблизний час**: Коли користувач каже "близько 9:00" або "щогодини", слід вибрати зміщене значення хвилини (наприклад, `57 8 * * *` або `7 * * * *`), щоб уникнути масового спрацювання на :00 або :30.
+
+## Параметри
+
+- `cron` (string, обов'язковий): 5-польний вираз cron у місцевому часовому поясі користувача. Формат: `хвилина година день-місяця місяць день-тижня`. Приклад: `"0 9 * * 1-5"` означає понеділок–п'ятниця о 9:00.
+- `prompt` (string, обов'язковий): Текст промпту, що ставиться в чергу при спрацюванні cron — точне повідомлення, яке буде надіслано до REPL у запланований час.
+- `recurring` (boolean, необов'язковий, за замовчуванням `true`): При `true` завдання запускається в кожному відповідному інтервалі cron і автоматично закінчується через 7 днів. При `false` завдання виконується рівно один раз, а потім видаляється — для одноразових нагадувань.
+- `durable` (boolean, необов'язковий, за замовчуванням `false`): При `false` розклад зберігається лише в пам'яті і втрачається після закінчення сесії. При `true` завдання зберігається в `.claude/scheduled_tasks.json` і переживає перезапуски.
+
+## Приклади
+
+### Приклад 1: одноразове нагадування
+
+Користувач каже: "Нагадай мені завтра о 14:30 надіслати тижневий звіт." Припустимо, що завтра — 21 квітня:
+
+```json
+{
+  "cron": "30 14 21 4 *",
+  "prompt": "Нагадування: надішли тижневий звіт просто зараз.",
+  "recurring": false,
+  "durable": true
+}
+```
+
+`recurring: false` гарантує автоматичне видалення завдання після виконання. `durable: true` зберігає його при будь-яких перезапусках до настання цього часу.
+
+### Приклад 2: повторюване ранкове завдання в будні
+
+Користувач каже: "Щоранку в будні узагальнюй мої відкриті завдання на GitHub."
+
+```json
+{
+  "cron": "3 9 * * 1-5",
+  "prompt": "Узагальни всі відкриті завдання на GitHub, призначені мені.",
+  "recurring": true,
+  "durable": true
+}
+```
+
+Хвилина `3` замість `0` дозволяє уникнути піку навантаження на рівну годину. Завдання автоматично закінчується через 7 днів.
+
+## Примітки
+
+- **Автоматичне закінчення через 7 днів**: Повторювані завдання автоматично видаляються максимум через 7 днів. Якщо потрібен довший розклад, перестворіть завдання до закінчення терміну.
+- **Спрацювання лише в режимі очікування**: `CronCreate` ставить промпт у чергу лише тоді, коли REPL не обробляє інший запит. Якщо REPL зайнятий у момент спрацювання, промпт чекає завершення поточного запиту.
+- **Уникайте хвилин :00 і :30**: Для приблизних часових запитів навмисно обирайте зміщені значення хвилин для розподілу навантаження на систему. Використовуйте :00/:30 лише тоді, коли користувач вказує саме цю хвилину.
+- **Конвертація часового поясу не потрібна**: Вираз cron інтерпретується безпосередньо у місцевому часовому поясі користувача. Немає необхідності конвертувати в UTC або будь-який інший пояс.

package/concepts/uk/Tool-CronDelete.md

@@ -0,0 +1,43 @@
+# CronDelete
+
+Скасовує завдання cron, попередньо заплановане за допомогою `CronCreate`. Негайно видаляє його зі сховища сеансу в пам'яті. Не має жодного ефекту, якщо завдання вже було автоматично видалено (одноразові завдання видаляються після спрацювання, повторювані завдання закінчуються після 7 днів).
+
+## Коли використовувати
+
+- Користувач просить зупинити повторюване заплановане завдання до автоматичного закінчення терміну через 7 днів.
+- Одноразове завдання більше не потрібне і має бути скасоване до його спрацювання.
+- Необхідно змінити вираз розкладу існуючого завдання — видалити його за допомогою `CronDelete`, потім повторно створити за допомогою `CronCreate`, використовуючи новий вираз.
+- Очищення кількох застарілих завдань для підтримання порядку у сховищі сеансу.
+
+## Параметри
+
+- `id` (string, обов'язковий): Ідентифікатор завдання, повернутий `CronCreate` під час первинного створення завдання. Це значення повинно точно збігатися; нечіткий пошук або пошук за назвою не підтримується.
+
+## Приклади
+
+### Приклад 1: скасування запущеного повторюваного завдання
+
+Повторюване завдання було раніше створене з ідентифікатором `"cron_abc123"`. Користувач просить його зупинити.
+
+```
+CronDelete({ id: "cron_abc123" })
+```
+
+Завдання видаляється зі сховища сеансу і більше не спрацьовуватиме.
+
+### Приклад 2: видалення застарілого одноразового завдання до його спрацювання
+
+Одноразове завдання з ідентифікатором `"cron_xyz789"` було заплановане до виконання через 30 хвилин, але користувач вирішив, що воно більше не потрібне.
+
+```
+CronDelete({ id: "cron_xyz789" })
+```
+
+Завдання скасовується. Жодних дій не буде виконано, коли настане первісний час спрацювання.
+
+## Примітки
+
+- `id` необхідно отримати зі значення, що повертається `CronCreate`. Немає способу знайти завдання за описом або зворотним викликом — збережіть ідентифікатор, якщо може знадобитися скасування пізніше.
+- Якщо завдання вже було автоматично видалено (спрацювало як одноразове або досягло повторюваного закінчення терміну через 7 днів), виклик `CronDelete` з цим ідентифікатором є холостою операцією і не спричинить помилки.
+- `CronDelete` впливає лише на поточний сеанс у пам'яті. Якщо середовище виконання не зберігає стан cron між перезапусками, заплановані завдання будуть втрачені при перезапуску незалежно від того, чи було викликано `CronDelete`.
+- Операції масового видалення не існує; скасовуйте кожне завдання окремо, використовуючи його власний `id`.

package/concepts/uk/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Виводить список усіх завдань cron, запланованих через `CronCreate` у поточному сеансі. Повертає зведення по кожному активному завданню, що включає `id`, вираз cron, скорочений `prompt`, прапорець `recurring`, прапорець `durable` та час наступного запуску.
+
+## Коли використовувати
+
+- Для перевірки всіх поточних запланованих завдань перед внесенням змін або завершенням сеансу.
+- Для знаходження правильного `id` завдання перед викликом `CronDelete` з метою його видалення.
+- Для діагностики причин, чому очікуване завдання так і не запустилося: підтвердити його існування та перевірити час наступного запуску.
+- Для підтвердження того, що одноразове (неповторюване) завдання ще не було виконано і досі перебуває в очікуванні.
+
+## Параметри
+
+Немає.
+
+## Приклади
+
+### Приклад 1: перегляд усіх запланованих завдань
+
+Викликати `CronList` без аргументів, щоб отримати повний список усіх активних завдань cron. У відповіді для кожного завдання містяться: `id`, вираз cron, що визначає розклад, скорочена версія `prompt`, який буде виконано, ознака `recurring` (повторюване), ознака `durable` (зберігається між перезапусками) та наступний запланований час запуску.
+
+### Приклад 2: пошук id конкретного повторюваного завдання
+
+Якщо створено кілька завдань cron і потрібно видалити одне конкретне повторюване завдання, спочатку викликати `CronList`. Переглянути повернутий список і знайти завдання, зведення `prompt` та вираз cron якого відповідають цільовому завданню. Скопіювати його `id` та передати до `CronDelete`.
+
+## Примітки
+
+- У списку відображаються лише завдання, створені в поточному сеансі, якщо тільки вони не були створені з `durable: true`, що дозволяє їм зберігатися між перезапусками сеансу.
+- Поле `prompt` у зведенні скорочено: відображається лише початок повного тексту запиту, а не весь його вміст.
+- Одноразові завдання (де `recurring` дорівнює `false`), що вже були виконані, автоматично видаляються і більше не з'являються у списку.

package/concepts/uk/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Визначення
+Виконує точну заміну рядка всередині наявного файлу. Це бажаний спосіб модифікації файлів, оскільки передається лише diff, що зберігає зміни точними та придатними для аудиту.
 
-Редагує файл через точну заміну рядків. Замінює `old_string` на `new_string` у файлі.
+## Коли використовувати
 
-## Параметри
+- Виправлення помилки в одній функції без переписування всього навколишнього файлу
+- Оновлення значення конфігурації, рядка версії чи шляху імпорту
+- Перейменування символу по всьому файлу за допомогою `replace_all`
+- Вставка блоку біля якоря (розширте `old_string`, щоб включити прилеглий контекст, а потім надайте заміну)
+- Застосування невеликих, добре спрямованих правок як частини багатоетапного рефакторингу
 
-| Параметр | Тип | Обов'язковий | Опис |
-|----------|-----|--------------|------|
-| `file_path` | string | Так | Абсолютний шлях до файлу для зміни |
-| `old_string` | string | Так | Оригінальний текст для заміни |
-| `new_string` | string | Так | Новий текст після заміни (повинен відрізнятися від old_string) |
-| `replace_all` | boolean | Ні | Чи замінювати всі збіги, за замовчуванням `false` |
+## Параметри
 
-## Сценарії використання
+- `file_path` (string, обовʼязковий): Абсолютний шлях до файлу для модифікації.
+- `old_string` (string, обовʼязковий): Точний текст для пошуку. Має збігатися символ у символ, включно з пробілами та відступами.
+- `new_string` (string, обовʼязковий): Текст заміни. Має відрізнятися від `old_string`.
+- `replace_all` (boolean, необовʼязковий): Якщо `true`, замінює кожне входження `old_string`. За замовчуванням `false`, що вимагає унікального збігу.
 
-**Підходить для:**
-- Зміна конкретних ділянок коду в існуючому файлі
-- Виправлення помилок, оновлення логіки
-- Перейменування змінних (у поєднанні з `replace_all: true`)
-- Будь-які сценарії, що потребують точної зміни вмісту файлу
+## Приклади
 
-**Не підходить для:**
-- Створення нових файлів — слід використовувати Write
-- Масштабне переписування — може знадобитися Write для перезапису всього файлу
+### Приклад 1: Виправлення одного місця виклику
+Встановіть `old_string` точним рядком `const port = 3000;` і `new_string` — `const port = process.env.PORT ?? 3000;`. Збіг унікальний, тому `replace_all` може залишатися за замовчуванням.
 
-## Примітки
+### Приклад 2: Перейменування символу по всьому файлу
+Щоб перейменувати `getUser` на `fetchUser` скрізь у `api.ts`, встановіть `old_string: "getUser"`, `new_string: "fetchUser"` і `replace_all: true`.
 
-- Перед використанням файл повинен бути прочитаний через Read, інакше буде помилка
-- `old_string` повинен бути унікальним у файлі, інакше редагування не вдасться. Якщо не унікальний, надайте більше контексту для забезпечення унікальності або використовуйте `replace_all`
-- При редагуванні тексту необхідно зберігати оригінальний відступ (tab/пробіли), не включайте префікс номера рядка з виводу Read
-- Надавайте перевагу редагуванню існуючих файлів, а не створенню нових
-- `new_string` повинен відрізнятися від `old_string`
+### Приклад 3: Уточнення повторюваного фрагменту
+Якщо `return null;` зʼявляється в кількох гілках, розширте `old_string`, щоб включити навколишній контекст (наприклад, попередній рядок `if`), щоб збіг став унікальним. Інакше інструмент видасть помилку замість здогадки.
 
-## Оригінальний текст
-
-<textarea readonly>Performs exact string replacements in files.
+## Примітки
 
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- Ви повинні викликати `Read` для файлу принаймні один раз у поточній сесії, перш ніж `Edit` прийме зміни. Префікси з номерами рядків з виводу `Read` не є частиною вмісту файлу; не включайте їх у `old_string` чи `new_string`.
+- Пробіли мають збігатися точно. Звертайте увагу на табуляції проти пробілів та пробіли в кінці, особливо в YAML, Makefiles і Python.
+- Якщо `old_string` не унікальний і `replace_all` дорівнює `false`, редагування зазнає невдачі. Або розширте контекст, або увімкніть `replace_all`.
+- Віддавайте перевагу `Edit` перед `Write`, коли файл уже існує; `Write` перезаписує весь файл і втрачає непов'язаний вміст, якщо ви не обережні.
+- Для кількох непов'язаних правок в одному файлі видайте кілька викликів `Edit` послідовно, а не одну велику крихку заміну.
+- Уникайте введення емодзі, маркетингових текстів або незапитаних блоків документації під час редагування файлів вихідного коду.

package/concepts/uk/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Визначення
+Перемикає сесію в режим планування — фазу дослідження лише для читання, в якій асистент вивчає кодову базу і складає конкретний план реалізації, щоб користувач затвердив його перед будь-якими змінами файлів.
 
-Перемикає Claude Code у режим планування для дослідження кодової бази та проєктування плану перед реалізацією.
+## Коли використовувати
+
+- Користувач просить нетривіальну зміну, що охоплює кілька файлів чи підсистем.
+- Вимоги неоднозначні, і асистенту потрібно прочитати код, перш ніж обирати підхід.
+- Пропонується рефакторинг, міграція чи оновлення залежності, і радіус впливу незрозумілий.
+- Користувач явно каже "сплануй це", "давай спочатку спланувати" або запитує огляд проєкту.
+- Ризик достатньо високий, щоб перехід одразу до правок міг зруйнувати роботу або стан.
 
 ## Параметри
 
-Без параметрів.
+Немає. `EnterPlanMode` не приймає аргументів — викликайте його з порожнім обʼєктом параметрів.
 
-## Сценарії використання
+## Приклади
 
-**Підходить для:**
-- Реалізація нової функціональності — потрібні архітектурні рішення
-- Існує кілька можливих підходів — потрібен вибір користувача
-- Зміна коду впливає на існуючу поведінку або структуру
-- Зміни в кількох файлах — можуть стосуватися 2-3 і більше файлів
-- Вимоги нечіткі — потрібно спочатку дослідити та зрозуміти обсяг
-- Уподобання користувача важливі — реалізація може мати кілька обґрунтованих напрямків
+### Приклад 1: Великий запит на функцію
 
-**Не підходить для:**
-- Виправлення одного рядка або кількох рядків (друкарська помилка, очевидний баг)
-- Користувач дав дуже конкретні інструкції
-- Суто дослідницьке/розвідувальне завдання — слід використовувати Task (тип Explore)
+Користувач запитує: "Додай SSO через Okta до адмінпанелі." Асистент викликає `EnterPlanMode`, потім витрачає кілька кроків, читаючи middleware автентифікації, сховище сесій, охоронці маршрутів та наявний UI входу. Він пише план, описуючи необхідні зміни, етапи міграції та тестове покриття, а потім подає через `ExitPlanMode` на затвердження.
 
-## Поведінка в режимі планування
+### Приклад 2: Ризикований рефакторинг
 
-Після входу в режим планування Claude Code:
-1. Використовує інструменти Glob, Grep, Read для глибокого дослідження кодової бази
-2. Розуміє існуючі патерни та архітектуру
-3. Проєктує план реалізації
-4. Подає план на затвердження користувачем
-5. За потреби може використовувати AskUserQuestion для уточнення
-6. Коли план готовий, виходить через ExitPlanMode
+Користувач каже: "Перетвори REST-контролери на tRPC." Асистент входить у режим планування, оглядає кожен контролер, каталогізує публічний контракт, перелічує фази розгортання (шим, подвійне читання, перемикання) і пропонує план послідовності перед тим, як торкатися будь-якого файлу.
 
 ## Примітки
 
-- Цей інструмент потребує згоди користувача для входу в режим планування
-- Якщо не впевнені, чи потрібне планування, схиляйтеся до планування — попереднє узгодження краще за переробку
-
-## Оригінальний текст
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- Режим планування за контрактом є лише для читання. Перебуваючи в ньому, асистент не повинен запускати `Edit`, `Write`, `NotebookEdit` чи будь-яку мутаційну команду оболонки. Використовуйте лише `Read`, `Grep`, `Glob` та недеструктивні команди `Bash`.
+- Не входьте в режим планування для тривіальних однорядкових правок, чисто дослідницьких питань чи завдань, де користувач уже повністю вказав зміну в деталях. Накладні витрати шкодять більше, ніж допомагають.
+- У режимі Auto режим планування не заохочується, якщо користувач явно не запитує — Auto віддає перевагу діям над попереднім плануванням.
+- Використовуйте режим планування, щоб зменшити коригування курсу в дорогій роботі. Пʼятихвилинний план часто економить годину неправильно спрямованих правок.
+- У режимі планування фокусуйте дослідження на частинах системи, які насправді зміняться. Уникайте вичерпних турів по репозиторію, не повʼязаних із поточним завданням.
+- Сам план має бути записаний на диск за шляхом, який очікує оболонка, щоб `ExitPlanMode` міг його подати. План повинен містити конкретні шляхи файлів, імена функцій та кроки верифікації, а не розпливчасті наміри.
+- Користувач може відхилити план і попросити перегляду. Ітеруйте в режимі планування, доки план не буде прийнятий; лише потім виходьте.

package/concepts/uk/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Визначення
+Створює ізольоване Git-робоче дерево (worktree) на новій гілці або перемикає сесію в наявне робоче дерево поточного репозиторію, щоб паралельна чи експериментальна робота могла тривати без втручання в основний checkout.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Коли використовувати
 
-## Параметри
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Сценарії використання
+- Користувач явно каже "worktree" — наприклад "start a worktree", "create a worktree" або "work in a worktree".
+- Інструкції проєкту в `CLAUDE.md` чи постійна памʼять спрямовують вас використовувати worktree для поточного завдання.
+- Ви хочете продовжити завдання, яке раніше було налаштоване як worktree (передайте `path`, щоб знову увійти).
+- Кілька експериментальних гілок мають співіснувати на диску без постійних перемикань.
+- Тривале завдання має бути ізольованим від непов'язаних правок у основному робочому дереві.
 
-**Підходить для:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**Не підходить для:**
-- The user asks to create/switch branches — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-
-## Примітки
-
-- Must be in a git repository, or have WorktreeCreate/WorktreeRemove hooks configured
-- Must not already be in a worktree
-
-## Оригінальний текст
-
-<textarea readonly>Use this tool ONLY when the user explicitly asks to work in a worktree. This tool creates an isolated git worktree and switches the current session into it.
+## Параметри
 
-## When to Use
+- `name` (string, необовʼязковий): Імʼя для нового каталогу worktree. Кожен сегмент, розділений `/`, може містити лише літери, цифри, крапки, підкреслення та тире; повний рядок обмежений 64 символами. Якщо відсутній і `path` також відсутній, генерується випадкове імʼя. Взаємовиключний з `path`.
+- `path` (string, необовʼязковий): Шлях у файловій системі до наявного worktree поточного репозиторію для перемикання. Має зʼявлятися в `git worktree list` для цього репозиторію; шляхи, що не зареєстровані як worktree поточного репо, відхиляються. Взаємовиключний з `name`.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## Приклади
 
-## When NOT to Use
+### Приклад 1: Створення нового worktree з описовим імʼям
 
-- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-- Never use this tool unless the user explicitly mentions "worktree"
+```
+EnterWorktree(name="feat/okta-sso")
+```
 
-## Requirements
+Створює `.claude/worktrees/feat/okta-sso` на новій гілці, що базується на `HEAD`, потім перемикає робочий каталог сесії в нього. Усі наступні правки файлів та команди оболонки працюють усередині цього worktree, доки ви не вийдете.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### Приклад 2: Повторний вхід у наявний worktree
 
-## Behavior
+```
+EnterWorktree(path="/Users/me/repo/.claude/worktrees/feat/okta-sso")
+```
 
-- In a git repository: creates a new git worktree inside `.claude/worktrees/` with a new branch based on HEAD
-- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation
-- Switches the session's working directory to the new worktree
-- On session exit, the user will be prompted to keep or remove the worktree
+Поновлює роботу в раніше створеному worktree. Оскільки ви ввійшли через `path`, `ExitWorktree` не видалить його автоматично — вихід з `action: "keep"` просто повертає в оригінальний каталог.
 
-## Parameters
+## Примітки
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- Не викликайте `EnterWorktree`, якщо користувач явно не попросив або інструкції проєкту цього не вимагають. Звичайні запити на перемикання гілок чи виправлення помилок мають використовувати звичайні Git-команди, а не worktree.
+- При виклику всередині Git-репозиторію інструмент створює worktree в `.claude/worktrees/` і реєструє нову гілку на основі `HEAD`. Поза Git-репозиторієм він делегує налаштованим хукам `WorktreeCreate` / `WorktreeRemove` у `settings.json` для ізоляції, незалежної від VCS.
+- Одночасно активна лише одна сесія worktree. Інструмент відмовляється запускатися, якщо ви вже всередині сесії worktree; спочатку вийдіть з `ExitWorktree`.
+- Використовуйте `ExitWorktree`, щоб вийти посеред сесії. Якщо сесія завершується, коли ви ще всередині новоствореного worktree, користувача запитають, чи зберегти його, чи видалити.
+- Worktree, увійдені через `path`, вважаються зовнішніми — `ExitWorktree` з `action: "remove"` їх не видалить. Це запобіжник для захисту worktree, якими користувач керує вручну.
+- Новий worktree успадковує вміст поточної гілки, але має незалежний робочий каталог та індекс. Підготовлені та непідготовлені зміни в основному checkout не видимі всередині worktree.
+- Порада з іменування: додавайте префікс типу роботи (`feat/`, `fix/`, `spike/`), щоб кілька одночасних worktree було легко розрізняти в `git worktree list`.

package/concepts/uk/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Визначення
+Подає план реалізації, складений під час режиму планування, на затвердження користувача та — якщо затверджено — переводить сесію з режиму планування, щоб можна було розпочати правки.
 
-Виходить з режиму планування та подає план на затвердження користувачем. Вміст плану зчитується з раніше записаного файлу плану.
+## Коли використовувати
 
-## Параметри
-
-| Параметр | Тип | Обов'язковий | Опис |
-|----------|-----|--------------|------|
-| `allowedPrompts` | array | Ні | Список описів дозволів, необхідних для плану реалізації |
-
-Кожен елемент масиву `allowedPrompts`:
-
-| Поле | Тип | Обов'язковий | Опис |
-|------|-----|--------------|------|
-| `tool` | enum | Так | Застосовний інструмент, наразі підтримується лише `Bash` |
-| `prompt` | string | Так | Семантичний опис операції (наприклад, "run tests", "install dependencies") |
-
-## Сценарії використання
+- План, написаний під час `EnterPlanMode`, завершений і готовий до перегляду.
+- Завдання орієнтоване на реалізацію (зміни коду чи конфігурації), а не чисте дослідження, тому явний план є доцільним.
+- Усе необхідне читання та аналіз виконано; подальше дослідження не потрібне перед рішенням користувача.
+- Асистент перелічив конкретні шляхи файлів, функції та кроки — не лише цілі.
+- Користувач попросив побачити план, або робочий процес режиму планування готується передати керування інструментам редагування.
 
-**Підходить для:**
-- У режимі планування план завершено, готовий до подання на затвердження користувачем
-- Лише для завдань реалізації, що потребують написання коду
-
-**Не підходить для:**
-- Суто дослідницьке/розвідувальне завдання — не потрібно виходити з режиму планування
-- Запитання користувачу "Чи підходить план?" — це саме функція цього інструменту, не використовуйте AskUserQuestion
-
-## Примітки
+## Параметри
 
-- Цей інструмент не приймає вміст плану як параметр — він зчитує з раніше записаного файлу плану
-- Користувач побачить вміст файлу плану для затвердження
-- Не запитуйте "чи підходить план?" через AskUserQuestion перед викликом цього інструменту — це дублювання
-- Не згадуйте "план" у запитаннях, оскільки користувач не бачить вміст плану до ExitPlanMode
+- `allowedPrompts` (array, необовʼязковий): Промпти, які користувач може ввести на екрані затвердження, щоб автоматично затвердити або змінити план. Кожен елемент вказує дозвіл з областю дії (наприклад, імʼя операції та інструмент, до якого вона застосовується). Залиште невстановленим, щоб використати типовий потік затвердження.
 
-## Оригінальний текст
+## Приклади
 
-<textarea readonly>Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
+### Приклад 1: Стандартна подача
 
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
+Після дослідження рефакторингу автентифікації в режимі планування та запису файлу плану на диск асистент викликає `ExitPlanMode` без аргументів. Оболонка читає план з його канонічного розташування, показує його користувачеві та чекає на затвердження або відхилення.
 
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
+### Приклад 2: Попередньо затверджені швидкі дії
 
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-**Important:** Do NOT use AskUserQuestion to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
+Дозволяє користувачеві надати дозвіл наперед для рутинних подальших команд, щоб асистенту не потрібно було робити паузу для кожного запиту дозволу під час реалізації.
 
-## Examples
+## Примітки
 
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.
-</textarea>
+- `ExitPlanMode` має сенс лише для роботи, орієнтованої на реалізацію. Якщо запит користувача є завданням дослідження чи пояснення без змін файлів, відповідайте напряму — не маршрутизуйте через режим планування, аби лише вийти з нього.
+- План має бути вже записаним на диск перед викликом цього інструмента. `ExitPlanMode` не приймає тіло плану як параметр; він читає зі шляху, який очікує оболонка.
+- Якщо користувач відхиляє план, ви повертаєтесь у режим планування. Перегляньте на основі відгуку та подайте знову; не починайте редагувати файли, поки план не затверджений.
+- Затвердження надає дозвіл залишити режим планування та використовувати мутаційні інструменти (`Edit`, `Write`, `Bash` тощо) для області, описаної в плані. Розширення області після цього вимагає нового плану або явної згоди користувача.
+- Не використовуйте `AskUserQuestion`, щоб запитати "чи виглядає цей план добре?" перед викликом цього інструмента — запит затвердження плану — це саме те, що робить `ExitPlanMode`, а користувач не бачить плану, доки його не подадуть.
+- Тримайте план мінімальним та дієвим. Рецензент має бути здатним перечитати його менш ніж за хвилину та зрозуміти, що саме зміниться.
+- Якщо посеред реалізації ви усвідомите, що план був неправильним, зупиніться та доповідьте користувачеві, а не відхиляйтеся мовчки. Повторний вхід у режим планування — дійсний наступний крок.