Приклади питань — Домен 3
25 питань у банку для цього домену · показано 8
Домен 3Сценарій 21 / 8
Ви хочете створити custom-команду /review, що запускає стандартний чек-лист код-рев'ю команди. Вона має бути доступна кожному розробнику після clone/pull репозиторію. Де створити файл команди?
AУ директорії .claude/commands/ у репозиторії проєкту, щоб вона версіонувалась
BУ ~/.claude/commands/ у домашній директорії кожного окремого розробника команди
CУ файлі CLAUDE.md у корені проєкту, оформивши її як окрему секцію команд
DУ .claude/config.json у масиві commands разом з описом кожної доступної команди
✓ Правильна відповідь: A — Project-scoped slash-команди зберігають у .claude/commands/ репозиторію — вони версіонуються разом із кодом і доступні всім після clone/pull. Розміщення в ~/.claude/commands/ робить команду особистою й не шерить її між розробниками; CLAUDE.md призначений для контексту, а не для виконуваних команд; а .claude/config.json з масивом commands описує неіснуючий у Claude Code механізм.
Домен 3Сценарій 22 / 8
Вам доручили реструктуризувати моноліт у мікросервіси: зміни в десятках файлів і рішення про межі сервісів та залежності модулів. Який підхід обрати?
AУвійти в plan mode: дослідити кодбазу, зрозуміти залежності й спроєктувати підхід
BПочати з direct execution й міняти інкрементально, дозволивши реалізації виявити межі
CDirect execution із повними наперед інструкціями, як структурувати кожен сервіс
DПочати в direct execution і перемкнутись у plan mode лише за несподіваної складності
✓ Правильна відповідь: A — Plan mode створений саме для масштабних змін у десятках файлів, кількох валідних підходів та архітектурних рішень про межі сервісів і залежності модулів — він дозволяє безпечно дослідити код перед комітом до змін. Інкрементальний direct execution ризикує дорогими переробками, коли межі виявляться невдалими; підхід із повними наперед інструкціями хибно припускає готову відповідь без дослідження; а відкладене перемикання ігнорує, що складність уже задана самими вимогами.
Домен 3Сценарій 23 / 8
Ви фіксите один баг у єдиному файлі з чітким stack trace, що прямо вказує на місце. Який режим оптимальний?
ADirect execution — зміна добре зрозуміла, чітко обмежена за scope і має точне місце
BPlan mode — будь-яка зміна коду потребує попереднього формального планування
CPlan mode із залученням Explore subagent для повного аналізу всієї кодбази
DСпершу fork_session для ізоляції, потім direct execution у новій сесії
✓ Правильна відповідь: A — Для простих, добре окреслених змін (single-file fix з чітким stack trace, що прямо вказує на місце) пасує direct execution. Plan mode потрібен для архітектурних або багатофайлових задач, тож вимагати його для будь-якої зміни коду — надлишково; залучення Explore subagent для аналізу всієї кодбази тут марнує контекст; а fork сесії додає зайвий крок ізоляції без потреби.
Домен 3Сценарій 24 / 8
Новий член команди скаржиться, що Claude Code не застосовує командні інструкції, які працюють у всіх інших. Ви з'ясовуєте, що інструкції лежать у ~/.claude/CLAUDE.md одного з інженерів. У чому причина й виправлення?
AUser-level конфіг (~/.claude/CLAUDE.md) не шериться через VCS; перенести в project-level
BЦе баг кешу конфігурації; новому інженеру варто просто перевстановити сам Claude Code
CІнструкції треба вручну продублювати в кожному окремому ~/.claude/CLAUDE.md для всіх колег
DПеренести інструкції у .gitignore, щоб вони згодом підхопились усіма геть автоматично
✓ Правильна відповідь: A — Налаштування user-level (~/.claude/CLAUDE.md) застосовуються лише до конкретного користувача й не передаються через version control, тому інструкції одного інженера не діють у решти. Командні стандарти мають бути project-level (.claude/CLAUDE.md або кореневий CLAUDE.md), щоб версіонуватись і діяти на всіх. Це не проблема кешу; ручне дублювання по домашніх теках некероване й розсинхронізується; а .gitignore узагалі виключає файл із репозиторію, замість того щоб його шерити.
Домен 3Сценарій 25 / 8
Ваш CLAUDE.md розрісся до сотень рядків і став важко підтримуваним. Який підхід рекомендований для модульності?
AРозбити на тематичні файли (testing, deployment) і підключати через @import
BСтиснути файл, видаливши коментарі, зайві пробіли й усі порожні рядки для компактності
CПеренести весь наявний вміст у єдиний гігантський system prompt поза самим CLAUDE.md
DСтворити по копії повного CLAUDE.md у кожній окремій піддиректорії всього проєкту
✓ Правильна відповідь: A — Великий CLAUDE.md дробиться на тематичні файли (наприклад, testing.md, api-conventions.md, deployment.md) і підключається через @import-синтаксис — це дає модульність і легку підтримку. Просте стиснення прибиранням пробілів не вирішує проблему підтримуваності; зведення всього в єдиний system prompt лише концентрує той самий моноліт; а копії повного файлу в кожній теці створюють розсинхронізацію й дублювання.
Домен 3Сценарій 26 / 8
Ви прозою описуєте бажану трансформацію коду, але Claude інтерпретує її щоразу по-різному. Що найефективніше комунікує очікування?
AНадати 2–3 конкретні приклади пар вхід/вихід, що однозначно демонструють трансформацію
BПереписати інструкцію ще детальнішою прозою з більшою кількістю прикметників
CПідвищити max_tokens, щоб модель докладніше пояснювала кожен крок трансформації
DДодати в кінці інструкції чітку фразу «будь дуже точним» для більшої суворості
✓ Правильна відповідь: A — Коли прозовий опис трансформації трактується щоразу по-різному, найдієвіше — кілька конкретних прикладів вхід/вихід (few-shot), які однозначно показують потрібний результат і прибирають неоднозначність. Ще детальніша проза з прикметниками не усуває різночитання; підвищення max_tokens впливає на довжину виводу, а не на консистентність трансформації; а заклик «будь точним» не дає моделі конкретного орієнтира поведінки.
Домен 3Сценарій 27 / 8
Ви реалізуєте кешування у незнайомому домені й не впевнені, які грані врахували. Який прийом найкраще виявить непомічені міркування ще до реалізації?
AInterview pattern: попросити Claude поставити вам запитання, що піднімуть рішення
BОдразу попросити повну реалізацію й виправляти баги вже по факту їх поступової появи
CДати лише прозовий опис задачі й цілком покластися на дефолтні рішення самої моделі
DЗгенерувати код двічі різними промптами й обрати з них довшу та детальнішу версію
✓ Правильна відповідь: A — Interview pattern — коли Claude ставить вам запитання, що виявляють непередбачені приховані міркування (стратегії інвалідації кешу, режими збоїв) ще до реалізації; це особливо цінно в незнайомому домені, де ви не впевнені, які грані врахували. Прохання одразу реалізувати пропускає етап виявлення й переносить помилки в дебаг; опора на дефолти моделі лишає приховані рішення непоміченими; а вибір довшої з двох генерацій не корелює з повнотою врахованих граней.
Домен 3Сценарій 28 / 8
У вас є skill для аналізу кодбази, що генерує дуже багатослівний вивід і засмічує основну розмову. Яка опція frontmatter це вирішує?
Acontext: fork — запускає skill в ізольованому sub-agent контексті без забруднення розмови
Ballowed-tools: лише Read — обмежує інструменти й тим скорочує обсяг виводу самого skill
Cargument-hint — підказує параметри виклику й тим зменшує загальну багатослівність відповіді
Dmodel: haiku — менша дефолтна модель за замовчуванням повертає коротший і стисліший вивід
✓ Правильна відповідь: A — Опція frontmatter context: fork ізолює skill у subagent-контексті, тож його багатослівний вивід не потрапляє в основну сесію — у головну розмову повертається лише результат. Обмеження інструментів через allowed-tools звужує доступ, а не ізолює контекст; argument-hint керує підказкою параметрів і не впливає на обсяг виводу; а зміна моделі не дає контекстної ізоляції, навіть якщо вивід стане коротшим.