ШІ для розробників: агенти для програмування, витрати й безпечна передача завдань

Як це зробити

1. 1Перш ніж передати завдання, напишіть перевірку або вкажіть на неї: тест, що падає, або команду та її очікуваний вивід.
2. 2Дайте агентові завдання за допомогою промпту з цієї сторінки, зазначивши файли, які він може змінювати, і ті, які не може.
3. 3Нехай він сам запустить перевірку й вставить остаточний вивід.
4. 4Переглядайте diff як pull request колеги: успішна перевірка починає рев'ю, а не завершує його.

Вбудовано

• ChatGPT · Codex
• Claude · Claude Code

Промпт для копіювання

Завдання: [зміна].
Готово — це коли [тест або команда] проходить і виводить [очікуваний вивід]. Запусти це, перш ніж завершити, і встав результат.
Ти можеш змінювати: [шляхи]. Не змінюй: [шляхи], залежності й тести.
Якщо не вдається домогтися, щоб перевірка проходила, зупинись і поясни чому, а не обходь перевірку.

Де все йде не так

• Агенти іноді домагаються проходження тесту, послаблюючи його. Забороніть змінювати тести й шукайте таке в diff.
• Завдання, завелике для однієї перевірки, завелике й для однієї передачі. Розділіть його.

Як це зробити

1. 1Виберіть той, що поруч із вашим кодом: Codex Cloud, хмарний агент Copilot на GitHub або Claude Code on the web.
2. 2Переконайтеся, що в його середовищі можна встановити ваші залежності й запустити тести: без них агент лише вгадує.
3. 3Надсилайте невеликі незалежні завдання, кожне з власною перевіркою, як у завданні вище.
4. 4Нехай кожен pull request спершу прочитає автоматичний рецензент, а потім перегляньте його самі.

Вбудовано

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Промпт для копіювання

У цьому репозиторії: [завдання].
Контекст: [де в коді, пов'язаний issue].
Готово, коли: [тест або команда] проходить у твоєму середовищі; додай її вивід в опис pull request.
Pull request має містити менше ніж [кількість] змінених рядків. Якщо потрібно більше, зупинись і запропонуй, як його розділити.

Де все йде не так

• Тести, яким потрібні секрети чи сервіси, що ви не налаштували, пропускаються або падають. Зелений запуск без них мало що доводить.
• Кілька агентів, що працюють над пов'язаним кодом, створюють pull request, які конфліктують. Тримайте паралельні завдання в різних частинах коду.

Як це зробити

1. 1Запишіть команди збирання, тестування й лінтингу у файл інструкцій, який агент читає на початку кожного сеансу; назву файлу вказано в документації кожного агента.
2. 2У Claude Code додайте хуки, які запускають форматер і тести після кожного редагування, щоб агент бачив збої й виправляв їх.
3. 3Нехай бот переглядає кожен pull request: увімкніть «Automatic review» у Codex або призначте Copilot рецензентом.
4. 4Коли агент двічі робить ту саму помилку, перетворіть її на тест або правило у файлі інструкцій.

Вбудовано

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Промпт для копіювання

Прочитай цей репозиторій і напиши файл інструкцій для агентів для програмування:
1. Точні команди для встановлення, збирання, тестування, лінтингу й форматування.
2. Структуру проєкту не більше ніж у 10 рядках.
3. Домовленості, які новачки тут порушують, з одним прикладом для кожної.
4. Чого агент ніколи не має тут робити, наприклад змінювати міграції чи редагувати згенеровані файли.
Наводь лише команди, які ти успішно запустив; решту познач як «не перевірено».

Де все йде не так

• Файл інструкцій із командами, які вже не працюють, привчає агента його ігнорувати. Запускайте їх знову, коли змінюється налаштування.
• Боти-рецензенти теж упевнено помиляються. Сприймайте їхні коментарі як пропозиції.

Як це зробити

1. 1Запишіть, що ви найчастіше вставляєте в чати, як-от issues, логи помилок, документацію чи схему. Підключіть це насамперед.
2. 2Додайте для кожного з них офіційний сервер MCP із токеном, який може лише читати. У Gemini CLI розширення може містити сервер MCP разом із його налаштуванням.
3. 3Дайте агентові завдання, для якого вони потрібні, і перевірте, що він звернувся до правильного.
4. 4Раз на кілька тижнів видаляйте сервери, якими більше не користуєтеся.

Вбудовано

• Gemini CLI · Extensions

Промпт для копіювання

Перш ніж щось змінювати: прочитай issue [номер] у трекері, знайди помилку в логах і перевір документацію для [бібліотека].
Скажи, що тобі дало кожне джерело і в якому файлі, на твою думку, помилка.
Нічого не записуй у жоден підключений інструмент.

Де все йде не так

• Вебсторінка, issue чи документ можуть містити текст, написаний для того, щоб керувати агентом. Не давайте доступу на запис інструментам, які читають вміст ззовні.
• Токени в конфігураційних файлах витікають. Використовуйте сховище секретів клієнта або змінні середовища, але ніколи не репозиторій.

Як це зробити

1. 1Перевірте, за що ви вже платите: плани ChatGPT включають Codex, а платні плани Claude — Claude Code.
2. 2Запишіть використання токенів у кількох типових сеансах там, де агент його показує.
3. 3Оцініть вартість цього використання на нашій сторінці цін API й порівняйте з підпискою.
4. 4Для автоматизації та CI використовуйте ключі API з лімітом витрат, щоб цикл не набрав великий рахунок.

Вбудовано

• ChatGPT · Codex
• Claude · Claude Code

Промпт для копіювання

Ось моє використання за [кількість] типових сеансів: [вхідні й вихідні токени]. Я працюю приблизно [кількість днів] днів на тиждень.
Оціни мою місячну вартість за токени за цими цінами: [вставте зі сторінки цін API].
Порівняй її з підпискою за [ціна] на місяць. Покажи обчислення, щоб їх можна було перевірити.

Де все йде не так

• Підписки теж мають ліміти використання. Якщо досягти ліміту посеред завдання, втрачається час; перевіряйте ліміт, а не лише ціну.
• Модель впливає на рахунок більше, ніж будь-що інше. Порівнюйте за тією моделлю, якою справді користуєтеся.

Як це зробити

1. 1Запустіть /init у репозиторії: команда аналізує кодову базу й пише початковий CLAUDE.md або пропонує покращення до наявного.
2. 2Спільні правила, як-от команди збирання й тестування та стандарти коду, тримайте в ./CLAUDE.md і зафіксуйте його в репозиторії. Власні вподобання пишіть у ~/.claude/CLAUDE.md для всіх проєктів або в CLAUDE.local.md для цього.
3. 3Посилайтеся на довші документи, а не вставляйте їх: @path/to/file імпортує інший файл під час запуску.
4. 4Щоразу, коли Claude двічі помиляється в тому самому, додайте один рядок, який би цьому запобіг.

Промпт для копіювання

Прочитай цей репозиторій і покращ CLAUDE.md. Обсяг — до 60 рядків:
1. Точні команди для збирання, тестування й лінтингу.
2. Структура в кількох рядках.
3. Домовленості, які новачок тут порушує.
4. Файли й папки, які ніколи не можна редагувати.
Видали все, що вже неправда. Команди, які ти не запускав, познач як «не перевірено».

Де все йде не так

• Усе в CLAUDE.md завантажується в кожному сеансі й займає контекст. Переносьте подробиці у файли, які він імпортує.
• Інструкції, що вже не відповідають дійсності, гірші, ніж жодних. Перевіряйте команди знову, коли змінюється налаштування.

З офіційної документації: Claude Code docs: How Claude remembers your project

Як це зробити

1. 1Натискайте Shift+Tab, доки в рядку стану не з'явиться «plan mode on», або почніть промпт із /plan.
2. 2Опишіть зміну й те, що не має змінитися. Claude все одно може запускати команди, щоб дослідити код, але під час планування не редагує файлів.
3. 3Читайте план як проєктну нотатку: неправильний файл, пропущений випадок, завелика зміна. Просіть виправлень, доки план не стане правильним, а потім схваліть його.
4. 4Перед наступним, не пов'язаним завданням почніть заново з /clear.

Промпт для копіювання

/plan Зміни [що] так, щоб [мета]. Обмеження: [що не має змінитися].
Перелічи файли, які ти зачепиш, порядок змін, тест, що доводить кожен крок, і все, у чому ти не впевнений. Нічого не редагуй, доки я не схвалю.

Де все йде не так

• План, що зачіпає більше файлів, ніж ви очікували, — тривожний знак. Перш ніж схвалювати, запитайте чому.
• У режимі планування команди для дослідження все одно запускаються. Він не робить незнайомий репозиторій безпечним для запуску.

З офіційної документації: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

Як це зробити

1. 1Відкрийте /permissions, щоб побачити всі правила й файл налаштувань, з якого походить кожне.
2. 2Спільні правила команди розробників запишіть у .claude/settings.json і зафіксуйте в репозиторії. Особисті правила — у ~/.claude/settings.json або .claude/settings.local.json.
3. 3Правила перевіряються в такому порядку: спершу deny, потім ask, потім allow, тож одне правило deny переважує будь-яке allow.
4. 4Перемикайте режими за допомогою Shift+Tab: acceptEdits схвалює редагування файлів у робочому каталозі. bypassPermissions вимикає запити й перевірки безпеки; документація радить використовувати його лише в ізольованих контейнерах або віртуальних машинах без доступу до інтернету.

Промпт для копіювання

Переглянь команди, які ти запускав у цьому сеансі. Запропонуй правила дозволів для .claude/settings.json: дозволь команди лише для читання й тестові команди, якими ми користуємося щодня, заборони все, що читає секрети або видаляє щось поза проєктом, а для всього іншого залиш запит. Поясни кожне правило одним рядком.

Де все йде не так

• Правило allow, що збігається з будь-якою командою, — те саме, що повна відсутність запитів. Дозволяйте точні команди.
• Правила в .claude/settings.json після фіксації в репозиторії діють для всієї команди. Переглядайте їх як код.

З офіційної документації: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

Як це зробити

1. 1Між не пов'язаними завданнями /clear починає нову розмову з порожнім контекстом.
2. 2У довгому завданні /compact із фокусом, наприклад «/compact збережи план і тест, що падає», підсумовує все попереднє.
3. 3Широкі пошуки передавайте субагентові: кожен працює у власному контекстному вікні, тож до вашого сеансу повертається лише його відповідь.
4. 4Claude Code також сам стискає контекст, коли наближається до ліміту; якщо стиснути його самостійно у слушний момент, збережеться те, що вибрали ви.

Вбудовано

• Claude Code · Subagents

Промпт для копіювання

/compact Збережи: мету, план, змінені досі файли й тест, який досі падає. Відкинь дослідження.

Де все йде не так

• /clear забуває розмову. Усе, що знадобиться знову, спершу запишіть у CLAUDE.md.
• Відповідь субагента — це все, що ви отримуєте. Просіть у нього шляхи до файлів і номери рядків, а не лише висновки.

З офіційної документації: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

Як це зробити

1. 1Запускайте кожен сеанс командою claude --worktree <name> (або -w). Вона створює git worktree у .claude/worktrees/<name>/ у гілці worktree-<name>.
2. 2Додайте .claude/worktrees/ до .gitignore, як радить документація.
3. 3Дайте кожному сеансу одне завдання з власною перевіркою, щоб переглядати їх по одному.
4. 4Переглядайте й зливайте кожну гілку як будь-який інший pull request.

Промпт для копіювання

Ти працюєш у worktree в гілці worktree-[назва]. Завдання: [одна зміна]. Готово, коли: [тест або команда] проходить. Роби коміти лише в цій гілці; не виконуй merge чи rebase інших гілок.

Де все йде не так

• Кожен worktree — окрема папка, тож залежності й результати збирання не спільні. Встановлюйте їх у кожному.
• Два завдання, що зачіпають ті самі файли, однаково конфліктуватимуть під час злиття, з worktree чи без.

З офіційної документації: Claude Code docs: Run parallel sessions with worktrees

Як це зробити

1. 1Двічі натисніть Esc на порожньому рядку введення або введіть /rewind (/checkpoint і /undo теж працюють).
2. 2Виберіть момент перед тим, як усе пішло не так, і відновіть розмову, код або і те, і те.
3. 3Знайте обмеження: файли, змінені shell-командами, як-от rm, mv чи cp, не відновлюються, як і редагування, зроблені поза Claude Code або в іншому сеансі.
4. 4Робіть коміт перед ризикованими кроками. Контрольні точки призначені для швидкого відновлення в межах сеансу, а не для заміни git.

Промпт для копіювання

Перш ніж почати, зроби коміт поточного стану з повідомленням «контрольна точка перед [завдання]». Потім [завдання]. Питай мене перед будь-якою командою, що видаляє або переміщує файли.

Де все йде не так

• Rewind не поверне файл, який видалила команда. Це може лише git.
• Зміни, які ви тим часом внесли вручну, теж не зберігаються. Зафіксуйте їх комітом, перш ніж робити rewind.

З офіційної документації: Claude Code docs: Checkpointing · Claude Code docs: Commands

Як це зробити

1. 1claude -p "..." працює в неінтерактивному режимі. --output-format json або stream-json дає вивід, який може розібрати скрипт.
2. 2У разі успіху він завершується з кодом 0, у разі збою — з ненульовим, тож CI може діяти залежно від результату.
3. 3Додавайте --bare у CI для запусків, які не мають залежати від локального налаштування.
4. 4Для pull request команда /install-github-app налаштовує Claude Code GitHub Actions (лише для репозиторіїв на github.com); після цього згадайте @claude у коментарі до pull request або issue.

Промпт для копіювання

claude -p "Прочитай diff відносно main. Перелічи кожну зміну, яка додає залежність, зачіпає автентифікацію або змінює міграцію бази даних, у форматі JSON: {\"files\": [], \"reason\": \"\"}. Якщо таких немає, поверни порожній список." --output-format json

Де все йде не так

• Скрипт працює з тими дозволами, які ви йому даєте. Давайте CI лише необхідний мінімум.
• /install-github-app працює лише з репозиторіями на github.com.

З офіційної документації: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

Як це зробити

1. 1Запустіть /init у CLI, щоб створити початковий AGENTS.md у поточній папці.
2. 2Особисті вказівки запишіть у ~/.codex/AGENTS.md, а правила проєкту — у репозиторій. Підпапка може мати власний файл; пріоритет мають файли, ближчі до місця, де працює Codex.
3. 3Тримайте файли короткими: їхній сумарний розмір обмежено, за замовчуванням — 32 KiB.
4. 4Додайте розділ «## Code Review Rules»: рев'ю Codex на GitHub дотримуються його.

Промпт для копіювання

Прочитай цей репозиторій і напиши AGENTS.md:
1. Точні команди для встановлення, збирання, тестування й лінтингу.
2. Структуру в кількох рядках.
3. Домовленості, які новачок тут порушує.
4. Розділ «## Code Review Rules» з тим, що рецензент завжди має позначати.
Наводь лише команди, які ти успішно запустив; решту познач як «не перевірено».

Де все йде не так

• Довгі файли працюють проти вас: сумарний розмір за замовчуванням обмежено 32 KiB.
• Файл у підпапці, який мовчки суперечить кореневому, збиває з пантелику людей так само, як Codex. Зазначайте, що саме він перевизначає.

З офіційної документації: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

Як це зробити

1. 1У CLI /permissions перемикає режим, а /status показує чинну політику схвалення й папки, доступні для запису.
2. 2«Ask for approval», рекомендований режим за замовчуванням, редагує й запускає команди в межах робочого простору та зупиняється, перш ніж вийти за них.
3. 3«Approve for me» зберігає ту саму пісочницю, але надсилає запити на схвалення на автоматичну перевірку, а не вам.
4. 4«Full access» знімає обмеження файлової системи й мережі. Документація додає застереження; залиште цей режим для середовищ, які не шкода викинути.

Промпт для копіювання

Перш ніж почати, запусти /status і скажи мені політику схвалення та папки, доступні для запису. Потім [завдання]. Питай перед будь-якою командою, якій потрібна мережа або яка записує поза цим репозиторієм.

Де все йде не так

• З «Approve for me» жодна людина не читає кожен запит. Використовуйте цей режим там, де хибну дію легко скасувати.
• «Full access» діє на всю машину, а не лише на репозиторій.

З офіційної документації: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

Як це зробити

1. 1codex exec "..." працює в неінтерактивному режимі й за замовчуванням використовує пісочницю лише для читання.
2. 2Додайте --sandbox workspace-write, коли він має редагувати файли; --full-auto застарів.
3. 3--json виводить потік подій у форматі JSON Lines для скриптів, яким потрібен кожен крок.
4. 4У GitHub Actions openai/codex-action@v1 запускає codex exec за вас.

Промпт для копіювання

codex exec "Прочитай зміни з тегу [v1.2.0]. Напиши примітки до випуску, згруповані як «Додано», «Змінено» і «Виправлено»: один рядок на зміну, словами, зрозумілими користувачеві, без хешів комітів."

Де все йде не так

• Старіші посібники досі використовують --full-auto. Цей прапорець застарів; використовуйте --sandbox workspace-write.
• Завдання, яке лише читає, має залишатися в режимі лише для читання, і в CI теж.

З офіційної документації: Codex docs: Non-interactive mode · Codex docs: GitHub Action

Як це зробити

1. 1/review у CLI переглядає вашу робочу копію. codex review робить те саме без чату — відносно базової гілки, коміту або незафіксованих змін.
2. 2На GitHub залиште в pull request коментар @codex review.
3. 3Увімкніть автоматичні рев'ю в розділі «Personal preferences» налаштувань Codex; тоді коментар не потрібен.
4. 4Запишіть правила своєї команди в розділі «## Code Review Rules» файлу AGENTS.md.

Вбудовано

• Codex · Codex code review

Промпт для копіювання

## Code Review Rules
- Позначай будь-яку зміну автентифікації чи дозволів.
- Позначай міграції бази даних без способу відкату.
- Позначай нові залежності й кажи, чи вони потрібні.
- Ігноруй форматування: ним займається лінтер.

Де все йде не так

• Рев'ю на GitHub позначають лише проблеми P0 і P1. Відсутність коментарів не означає, що архітектура правильна.
• Рев'ю — це друга думка, а не запуск тестів. Тести залишайте.

З офіційної документації: Codex docs: CLI commands · Codex docs: GitHub integration

Як це зробити

1. 1Створіть середовище з репозиторіями, залежностями, інструментами й налаштуваннями доступу, потрібними завданням. Нові середовища записують скрипт встановлення та навичку запуску (start skill).
2. 2Налаштуйте доступ до інтернету для кожного середовища: лише менеджери пакетів, вибрані домени або все.
3. 3Запускайте завдання з ChatGPT, з розширення для IDE для довших робіт або з термінала командою codex cloud exec; --attempts 1-4 просить кілька спроб для порівняння.
4. 4Code Review та інтеграції з GitHub і Linear досі працюють на старішому Codex Cloud (Legacy), який OpenAI планує вивести з ужитку.

Вбудовано

• Codex · Codex Cloud

Промпт для копіювання

codex cloud exec --attempts 3 "Завдання: [зміна]. Контекст: [файли]. Готово, коли [тест] проходить у цьому середовищі. Diff має бути меншим за [кількість] рядків."

Де все йде не так

• Необмежений інтернет дає завданню змогу звертатися до будь-якого сайту, зокрема до сторінок, написаних для того, щоб ним керувати. Дозволяйте лише те, що потрібно для роботи.
• Якщо скрипта встановлення немає, тести могли не запуститися. Перевірте, що завдання справді їх запустило.

З офіційної документації: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

Як це зробити

1. 1Задайте модель і рівень міркувань за замовчуванням у ~/.codex/config.toml (model і model_reasoning_effort). CLI і розширення для IDE користуються ним спільно.
2. 2Створіть профіль як окремий файл, ~/.codex/<name>.config.toml, і запускайте з --profile <name>.
3. 3Додавайте сервери MCP командою codex mcp add <name> -- <command>; кожен стає таблицею [mcp_servers.<name>], а /mcp показує активні.
4. 4/status показує, що діє зараз, а codex resume --last відновлює останній сеанс у цій папці.

Промпт для копіювання

Прочитай ~/.codex/config.toml і .codex/config.toml цього проєкту. Скажи мені чинні модель, рівень міркувань, пісочницю й сервери MCP, з якого файлу походить кожне з них і що конфліктує.

Де все йде не так

• Налаштування проєкту завантажуються лише для довірених проєктів. Якщо якесь здається проігнорованим, спершу перевірте це.
• Профілі тепер — окремі файли. Посібники, які розміщують [profiles.name] у config.toml, застаріли.

З офіційної документації: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands