Context engineering для Claude 5: шість нових правил і аудит промпту

Коротко (TL;DR)

Context engineering для Claude 5 — це збирання всього, що модель отримує разом із вашим запитом: системного промпту, CLAUDE.md, скілів, пам’яті, файлів-референсів. 24 липня 2026 року Anthropic повідомила, що прибрала із системного промпту Claude Code понад 80% тексту для моделей на кшталт Opus 5 і Fable 5 і не побачила вимірних втрат на своїх оцінках коду. Нижче — що з цього випливає для ваших промптів і як перевірити це на власних завданнях, а не на вірі.

• Що застаріло: жорсткі правила «на всі випадки», приклади виклику інструментів, повтори однієї інструкції у двох місцях, CLAUDE.md як звалище всіх практик.
• Що лишилося: мета й причина запиту, формат виводу, межі завдання, заборона незворотних дій. Приклади для формату й тону довідка Anthropic і далі радить — 3–5 штук.
• Що робити: пройти кожен рядок промпту п’ятьма запитаннями, прибрати милиці під старі моделі, винести рідкісні інструкції у скіли.
• Як не зламати: прогнати старий і новий варіант на 15–20 реальних завданнях і відкочувати рядок, якщо просіла метрика.
• Чим собі допомогти: у Claude Code 2.1.283+ є /doctor prompt-audit — він знаходить застарілі й суперечливі інструкції, але нічого не змінює без вашої команди.

Що Anthropic сказала про Claude 5 — і чого немає в її пості

Першоджерело — пост Таріка Шихіпара (Thariq Shihipar, технічний співробітник Anthropic) The new rules of context engineering for Claude 5 generation models, опублікований 24 липня 2026 року. Головна фраза поста: «We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations». Тобто понад 80% системного промпту прибрано, а вимірних втрат на внутрішніх оцінках коду немає.

Важливо, що саме сказано, а чого немає. У пості немає диффа старого й нового промпту, немає назв оцінок і жодної цифри якості. «Без втрат» — це заява самої Anthropic, незалежно її ніхто не відтворив. Перекази поста, зокрема випуск DOU «AI шумлять», подекуди його посилюють — звірка нижче.

На кадрі зі сторінки поста (знято 24 жовтня 2026 року) рамка 1 виділяє зміст: усі шість пар «Then / Now» видно поспіль. Рамка 2 — ілюстрація з розділу про приклади: старий опис інструмента TodoWrite зі списками «коли використовувати» й розібраними прикладами проти короткого інтерфейсу зі статусами pending, in_progress, completed.

▲ Long▼ Short

Binance · Wall Street 24/7Ціна падає? Це теж шансУгоду можна відкрити і на зростання, і на падіння. Почніть із плеча 1×

NVDATSLAGOLD

Як це працює

Пост писали про дві моделі, а лінійка відтоді оновилася. На 24 жовтня 2026 року в довідці Anthropic актуальні Claude Fable 5.1, Claude Opus 5.5, Sonnet 5.5 і Haiku 5.5 (ID claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5), і для кожної є власна сторінка з порадами щодо промптів. Висновки поста до них застосовні із застереженням: довідка прямо пише, що техніку, перевірену на одній моделі, треба перевірити на своїх оцінках, перш ніж переносити на іншу.

Навчання зі ШІ: Study mode, уроки-ігри й пастка −17% на іспиті

Бенчмарки ШІ-агентів: що вимірюють Agents’ Last Exam та ще 10 тестів

OpenWorker Ендрю Ина: відкритий ШІ-агент із 25+ конекторами, який поки що в беті

Цикли ШІ-агентів: 4 типи agent loop і чому агенту потрібна зовнішня перевірка

Blume: сайт документації з теки Markdown, який читають люди та ШІ-агенти

Як це працює: чому зайві правила заважають Claude 5

Context engineering — це робота не з одним запитом, а з усім контекстом, який модель бачить під час кожної відповіді. Докладно про саме поняття і про те, чому довгий контекст «псується», — у розборі контекстної інженерії для ШІ-агентів. Тут важлива одна відмінність: промпт пишуть під конкретне завдання, а контекст працює одразу на сотні різних запитів, тому він не може бути таким самим конкретним.

Звідси головна проблема, яку Anthropic знайшла в себе. Читаючи логи власної роботи в Claude Code, команда бачила в одному запиті суперечливі вказівки: системний промпт, скіл і користувач одночасно казали «leave documentation as appropriate» і «DO NOT add comments». Claude зазвичай вгадує, чого хоче людина, але на розбір конфлікту витрачає зайве міркування. Документація Claude Code додає: якщо дві інструкції суперечать одна одній, модель може обрати одну довільно.

Друга причина — правила, потрібні слабким моделям. Раніше системний промпт Claude Code вимагав: «In code: default to writing no comments. Never write multi-paragraph docstrings…». Для частини завдань це було хибно: користувач має свої вподобання, а складному коду інколи потрібен довгий коментар. Старим моделям правило однаково було вигідніше, ніж свобода. У новому промпті його замінила одна фраза: «Write code that reads like the surrounding code: match its comment density, naming, and idiom» — пиши так, як написано навколишній код.

Третє — баланс між конкретикою і свободою. Автор польового гайду з Fable 5 формулює його так: надто конкретна інструкція змусить Claude виконувати її, навіть коли розумніше змінити курс; надто розмита — і модель ухвалить рішення за «галузевими практиками», які вам можуть не підійти. Ще у вересні 2025 року Anthropic називала це «правильною висотою» промпту й окремо застерігала, що мінімальний набір інструкцій не означає короткий.

Тому нові правила context engineering for Claude 5 models зводяться не до «пиши менше», а до «пиши про мету й причини». Довідка з Fable 5 це прямо підтверджує: модель працює краще, коли в промпті названо задум запиту, і більшістю поведінки можна керувати короткою інструкцією замість переліку випадків. Як побудувати добрий промпт з нуля — в окремому посібнику зі структури промпту; ця стаття про чистку того, що вже накопичилося.

Шість старих звичок і чим їх замінити для Claude 5

Пост Anthropic побудовано як шість пар «було → стало». У таблиці — кожна пара і те, що вона означає для вашого власного промпту чи CLAUDE.md.

до виходу на біржу

Binance · Wall Street 24/7OpenAI і Anthropic ще не на біржіPre-IPOА контракти на їхню ціну вже торгуються на Binance

OpenAIAnthropicNVDA

Дивитися ціни

Дві пари із шести в переказах зазвичай губляться. «Повтори»: ранні моделі краще слухалися інструкцій наприкінці контексту, тому згадки інструментів дублювалися в системному промпті й в описі самого інструмента — тепер дублі видалено. «Референси»: специфікацією може бути докладний набір тестів або функція в іншій кодовій базі, яку треба портувати, а HTML-макет дизайну, за спостереженням Anthropic, зазвичай дає кращий результат, ніж словесний опис чи скриншот.

Якщо звести таблицю до одного правила, context engineering для Claude 5 зводиться до запитання «навіщо тут цей рядок?». Рядок, що страхує від помилки старої моделі, тепер коштує токенів у кожному запиті й може сперечатися з рештою. Рядок, що повідомляє моделі те, чого вона не дізнається сама, лишається.

Приклади, роль, CAPS і «думай крок за кроком»: що шкодить, а що ні

Найчастіше спотворення поста — «приклади тепер шкодять». У пості сказано конкретніше: «The number one rule for tool usage was to give Claude examples», а з новими моделями такі приклади «constrains them to a certain exploration space» — звужують простір пошуку. Ідеться про приклади виклику інструментів. Довідка з промптів тієї ж Anthropic на 24 жовтня 2026 року радить протилежне для формату й тону: «Include 3–5 examples for best results».

На кадрі з довідки Prompting best practices (знято 24 жовтня 2026 року) рамка 1 — підказка «Include 3–5 examples for best results» у розділі про приклади, рамка 2 — розділ «Give Claude a role»: роль у системному промпті й досі рекомендована, і навіть одне речення змінює поведінку й тон.

Щодо CAPS потрібне застереження: у довідці пораду пом’якшити агресивну мову написано як ліки від «перепрацювання» в моделей 4.5–4.6, окремої заборони для лінійки 5.x там немає. Логіка при цьому та сама — гучна інструкція для уважної моделі стає нав’язливою.

Окрема сторінка довідки з prompt engineering для Claude Opus 5.5 додає ще один рядок на видалення: інструкції «думай уважно перед відповіддю» в системному промпті чату. У тестах Anthropic після видалення такого рядка відповіді починалися раніше без явного падіння якості. Застереження те саме: це перевірено в чат-сценарії, на ваших завданнях результат треба міряти.

Аудит промпту під Claude 5: покроковий чек-лист

Аудит — це прохід кожним рядком контексту з одним запитанням: що зламається, якщо його видалити? Порядок такий.

1. Зберіть усі шари в одне місце. Системний промпт, усі CLAUDE.md (корінь, підпапки, користувацький), правила в .claude/rules/, описи скілів, AGENTS.md. Конфлікти майже завжди живуть на стику шарів, тому дивитися файли поодинці марно.
2. Знайдіть суперечності. Шукайте пари на кшталт «лишай документацію за ситуацією» і «не додавай коментарі». Кожну пару зведіть до одного формулювання з причиною.
3. Поставте кожному рядку п’ять запитань (список нижче) і позначте: лишити, прибрати, перенести.
4. Перепишіть решту через мету й причину. «Відповідай без markdown» → «Відповідай звичайним текстом: віджет не показує розмітку».
5. Винесіть рідкісне у скіли. Інструкції, потрібні в одному завданні з двадцяти, не мають вантажитися в кожне.
6. Звіртеся з довідкою під свою модель. Для Claude Opus 5.5 в Anthropic є окремий prompt guide — сторінка «Prompting Claude Opus 5.5»; у Fable 5.1, Sonnet 5.5 і Haiku 5.5 — свої. Там перелічено рядки, які для конкретної моделі варто видалити.
7. Проженіть міні-eval (розділ нижче) і тільки потім викочуйте нову версію.

П’ять запитань до кожного рядка:

• Чи страхує він від помилки, якої нова модель уже не робить? «Перевір відповідь», «мінімізуй виклики інструментів», «тримай усі знахідки до фінальної відповіді» — довідки з Opus 5, Fable 5.1 і Sonnet 5.5 прямо радять видалити такі рядки.
• Чи може модель дізнатися це сама з коду або файлів? Структура папок, список залежностей, огляд архітектури — виводяться з репозиторію.
• Чи не дублює він іншу інструкцію? Дубль у системному промпті й в описі інструмента — кандидат на видалення.
• Чи має він причину? Правило без «тому що» модель виконає буквально, навіть там, де воно недоречне.
• Чи охороняє він незворотну дію, формат або безпеку? Якщо так — лишити, переписати спокійним тоном і з причиною.

Останнє запитання — головне гальмо чистки. Видалення файлів, гроші, надсилання листів, доступ до продакшену, формат, який парсить інший сервіс, — такі межі не є милицею для слабкої моделі, і під Claude 5 вони лишаються.

Промпт «було → стало»: чистка системного промпту на прикладі

Навчальний приклад: системний промпт чат-бота підтримки інтернет-магазину, який роками доповнювали після кожного інциденту. Це шаблон для розбору, а не замір — перевіряти результат треба на своїх завданнях.

Було:

Ти — найкращий у світі асистент підтримки.
CRITICAL: You MUST ALWAYS use the search_orders tool when the user mentions an order.
ЗАВЖДИ викликай search_orders. НІКОЛИ не відповідай без перевірки замовлення.
Приклад: «Де моє замовлення 123?» → search_orders(order_id="123")
Приклад: «Замовлення 456 не прийшло» → search_orders(order_id="456")
Думай крок за кроком і випиши міркування в тегах <thinking> перед відповіддю.
Перед фінальною відповіддю перевір кожен факт двічі.
Мінімізуй виклики інструментів.
Не використовуй списки й жирний шрифт.
Не роби повернень.

Стало:

Ти відповідаєш клієнтам інтернет-магазину в чаті підтримки. Мета — розв'язати
питання за одну-дві відповіді: знайти замовлення, пояснити статус, запропонувати
наступний крок. Клієнти найчастіше пишуть із телефона, тому відповідай коротко.

Дані про замовлення — в інструменті search_orders; використовуй його, коли
питання стосується конкретного замовлення.

Повернення коштів і зміну адреси доставки ти не оформлюєш: це незворотні дії,
їх виконує оператор. Передай запит через handoff_to_human і скажи клієнтові,
коли йому дадуть відповідь.

Пиши звичайним текстом без markdown: чат-віджет не показує розмітку.

Чого бракує в новій версії, видно одразу: немає прикладів відповідей у фірмовому тоні. Якщо тон для бізнесу важливий, їх варто повернути — 3–5 коротких зразків у тегах <example>. Видаляли ми приклади виклику інструмента, а не приклади формату.

Як перевірити, що чистка не погіршила якість: міні-eval

Міні-eval — це невеликий набір реальних завдань, на якому старий і новий промпт проганяють однаково й порівнюють за заздалегідь записаними критеріями. Довідка Anthropic прямо радить перевіряти прийоми «against your own evals», а дослідження ETH Zurich про файли AGENTS.md у висновках пише те саме: будь-яку спробу поліпшити роботу агента треба суворо оцінити до викочування.

1. Наберіть 15–20 завдань із реальних логів, а не вигаданих. Додайте типові запити й 3–4 неприємні: конфлікт інструкцій, прохання зробити заборонене, завдання на формат.
2. Запишіть критерії до прогону. Для кожного завдання: розв’язано чи ні, чи дотримано формату, чи не було забороненої дії.
3. Проженіть обидва варіанти на одній моделі з однаковими налаштуваннями. Різні моделі, рівень effort або режим мислення роблять порівняння безглуздим.
4. Порівняйте частку розв’язаних завдань і витрату токенів.
5. Відкочуйте конкретний рядок, а не всю чистку, якщо просіла метрика. Відчуття «стало гірше» без цифр — не привід.

Як читати результат на малій вибірці. На 20 завданнях одне завдання — це 5 процентних пунктів, тому різниця в одне завдання не відрізняється від випадковості. Наш обережний поріг відкату — евристика, а не статистичний тест: мінус два завдання й більше або хоча б одна заборонена дія в новому варіанті, і друге важливіше за будь-яке середнє. Спірний результат перевірте повторним прогоном: відповіді моделі від запуску до запуску трохи різняться.

Умовний розрахунок економії, щоб було зрозуміло, заради чого все це. Якщо системний промпт скоротився з 6 000 до 2 000 токенів, кожен запит несе на 4 000 вхідних токенів менше. На 1 000 запитів на день це 4 млн токенів на добу, які більше не треба обробляти. Цифри умовні — підставте свої обсяги й ціну вашої моделі. Якщо ввімкнено кешування промпту, повторюваний системний промпт і так оплачується за зниженою ставкою, тож у грошах виграш менший, але місце у вікні й увага моделі звільняються повністю.

Опубліковані цифри щодо такої чистки поки є тільки в OpenAI, і це її внутрішні прогони, а не незалежний тест. У довідці з GPT-5.6 (на 24 жовтня 2026 року) сказано: на вибірці прогонів кодового агента коротші системні промпти підняли оцінки приблизно на 10–15%, скоротивши токени на 41–66% і вартість на 33–67%. Сама OpenAI називає діапазони орієнтовними й радить ту саму методику, що й вище: прибирати по одній групі інструкцій, прикладів чи інструментів і перезапускати ті самі оцінки.

CLAUDE.md, скіли й автопам’ять у Claude Code: що куди класти

Context engineering у Claude Code — це розкладання інструкцій по шарах, кожен з яких має свою ціну. Щось вантажиться в кожен запит, щось — лише коли потрібно. Як написати сам файл інструкцій з нуля, розібрано в статті про CLAUDE.md у Claude Code; тут — що з нього прибрати й куди перенести.

Найдорожче місце — опис скіла. Тіло скіла читається лише під час виклику, а список назв і описів усіх скілів лежить у контексті на кожному ході, навіть якщо скіл ніколи не використовують. Довге «коли використовувати» в описі оплачується в кожному запиті. Як влаштовані скіли й прогресивне завантаження — у розборі Agent Skills у Claude Code.

Автопам’ять змінює роль CLAUDE.md. Раніше Claude Code пропонував хоткей #, щоб дописувати нотатки в CLAUDE.md, тепер модель сама зберігає те, що стосується роботи й вас. За документацією автопам’ять пропускає все, що виводиться з коду (архітектуру, шляхи до файлів, виправлення багів), і те, що вже є в CLAUDE.md. Отже, у CLAUDE.md лишається те, чого не дізнатися ні з репозиторію, ні з минулих сесій: приклад із поста — домовленість тримати всі типи в одному монолітному файлі.

Перевіряти шари вручну довго, тому в Claude Code є вбудований аудит. Команда /doctor prompt-audit (потрібна версія 2.1.283 або новіша; за даними Tproger, вона вийшла 25 вересня 2026 року) перевіряє CLAUDE.md, CLAUDE.local.md, AGENTS.md, а також правила, скіли, команди й субагентів у .claude/. Вона шукає інструкції, написані під старі моделі, посилання на файли й команди, яких немає, суперечності між файлами.

На кадрі з документації Claude Code (знято 24 жовтня 2026 року) рамкою виділено розділ «Audit your instruction files». У ньому видно три речі: аудит видає звіт із запропонованими правками й нічого не змінює, доки ви не попросите; одну папку можна перевірити окремо — /doctor prompt-audit .claude/skills/deploy; працює він через вбудований скіл /claude-api і потребує Claude Code v2.1.283.

Простий /doctor без аргументу — загальний чекап налаштувань: серед іншого він знаходить невикористовувані скіли й вміст CLAUDE.md, який виводиться з коду, і пропонує перенести інструкції, що вантажаться постійно, у скіли. Для ціни кожного скіла є окрема команда /skill-doctor, її розберемо в окремому матеріалі.

Чи працює це на GPT і Gemini: що радять OpenAI та Google

Частково. OpenAI з вересня 2026 року радить той самий напрям: менше приписів, короткі й несуперечливі описи скілів, без вимоги читати все перед кожною правкою. Google у довідці Gemini API, навпаки, і далі рекомендує завжди додавати few-shot приклади. Спільний знаменник у всіх трьох — суперечності й зайві інструкції шкодять, а мету й межі треба задавати явно.

В OpenAI є й зворотний ефект, якого в пості Anthropic немає. У блозі від 11 вересня 2026 року компанія попереджає: якщо попередній моделі ви писали жорсткі заборони, щоб вона не заходила задалеко, GPT-6 Astra може сприйняти їх надто серйозно й зупинитися там, де ви були б раді продовженню. Тобто застаріла межа шкодить не лише витратою токенів, а й тим, що роботу не доведено до кінця.

Загальний висновок для змішаного стеку: той самий AGENTS.md чи скіл може читати модель іншого вендора. OpenAI прямо пише, що інструкції, які допомагали її попереднім моделям, можуть сковувати нову, — і радить думати, які моделі читатимуть ваші файли.

Коли чистити промпт не треба і чим це ризикує

Чистка під Claude 5 — не універсальна порада. Є сценарії, де старі інструкції виправдані, і є ризики, про які перекази поста мовчать.

• Старі моделі в продакшені. Висновки поста стосуються «моделей на кшталт Opus 5 і Fable 5». Для Sonnet 4.6 і Haiku 4.5 у довідці лишаються старі рекомендації, а довідка прямо вимагає перевіряти техніку під час перенесення на іншу модель.
• Незворотні дії та безпека. Видалення даних, платежі, надсилання листів, доступ до продакшену лишаються під явною забороною з причиною.
• Формат, який читає машина. Якщо відповідь парсить інший сервіс, суворий формат — не милиця, а контракт.
• Opus 5 потрібні межі, а не свобода. Довідка з Opus 5: модель сама перевіряє свою роботу й може розширювати завдання, додаючи кроки, про які не просили. Для вузьких завдань рамку треба задавати явно.

Цифра «+72%» схожа на спростування поста, але ним не є. Її навів китайський портал QbitAI з посиланням на розробника Chen Cheng (переказ — 36Kr), і порівнюються в ній різні пари: «80%» Anthropic — це шлях від старого промпту до нового, а «+72%» — Opus 5 проти Opus 4.8. За тим самим переказом основне скорочення припало на перехід від Opus 4.7 до 4.8.

Що саме додалося, розробник теж подивився: за переказом 36Kr, майже всю різницю, близько 3 755 символів, дають два розділи, які є тільки в промпті для Opus 5, — «Delivering work» (рамки завдання, звіти про хід роботи, здача результату) і «Corrections» (обмеження на повторні розбори власних помилок). Це збігається з довідкою з Opus 5: модель сама перевіряє роботу, розширює завдання й охоче делегує його субагентам Claude Code, тому для вузьких завдань довідка радить ставити рамки явно, а про сам Claude Code пише, що на Opus 5 він додає власну інструкцію щодо делегування. Офіційно Anthropic склад приросту не коментувала, а сам замір одиничний — ми його не відтворювали.

З того самого розбору випливає ще одна деталь: Claude Code тримає два набори системних промптів і обирає їх залежно від моделі. Докладний старий отримують Sonnet, Haiku і старі Opus, скорочений новий — Opus 5 і Fable 5. Тобто сама Anthropic не переносить чистку на моделі, для яких її не перевірено.

Дослідження ETH Zurich (arXiv 2602.11988, версія від 29 вересня 2026 року) додає незалежний сигнал: контекстні файли на кшталт AGENTS.md у середньому не підвищують частку розв’язаних завдань і піднімають вартість запуску більш ніж на 20%. Огляди репозиторію, які радять вендори, виявилися марними, а от інструкції агенти виконують. Це працює в обидва боки: вдалий рядок спрацює, невдалий — теж, буквально. Застереження: моделі в дослідженні — не лінійка Claude 5.

Кейси: як чистили Claude Code, AGENTS.md і опис скіла

Три публічні приклади, де видно і «було», і «стало». Усі три — з першоджерел вендорів, а не з переказів.

Коментарі в коді в Claude Code

Було: правило «за замовчуванням не писати коментарів, жодних багаторядкових docstring, щонайбільше один короткий рядок», плюс заборона створювати документи з планами без прохання користувача. Стало: «пиши код так, як навколишній: та сама щільність коментарів, назви й ідіоми». Одна фраза закриває всі випадки — і проєкт без коментарів, і складний модуль, де багаторядковий коментар доречний, — бо спирається на контекст, а не на заборону.

Опис скіла для міграцій Postgres в OpenAI

Поганий опис: «Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence». Добрий: «…Use when adding or changing a migration, or reviewing its rollout». За поясненням OpenAI, перша версія штовхає модель вмикати скіл за будь-якого дотику до бази даних, хоча він потрібен лише для міграцій. Опис став точнішим, а не довшим.

AGENTS.md «прочитай усе перед кожною правкою»

Погано: «Before every edit, read architecture.md, database.md, and deployment.md». Добре: architecture.md — для меж сервісів, database.md — для змін схеми, deployment.md — під час підготовки деплою. OpenAI називає вимогу читати стос документів перед кожною правкою зайвою для виправлення одруківки: це спалює контекст і сповільнює роботу. Посилання на документи лишаються корисними, якщо вони прив’язані до ситуації.

FAQ

Чи треба прибирати приклади з промптів для Claude 5?

Не всі. Пост Anthropic говорить про приклади виклику інструментів: у нових моделей вони звужують простір пошуку, і замість них краще поліпшити параметри й опис інструмента. Приклади формату, тону й структури довідка Anthropic на 24 жовтня 2026 року і далі радить — 3–5 різноманітних зразків у тегах <example>, без спроби перелічити всі крайові випадки.

Чим context engineering відрізняється від prompt engineering?

Prompt engineering — це формулювання одного запиту під конкретне завдання. Context engineering — робота з усім, що модель бачить разом із запитом: системним промптом, CLAUDE.md, скілами, пам’яттю, файлами й описами інструментів. Контекст обслуговує сотні різних запитів, тому в ньому не можна бути таким самим конкретним, як у промпті, і ціна кожного зайвого рядка вища.

Чи варто прибирати CAPS і MUST зі старих промптів?

Так, здебільшого. Довідка Anthropic радить пом’якшувати формулювання на кшталт «CRITICAL: You MUST use this tool» до звичайного «Use this tool when…»: пораду написано для Opus 4.5 і 4.6, які уважніші за попередні моделі до системного промпту, і гучна інструкція в них веде до перегину. Для лінійки 5.x окремого правила немає, але логіка та сама. Виняток — незворотні дії: заборона лишається, але спокійним тоном і з причиною.

Як зрозуміти, що правило в CLAUDE.md застаріло?

Поставте йому запитання: що зламається, якщо рядок видалити? Застаріле правило зазвичай страхує від помилки, якої нова модель уже не робить, повторює те, що видно з коду, дублює іншу інструкцію або не має причини. Документація Claude Code радить тримати CLAUDE.md коротшим за 200 рядків і витрачати його на неочевидні «граблі» проєкту.

Що робить /doctor prompt-audit і з якої версії він доступний?

Команда перевіряє CLAUDE.md, AGENTS.md, правила, скіли, команди й субагентів на інструкції під старі моделі, посилання на відсутні файли й суперечності між файлами. Вона видає звіт із запропонованими правками й нічого не змінює без вашої команди. Потрібен Claude Code версії 2.1.283 або новішої; перевірити один файл чи папку можна, передавши шлях.

Чи зламаються старі промпти на Claude 5, якщо нічого не змінювати?

Як правило, ні: моделі й далі виконують інструкції. Проблема в іншому — зайві рядки коштують токенів у кожному запиті, суперечності змушують модель обирати між ними, а застарілі заборони сковують її там, де вона впоралася б краще. Opus 5 зі старою інструкцією «перевір усе» просто перевіряє двічі й витрачає більше.

Чи підходять нові правила для GPT і Gemini?

Частково. OpenAI у 2026 році радить той самий напрям: менше покрокових приписів, короткі описи скілів, жодних суперечностей. Google у довідці Gemini API і далі рекомендує завжди додавати few-shot приклади, попереджаючи лише про перенавчання на завеликій їх кількості. Спільне в усіх трьох вендорів — явні цілі й межі за меншої кількості зайвих правил.