Приклади питань — Домен 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. B — це особисті команди (не шеряться); CLAUDE.md (C) — для контексту, не для команд; D описує неіснуючий у Claude Code механізм.
Домен 3Сценарій 22 / 8
Вам доручили реструктуризувати моноліт у мікросервіси: зміни в десятках файлів і рішення про межі сервісів та залежності модулів. Який підхід обрати?
AУвійти в plan mode: дослідити кодбазу, зрозуміти залежності й спроєктувати підхід ще до змін
BПочати з direct execution й міняти інкрементально, дозволивши реалізації виявити природні межі
CDirect execution з повними наперед інструкціями, як саме структурувати кожен сервіс
DПочати в direct execution і перемкнутись у plan mode лише якщо виникне несподівана складність
✓ Правильна відповідь: A — Plan mode створений саме для масштабних змін, кількох валідних підходів та архітектурних рішень. Він дозволяє безпечно дослідити код перед комітом до змін. B ризикує дорогими переробками; C припускає готову відповідь без дослідження; D ігнорує, що складність уже задана вимогами.
Домен 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 потрібен для архітектурних/багатофайлових задач, тож тут він був би надлишковим.
Домен 3Сценарій 24 / 8
Новий член команди скаржиться, що Claude Code не застосовує командні інструкції, які працюють у всіх інших. Ви з'ясовуєте, що інструкції лежать у ~/.claude/CLAUDE.md одного з інженерів. У чому причина й виправлення?
AUser-level конфіг (~/.claude/CLAUDE.md) не шериться через version control; перенести інструкції у project-level (.claude/CLAUDE.md або кореневий CLAUDE.md)
BЦе баг кешу; новому інженеру треба перевстановити Claude Code
CІнструкції треба продублювати в кожному ~/.claude/CLAUDE.md вручну для всіх
DПеренести інструкції у .gitignore, щоб вони підхопились автоматично
✓ Правильна відповідь: A — Налаштування user-level застосовуються лише до цього користувача й не шеряться через VCS. Командні стандарти мають бути project-level, щоб діяти на всіх. Ручне дублювання (C) некероване; .gitignore (D) узагалі виключає файл із репозиторію.
Домен 3Сценарій 25 / 8
Ваш CLAUDE.md розрісся до сотень рядків і став важко підтримуваним. Який підхід рекомендований для модульності?
AРозбити на тематичні файли у .claude/rules/ (напр. testing.md, api-conventions.md, deployment.md) або підключати зовнішні файли через @import
BСтиснути файл, видаливши коментарі й пробіли
CПеренести весь вміст у єдиний гігантський system prompt
DСтворити по копії повного CLAUDE.md у кожній піддиректорії
✓ Правильна відповідь: A — Великий CLAUDE.md дробиться на тематичні файли у .claude/rules/ або підключається через @import-синтаксис для модульності. Стиснення (B) не вирішує підтримуваність; єдиний system prompt (C) і копії в кожній теці (D) лише погіршують.
Домен 3Сценарій 26 / 8
Ви прозою описуєте бажану трансформацію коду, але Claude інтерпретує її щоразу по-різному. Що найефективніше комунікує очікування?
AНадати 2–3 конкретні приклади вхід/вихід, що демонструють потрібну трансформацію
BПереписати інструкцію ще детальнішою прозою з більшою кількістю прикметників
CПідвищити max_tokens, щоб модель докладніше пояснювала кроки
DДодати в кінці інструкції фразу «будь дуже точним»
✓ Правильна відповідь: A — Коли прозовий опис трактується непослідовно, найдієвіше — конкретні приклади вхід/вихід. Більше прози (B), більший max_tokens (C) чи заклики «будь точним» (D) не усувають неоднозначності так, як приклади.
Домен 3Сценарій 27 / 8
Ви реалізуєте кешування у незнайомому домені й не впевнені, які грані врахували. Який прийом найкраще виявить непомічені міркування ще до реалізації?
AInterview pattern: попросити Claude поставити вам запитання, що піднімуть приховані рішення (інвалідація кешу, режими збоїв)
BОдразу попросити повну реалізацію й виправляти баги по факту
CДати лише прозовий опис і покластися на дефолти моделі
DЗгенерувати код двічі й обрати довшу версію
✓ Правильна відповідь: A — Interview pattern — коли Claude ставить запитання, що виявляють непередбачені вами міркування (стратегії інвалідації кешу, failure modes) ще до реалізації. Це особливо корисно в незнайомих доменах. Решта варіантів пропускають цей етап виявлення.
Домен 3Сценарій 28 / 8
У вас є skill для аналізу кодбази, що генерує дуже багатослівний вивід і засмічує основну розмову. Яка опція frontmatter це вирішує?
Acontext: fork — запускає skill в ізольованому sub-agent контексті, не забруднюючи основну розмову
Ballowed-tools: лише Read — обмежує інструменти, прибираючи зайвий вивід
Cargument-hint — підказує параметри, скорочуючи вивід
Dmodel: haiku — менша модель дає коротший вивід
✓ Правильна відповідь: A — context: fork ізолює skill у subagent-контексті, тож його verbose-вивід не потрапляє в основну сесію. allowed-tools (B) обмежує інструменти, а не ізолює контекст; argument-hint (C) — про параметри; зміна моделі (D) не про ізоляцію.