---
name: mitralex-legal-research
description: "Використовуй завжди, коли відповідаєш на питання з українського права з використанням Mitralex MCP: нормативні документи (чинні та історичні редакції), податкові розʼяснення ЗІР, ІПК, правові позиції і повні тексти постанов Верховного Суду. Version 2.0."
---

# Mitralex Legal Research (v2.0)

Mitralex MCP tools дають доступ до бази українського законодавства, податкових роз'яснень ДПС та практики Верховного Суду. 

Пам'ять моделі і веб – лише маршрут: підказують, де шукати. Текст норми, редакція, чинність, позиція ВС чи ДПС беруться тільки з результату тулів Mitralex. Не відповідай з пам'яті про чинне право, ставки, строки, винятки, практику ВС чи позиції ДПС.

Якщо скіл розходиться з тулом: схему і правила виклику бери з поточного опису тула, наявність і зміст даних – з його фактичної відповіді. Суперечать одне одному – не приховуй розбіжність і не домислюй відсутні дані.

## Pre-flight gate перед відповіддю

1. Назвав норму → вона пройшла `lookup_legislation` або `get_legislation_document`. Немає tool-верифікації – не подавай як встановлений факт. Запит про судову практику, стратегію чи аналіз від цього не звільняє: щойно норма з'являється у відповіді, вона проходить той самий lookup.

2. Перша змістовна згадка норми, постанови, ЗІР, ІПК у чаті має inline-посилання `mitralex_url` на найточніший якір чи діапазон (розділ «Якорі і посилання»).

3. «…»-цитата лише з поля, де лежить сам текст джерела (норма, постанова, ЗІР, ІПК), без маркерів якорів `[[…]]`. Аналітичні поля (`legal_position`, `case_summary`, `relevant_full_text_excerpt`), пам'ять і веб – переказ, не цитата.


## Тули

У тексті скіла tools названо коротко, без префікса. Фактичні MCP-імена мають префікс `mitralex_` (наприклад, `mitralex_lookup_legislation`, `mitralex_get_court_decision`);

Законодавство:
- `lookup_legislation` – точне отримання однієї статті або пункту (у ПКУ і підпункт, напр. 14.1.6): `nreg` + `unit_number` + `unit_kind`; `edition_date` для минулої редакції.
- `get_legislation_document` – розділ, глава, кілька статей, перехідні положення, частина статті за якорями (`anchor_ranges`, до 10 діапазонів) або невеликий документ цілком (лише `nreg`); `edition_date`.
- `get_legislation_table_of_contents` – пари `[якір, заголовок]` без тексту; `edition_date`.
- `search_legislation_by_title` – канонічна назва, статус, `nreg`.
- `search_legislation` – семантичний повнотекстовий пошук по всіх НПА, коли невідомо, яка норма регулює потрібне питання.

Практика і податки:
- `search_court_decisions` – постанови ВС з 2018 року, порціями через `cursor`.
- `get_court_decision` – повний текст за `decision_id` або `case_number` + `adjudication_date`.
- `search_tax_zir`, `search_tax_ipk` – позиції ДПС.

Якщо тули deferred – на старті підвантаж законодавчий блок одним викликом (точні імена або запит `Mitralex legislation` латиницею); court і tax – лише коли питання цього потребує.

## Якорі і посилання

Будь-яка відповідь Mitralex може містити `mitralex_url` і маркери якорів `[[…]]` на початку абзаців тексту (`[[n20]]`, в історичних редакціях також `[[o105]]`). Правило універсальне для всіх джерел, нинішніх і майбутніх (законодавство, постанови ВС, ЗІР, ІПК): дивись не на тип джерела, а на те, чи є маркери в отриманому тексті.

- Є маркери → посилайся якомога точніше: `mitralex_url#n20` – стаття або абзац; `mitralex_url#n20-n24` – фрагмент з підсвіткою (n24 не входить). Діапазон став, коли спираєшся на конкретну частину довгого тексту: користувач одразу бачить саме те місце.
- Маркерів немає → посилання на документ (`mitralex_url` без якоря) + словесна локалізація: «п. 45 постанови», «ч. 2 ст. 625».
- URL з тула вже містить `#якір` → заміни його потрібним, другий `#` не додавай.
- Кінець діапазону – наступний реально повернутий маркер після потрібного фрагмента у фізичному порядку тексту; він у діапазон не входить. Якорі не сортуй за числом і не збільшуй числову частину сам.
- Лише для кінця посилання: якщо наступний маркер порожній (`[[n242]] ` без тексту) або це заголовок «Додаток N до …», бери перший маркер з текстом після них. Краще захопити зайвий рядок у підсвітку, ніж отримати посилання, яке не підсвітиться взагалі. Цитуй при цьому лише потрібний фрагмент, не захоплений хвіст.
- Якорі прив'язані до документа і його редакції: не переноси між документами і редакціями, не вигадуй. Лише `mitralex_url` + маркери з відповіді тула.
- Маркери `[[…]]` – технічні мітки, у цитатах прибирай.

## Маршрут

1. Знаєш документ і номер статті/пункту → одразу `lookup_legislation` з `nreg` (memory-first).
2. Знаєш назву, але не `nreg`, або є сумнів → `search_legislation_by_title`.
3. Потрібен розділ, глава, кілька статей → TOC → `get_legislation_document` за якорями.
4. Не знаєш, який акт → `search_legislation`, далі точний lookup.
5. Податки → норма ПКУ через lookup + ЗІР/ІПК. Практика → `search_court_decisions`; повний текст через `get_court_decision` – для дослівної цитати, для документа і для висновку, що тримається на конкретній постанові. Для огляду і відбору практики досить пошукових полів. Норми, названі при поясненні практики, теж проходять lookup. 

Memory-first – лише за розумної впевненості в реквізиті (ПКУ, ЦК, відомі дефініції). Recall `nreg` і номера – тільки маршрут. Розпливчастий recall – не вгадуй номер, іди в пошук.

Після memory-routed lookup звір: `unit_text` про ту норму, `unit_type` очікуваний, `unit_section` правдоподібний. Розбіжність:
- інший документ, порожньо або `NO_LEGISLATION_RESULTS` → перевір `nreg` через `search_legislation_by_title`; для пунктів підзаконних актів – `unit_kind: non_article`;
- документ той, одиниця не та (14.1.6 vs 14.1.6-1) → TOC для точного номера або `search_legislation`;
- пункт не знаходиться за номером у документі зі складною структурою → TOC → `get_legislation_document` за якорями;
- кілька `results[]` з одним номером → уточни `section_path`.

Не більше двох спроб на одну одиницю (одну статтю, пункт чи документ); далі фіксуй прогалину.

## Законодавство: правила тулів

`lookup_legislation`
- рівно одне з `nreg` / `document_title`; `unit_number` і `unit_kind` обов'язкові. Документ цілком lookup не віддає – для цього `get_legislation_document`;
- `article` – статті; `non_article` – пункти і підпункти, для пунктів додавай `section_path` (перехідні й прикінцеві положення, порядки в постановах, додатки). Приклад: військовий збір – `2755-17`, `16-1`, `non_article`, `Підрозділ 10. Інші перехідні положення`;
- складені номери не розривай: `16-1`, `14.1.6-1`, `170.13-1`;
- частини статті окремо не запитуй: отримай статтю і працюй з її текстом. Опис тула радить так само робити з підпунктами, але фактично підпункти ПКУ на кшталт 14.1.6 lookup повертає (факт над описом); не знайшовся підпункт – отримай пункт або статтю;
- якір – не `unit_number`.

`get_legislation_document`
- `"a..b"` – від якоря a до b, b не входить; `"a.."` – до кінця; `"..b"` – від початку;
- якорі – з TOC або з маркерів `[[n…]]` у тексті тієї самої редакції;
- перевір кожен елемент `fragments[]`: є `text` і немає `error`. Успішний виклик не означає, що прийшли всі діапазони. `ANCHOR_NOT_FOUND` – звір якір і редакцію (TOC з тим самим `edition_date`); `INVALID_RANGE` – початок стоїть після кінця;
- кодекси і великі закони цілком не запитуй, лише діапазони.

TOC
- у кодексів великий (ЦК – понад 100 тис. символів, 1500+ записів). Для однієї статті він не потрібен – вистачить lookup.
- Якорі без TOC: `mitralex_url` з `lookup_legislation` і `search_legislation` уже містить якір статті (`…/435-15#n3107`).

`search_legislation`: назва НПА + 2–5 термінів з лексики закону, орієнтовно до 8 слів (довга повна назва акта – виняток). Результат – орієнтир; для цитати потрібен lookup.

## Історичні редакції

- `edition_date` передавай, коли правовідносини датовані минулим (договір, податковий період, діяння) або користувач просить редакцію на дату.
- `edition_date` і `valid_till_date` у відповіді – межі редакції всього документа, не норми. Повернута редакція може початися раніше за запитану дату – це нормально. `valid_till_date` виключна; `null` – остання відома редакція, що не замінює перевірки `document_status`.
- Редакція на дату не доводить, що норма на цю дату вже діяла: звір `effective_date` документа і дату набрання чинності самою зміною (запит на 2010-12-15 може повернути редакцію з `effective_date` 2011-01-01).
- Коли саме змінилася норма – порівнюй тексти сусідніх редакцій. Дата закону з примітки `{…згідно із Законом № … від …}` – лише зачіпка для пошуку, не дата, з якої зміна застосовується.
- Якорі прив'язані до редакції: для діапазонів в історичній редакції бери TOC з тим самим `edition_date`.
- `mitralex_url` історичної редакції містить дату (`…/2755-17%232023.01.01#n10056`) – використовуй як є.
- Формула: «в редакції станом на {дата}».

## Податки

- ЗІР – загальна позиція ДПС; ІПК – індивідуальна, не обов'язкова, орієнтир. Статус ІПК «Чинна» означає лише, що її не анульовано.
- Перевіряй `document_status` кожної знайденої ЗІР/ІПК: свіжа дата не означає чинну відповідь, за один день бувають і «Чинна», і «Втратила чинність». Нечинну не подавай як позицію ДПС без застереження.
- Запит 4–8 слів податковою мовою: податок, тип платника, режим, суть (`ФОП 3 групи експорт послуг ПДВ`). Для свіжої позиції – `date_from`, напр. останні 2 роки.
- Ключові норми ПКУ з висновку ЗІР/ІПК – через lookup.

## Судова практика

`search_court_decisions`
- Новий пошук: `query` + `search_mode` (+ фільтри). Старт `all`, ядро 3–4 терміни; мало або порожньо → `any`, 4–6 термінів із синонімами; шум в `any` → назад `all`. Для меморандуму або огляду практики, де `all` дав мало, – обидва режими з дедуплікацією за `decision_id`.
- `limit` за замовчуванням 10; більше – лише на прохання, максимум 50.
- «Покажи ще» → лише `cursor` = `next_cursor` дослівно (і `limit` за потреби). Запит для продовження не переформульовуй; `cursor` разом із `query` чи фільтрами – помилка.
- Читай `has_more`, `next_cursor` і поле `note`:
  - `has_more=true` і є `next_cursor` – показано лише частину: загальну кількість не називай і не оцінюй («десятки», «практики немає»);
  - `has_more=true`, `next_cursor=null` – досягнуто межі пошукової сесії (50 постанов): уточни запит або фільтри;
  - `has_more=false` – кількість знайденого дорівнює сумі всіх показаних сторінок цього пошуку, не лише останньої.
- Навіть вичерпана видача – це вибірка за конкретним запитом, а не вся практика з питання.
- Помилки: `INVALID_CURSOR` – один повтор з тим самим cursor; `EXPIRED_CURSOR` – новий пошук з `restart_parameters` і скажи, що видача почалася заново; `UPSTREAM_ERROR` – один повтор, це не «нічого не знайдено».
- `legal_position_status`: «Чинна» – позначена як чинна в базі, це не гарантія актуальності висновку; «Від позиції відступлено» чи інша позначка відступу або уточнення – не подавай як актуальну без перевірки.

`get_court_decision`
- Повертає метадані і `full_text`, без фабули і позиції. Перевір `full_text_status`: лише `returned` означає повний текст; інший статус (напр. ліміт токенів або недоступність) – повного тексту немає, цитувати нема з чого.
- `NO_COURT_DECISION` – постанову за реквізитами не знайдено (типово для номерів справ з вебу).
- Постанови ВП бувають 80+ тис. символів: у чаті можуть обрізатися, в агентному режимі часто приходять файлом (розділ «Великі відповіді»).

## Цитування

- Тріаж: `legal_position`, `case_summary`, `relevant_full_text_excerpt` – лише щоб оцінити релевантність і пояснити вибір. Не цитуй їх.
- Документ (позов, відзив, скарга, лист, меморандум) або висновок, що тримається на конкретній постанові: відкрий її повністю через `get_court_decision`, перевір `full_text_status` і що текст реально прочитано; висновок стоїть на дослівному тексті.
- Норму цитуй з `unit_text` або тексту `get_legislation_document` без `[[n…]]`; постанову – з `full_text`; позицію ДПС – з `answer_text` ЗІР або `consultation_text` ІПК, із датою і характером джерела.
- Формат цитати: дослівна цитата – окремим абзацом, курсивом, у «ялинках». Перед нею – реквізити джерела, у тексті абзацу цитату не розчиняй. Курсив лише для дослівної цитати; посилання на статтю чи постанову курсивом не виділяй.
- Gate перед «…»: звідки рядок? Аналітичне поле, пам'ять, веб – це переказ: отримай першоджерело або зніми лапки. Звір статус позиції і редакцію норми.
- `?` замість лапок у тексті постанови: відновлюй «» лише там, де `?` очевидно парно обрамлює назву (`?Флай сервіс?`). Інші сумнівні символи, слова і пунктуацію не виправляй.

## Великі відповіді тулів

Обмеження бувають на двох рівнях. Спершу перевір відповідь самого тула: `full_text_status` постанови, помилки у `fragments[]`, чи не обривається `document_text` (сервер має власний ліміт символів). Потім розпізнай, що зробило з відповіддю середовище – це залежить від клієнта, а не від наявності shell:

1. **Повний результат у контексті** → працюй напряму.
2. **Обрізано в контексті** (позначка на кшталт `[OUTPUT TRUNCATED…]`, обірваний JSON, текст без кінця) → хвіст втрачено, про решту нічого не домислюй. Є файлова система і збереженого файлу ще немає – один раз повтори виклик (середовище може зберегти файл); якщо файл уже є, не повторюй, читай його. Інакше звузь: замість TOC – lookup потрібних статей, замість документа – `anchor_ranges`, менший `limit`. Постанову звузити нікуди: цитуй лише з отриманої частини і прямо скажи, що текст неповний.
3. **Збережено у файл** (`exceeds maximum allowed tokens… saved to <шлях>` або `<persisted-output>… saved to <шлях>` з коротким прев'ю) → дані поза контекстом, і сам факт збереження повноти не гарантує: файл може містити вже неповну серверну відповідь:
   - прев'ю – не результат, не відповідай з нього;
   - спершу перевір структуру файлу (тип, ключі); якщо це JSON – читай `jq` або python за полями (`.toc`, `.fragments`, `.document_text`, `.results[0].full_text`), не построково;
   - перевір статус і цілісність: `full_text_status`, помилки у `fragments[]`, кількість записів, перший і останній елемент, кінець постанови (резолютивна частина, підписи);
   - великі тексти читай через субагента, якщо він є: дай шлях, схему і перелік тем; вимагай дослівні фрагменти без переказу і скорочень;
   - файл тимчасовий і користувачу не видимий; якщо користувач просить ці дані – оформи похідний файл (md зі змістом, витяг норм) і передай.

## Середовище: чат, агентний режим, папка

Режим визначай за тим, що реально є в сесії, а не за назвою продукту:

- **Лише чат** (немає shell і файлів) → великі відповіді зазвичай ріжуться (сценарій 2). Плануй вузькі виклики з самого початку: lookup, діапазони, невеликий `limit`.
- **Агентний режим** (є shell і файли) → велика відповідь може прийти в контекст, лягти файлом (сценарій 3) або обрізатися; перевіряй щоразу.
- Файли створюй, коли їх просить користувач або задача (документ, робочий md аналізу); на звичайне питання відповідай у чаті.
- **Підключена папка користувача** → місце для файлів, які ти створюєш за задачею, а не дозвіл складати туди все. Збережені відповіді тулів лежать у робочій папці сесії; сирі JSON у папку користувача не копіюй.
- **Хмарна сесія без папки** → файл передавай у розмову; до комп'ютера користувача доступу немає.
- Шлях до збереженого результату бери лише з повідомлення середовища, не вгадуй.

## Веб

Веб – розвідка нарівні з пам'яттю: концепція, релевантні статті, кандидати постанов (номер справи, дата), доктрина.
- Усе, на що спираєшся, проходить тул Mitralex; не підтвердилося – не використовуй і скажи про це.
- Номер справи з вебу → `get_court_decision` (`case_number` + `adjudication_date`) або `search_court_decisions`; не знайдено – не спирайся на неї і, якщо згадуєш, кажи «не підтверджено через Mitralex», а не «не існує».
- Доктрина і коментарі формують твою позицію, але клієнту не подаються як джерело.
- Широку веб-розвідку делегуй субагенту, якщо можна: хай поверне лише зачіпки.

## Атрибуція за типом виводу

- **Чат**: inline `mitralex_url` біля першої змістовної згадки, на найточніший якір чи діапазон; тип джерела підписаний (норма, постанова ВС, ЗІР, ІПК); одне джерело – одне посилання; список у кінці – лише доповнення.
- **Робочий md-файл аналізу**: так само з посиланнями, включно з діапазонами, щоб юрист одним кліком бачив підсвічений фрагмент.
- **Фінальний документ у Word**: без гіперпосилань і згадок Mitralex, джерела повними реквізитами (розділ «Документ у Word»). Посилання в документ – лише на прохання.

## Документ у Word

Стосується договору, позову, відзиву, апеляційної чи касаційної скарги, клопотання, офіційного листа, меморандуму. Інструкції користувача щодо оформлення мають пріоритет; нижче – базовий стандарт, коли їх немає.

Зміст і джерела:
- лише чистий текст юридичного документа; джерела – повними реквізитами: акт, стаття, частина, пункт, за потреби редакція; постанова ВС – суд, дата, номер справи і провадження;
- ключові положення норм і висновки ВС – дослівна цитата окремим абзацом, курсивом, у «ялинках»;
- невідомі дані – плейсхолдер великими літерами: `[НАЗВА_СУДУ]`, `[СУМА_БОРГУ]`, `[ДАТА_ДОГОВОРУ]`. Дані не вигадуй і слот порожнім не залишай.

Оформлення (ДСТУ 4163:2020):
- Times New Roman 14 (допустимо 12), інтервал 1–1,5, текст по ширині, абзацний відступ 10 мм; чорний текст без заливок, рамок і кольорових виділень;
- поля: ліве 30 мм, праве 10 мм, верхнє і нижнє 20 мм;
- нумерація сторінок обов'язкова, якщо сторінок більше однієї: з другої сторінки, арабськими цифрами внизу справа, без слова «сторінка» і розділових знаків; першу сторінку не нумерують;
- дати: у реквізитах `07.12.2025`; у тексті словесно-цифровим способом «07 грудня 2025 року», нуль у дні обов'язковий;
- лапки «ялинки», знак №, «грн» без крапки; Київ без «м.», інші населені пункти – «м. Одеса», «смт Гостомель»;
- назва документа великими літерами по центру;
- адресат: посадова особа – у давальному відмінку («Директору ТОВ «Альфа» / Власне ім'я ПРІЗВИЩЕ»), юридична особа без посадової особи – у називному;
- підпис: посада, лінія для підпису, власне ім'я повністю і ПРІЗВИЩЕ великими літерами («Сергій ПЕТРЕНКО»), розшифрування на рівні останнього рядка посади; у процесуальному документі дата окремим рядком перед підписом; без прийменника «За» чи риски перед посадою;
- додатки: «Додаток: на 5 арк. в 1 прим.»; кілька – нумерований перелік із кількістю аркушів і примірників кожного.

Структура:
- процесуальний документ: шапка (суд, сторони з адресами, кодами і контактами, номер справи за наявності), назва, вступна частина, обставини, правове обґрунтування, прохальна частина («ПРОШУ:»), перелік додатків, дата, підпис;
- договір: назва, місто і дата в шапці, преамбула зі сторонами, нумеровані розділи з пунктами 1.1, 1.2, реквізити і підписи сторін у кінці;
- офіційний лист: адресат, заголовок «Про …», текст, відмітка про додатки, підпис, відомості про виконавця.

## Відповідь

- Мова – українська, якщо користувач не просив іншу.
- Відокремлюй текст норми від аналітики, ЗІР/ІПК і практики.
- Не вдалося отримати ключову норму чи повний текст постанови – скажи прямо.
- «Не знайдено в Mitralex» означає «не підтверджено доступним пошуком», а не доказ, що документа чи практики немає.
- Механіку тулів користувачу не описуй: йому потрібен результат.