Як скласти перевірювану умову /goal

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

Goal - це ціль з умовою завершення, яку ви задаєте агенту командою /goal. Наприклад: "грайте за обидві сторони, поки сторінка не покаже, що партія закінчена". Після чергового ходу роботи окрема модель перевіряє за розмовою, чи досягнута ціль. Якщо ще ні, робота триває без вашого "давай далі". У вас з'являється можливість дочекатися результату, хоча перешкода або помилка все ще можуть зупинити роботу раніше.

Почнемо з готової умови для гри, а потім складемо цілі для пошуку, форми і мобільної сторінки. Кожна матиме зрозумілий результат і спосіб його перевірити. Заразом розберемо, як попросити агента написати умову за вас і як відрізнити справжнє завершення від зупинки без результату.

Що продовжує /goal

У розмові навколо прикладу з грою беруть участь два різних механізми, і їх легко переплутати. Один виконує дії в браузері: клікає, вводить ходи, читає, що показує сторінка. Другий нічого не клікає - він читає розмову цілком і вирішує, продовжувати роботу далі чи ні.

Перший - це Playwright, браузерний інструмент, підключений заздалегідь через MCP. Другий запускає команда /goal. Playwright рухає фігури, /goal вирішує, чи пора зупинитися - і це два різних завдання, навіть коли збоку здається, що відбувається одне й те саме.

Важлива деталь: оцінка відбувається не після кожного кліку мишею, а після того як агент завершив свій хід роботи - грубо кажучи, свою відповідь цілком. Усередині одного такого ходу агент цілком може зробити кілька дій підряд: зробити хід фігурою, прочитати результат, відреагувати на нього. /goal підключається вже потім, коли є що оцінювати.

Підготуйте гру до запуску

Перш ніж задавати умову, приклад має бути в робочому стані: сторінка відкривається за відомою адресою, інструменти для гри на ній уже підключені (той самий Playwright), а на сторінці є мітка, за якою видно, чи закінчилася партія.

У нашому прикладі це data-атрибут: data-game-over="false" у партії, яка ще триває, і data-game-over="true" у завершеної. Таку домовленість задає той, хто написав сторінку з грою - агент її не вигадує, а просто читає.

Перевірити це легко: попросіть агента відкрити сторінку і прочитати значення атрибута. Для щойно розпочатої партії він отримає false. і це нормально, саме те, що має бути на старті.

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

Запустіть готову ціль

Далі - власне команда. Формулювання умови для нашого прикладу може мати такий вигляд:

/goal грайте по черзі за обидві сторони через інтерфейс сторінки.
Після кожного ходу читайте data-game-over і показуйте, що видно
на сторінці. Партія вважається закінченою, коли data-game-over
стає true. Якщо після 40 ходів партії це не сталося,
зупиніться і опишіть, на чому застрягли. Код гри не змінювати.

Розберемо формулювання частина за частиною. Ці самі частини знадобляться для ваших завдань:

• "грайте... через інтерфейс сторінки" - вимірна дія, яку агент реально може показати в розмові;
• "партія вважається закінченою, коли data-game-over стає true" - єдине, що тут зараховується як справжній результат. Саме це оцінювач і шукатиме в розмові;
• "після кожного ходу читайте... і показуйте" - той самий факт, за яким оцінювач взагалі зможе щось перевірити. Без цього рядка йому нема на що дивитися;
• "якщо після 40 ходів партії це не сталося, зупиніться і опишіть" - окрема інструкція на випадок, коли true так і не настане. Вона не частина успіху, а спосіб припинити роботу без нього: обмежує ціль за обсягом, але не підміняє собою результат. І це, як і раніше, інструкція в тексті, а не жорсткий програмний таймер - її теж оцінюють за розмовою;
• "код гри не змінювати" - те, що не повинно статися по дорозі, поки агент домагається результату.

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

З чого скласти свою умову

Почніть з фрази "завдання закінчено, коли...". Якщо продовження звучить як "все стало краще", агенту доведеться самому вирішувати, що ви мали на увазі. Замініть оцінку на поведінку, яку можна побачити: "після очищення пошуку знову видно всі картки". Кілька перевірок допустимі, якщо вони описують один результат, наприклад виправлений пошук.

• Назвіть результат. "Виправити пошук" задає напрямок, а "пошук знаходить картку за назвою і повертає весь список після очищення" задає точку завершення.
• Вкажіть перевірку. Напишіть, що відкрити, що ввести і яка відповідь очікується. Попросіть показати фактичний результат у розмові, щоб його міг прочитати оцінювач.
• Обмежте зміни. Якщо потрібні лише стилі, скажіть про це. Якщо агент перевіряє готову гру, забороніть змінювати її код заради потрібного результату.
• Передбачте зупинку без успіху. Наприклад, після трьох спроб виправлення з повторною перевіркою агент має описати проблему, що лишилася. Це ліміт роботи, а не ще один спосіб оголосити завдання виконаним.

Перед запуском перевірте, що агенту доступні потрібна сторінка, файли й інструменти. Адреса і назви елементів в умові мають стосуватися вашого проєкту. Текстовий ліміт спроб допомагає керувати роботою, але не є жорстким технічним обмежувачем часу чи витрат (секундомір тут не працює).

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

Три приклади для своїх завдань

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

Виправити пошук у каталозі

Припустимо, у локальному каталозі є картки "Atlas" і "Orion", але після очищення пошуку список лишається порожнім. Прохання "зроби нормальний пошук" нічого не каже про потрібну поведінку. Тут корисніше три конкретні випадки:

/goal виправте пошук у каталозі на http://localhost:3000/catalog.
Готово, коли запит "atlas" знаходить картку "Atlas",
запит "zzzz-no-match" показує "Нічого не знайдено",
а очищення поля повертає всі вихідні картки.
Перевірте всі три випадки через Playwright і покажіть у розмові
запит, очікуваний результат і фактично видимі картки
або повідомлення. Після останньої правки повторіть усі три перевірки.
Змінювати тільки логіку пошуку; дані каталогу й оформлення не змінювати.
Якщо після трьох спроб виправлення з перевіркою проблема лишилася,
зупиніться і перелічіть, які випадки ще не працюють.

Тут важливе слово "всі": одна знайдена картка ще не підтверджує, що пошук виправлено. Дані каталогу зафіксовані, тому не можна отримати потрібний результат, перейменувавши картки. А повторну перевірку після останньої правки роблять не просто так: виправлення очищення цілком могло зламати сам пошук.

Перевірити форму без правок

У цілі результатом може бути список спостережень. Припустимо, потрібно перевірити готову форму реєстрації, а виправлення ви хочете обговорити окремо. Тоді ціль закінчується після перевірки всіх випадків, навіть якщо виявлено помилки.

/goal перевірте форму на http://localhost:3000/signup
через Playwright, не змінюючи файли проєкту.
Перевірте два випадки, кожен починаючи з порожньої форми:
1. Натиснути "Зареєструватися" без заповнення полів.
Очікується підказка про обов'язкове поле, реєстрація не відбувається.
2. Ввести "alex" у поле email і заповнити решту обов'язкових
полів допустимими навчальними значеннями, потім натиснути кнопку.
Очікується помилка формату email, реєстрація не відбувається.
Готово, коли в розмові є звіт за обома випадками:
що введено, що очікувалося, що показала сторінка, чи є розбіжність.
Не надсилати форму з коректним email і не створювати акаунти.
Якщо сторінку або елемент не можна відкрити, припиніть перевірку
і вкажіть, який випадок лишився неперевіреним і чому.

Зверніть увагу на різницю: "перевірити форму" і "домогтися, щоб форма працювала" - два різних завдання. Тут помилка у формі не заважає завершити звіт, якщо агент справді перевірив обидва випадки і показав результати. Але недоступна сторінка заважає: припущення замість спостережень не закривають ціль.

Вмістити сторінку на телефоні

"Зроби красиво на мобільному" лишає занадто багато на смак агента. Виберіть конкретну сторінку, розміри вікна й елементи, які мають лишитися доступними.

/goal виправте стилі сторінки http://localhost:3000
для вікон 390x844 і 1440x900.
Готово, коли на обох розмірах немає горизонтальної прокрутки,
заголовок і кнопка "Почати" повністю видимі і не перекриваються,
а натискання "Почати" і далі відкриває розділ з грою.
Перевірте обидва розміри через Playwright після останньої правки.
Покажіть скриншоти, результат натискання і виміряні
scrollWidth і clientWidth кореневого елемента сторінки:
scrollWidth не повинен перевищувати clientWidth.
Змінювати тільки CSS. Не приховувати вміст і не обрізати його
заради відсутності прокрутки. Текст і поведінку гри зберегти.
Якщо після трьох спроб правки з перевіркою умови не виконані,
зупиніться і покажіть розбіжність, що лишилася.

Розміри тут - ширина і висота вікна браузера в пікселях. scrollWidth показує ширину вмісту з урахуванням області за краєм, а clientWidth - доступну ширину. Їхнє порівняння допомагає виявити переповнення, але саме по собі не доводить, що текст не обрізаний і кнопка доступна. Тому в умові є ще скриншоти і натискання. Два розміри теж не доводять зручність на всіх пристроях - вони задають обсяг саме цього завдання.

Попросіть агента підготувати goal

Не обов'язково писати умову з чистого аркуша. У добірці Claude Code Best Practice зібрано дві поради спільноти: попросити агента запропонувати цілі за контекстом проєкту і доручити йому скласти формулювання після читання листування і файлів. Нижче - адаптація цих прийомів для невеликого завдання.

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

Прочитайте поточне листування і файли проєкту, що стосуються завдання.
Запропонуйте три корисні цілі, які можна довести до перевірюваного
результату. Для кожної назвіть результат, спосіб перевірки,
межі змін і те, чого поки бракує для запуску.
Спирайтеся на наші домовленості. Цілі поки не запускайте,
файли не змінюйте. Якщо намір незрозумілий, поставте запитання.

Виберіть одну ціль. Довга робота сама по собі не перевага: корисніше виправлений пошук, ніж кілька годин невизначених "покращень". Коли завдання вже зрозуміле, перший запит можна пропустити і одразу попросити чернетку умови:

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

Перед надсиланням чернетки перевірте сенс. Чи збігається результат з тим, що ви хотіли? Чи існує вказана сторінка? Чи не дозволив агент заодно змінювати дані або додавати функції? Якщо внизу лишилися неясності, спочатку розберіть їх. Запускати варто вже уточнений текст: команда /goal одразу починає роботу.

Подивіться стан і зупиніть роботу

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

Зупинити ціль достроково теж можна - командою /goal clear. Вона знімає умову, навіть якщо партія ще не закінчилася.

На два з цих варіантів завершення можна покладатися як на підтверджений результат: умова виконана, і це видно з відповіді оцінювача в розмові, або ціль знята вручну командою /goal clear раніше, ніж щось було доведено. Решта способів, якими ціль може зупинитися сама, до цих двох не належать - і результату не підтверджують.

Що отримує перевірювальна модель

Оцінювач /goal бачить не саму сторінку, а розмову: те, що агент написав, і те, що він туди скопіював зі спостережень браузера. Власних інструментів оцінювач не має - він не відкриває сторінку заново і не виконує команди сам, лише читає вже накопичений текст.

Звідси простий наслідок. Фраза агента "партія закінчена" сама по собі нічого не доводить ні оцінювачу, ні вам. Доводить результат, який агент реально прочитав зі сторінки - те саме значення data-game-over. Перше - рапорт, друге - спостереження, і це різні речі, навіть якщо звучать схоже.

Варто розуміти і межі самої ознаки. data-game-over повідомляє стан конкретного застосунку - те, що заклав у нього автор сторінки. Він нічого не каже про те, що вся партія цілком зіграна за правилами шахів без жодної помилки. Так само й відсутність прокрутки не доводить, що кнопка працює. Вибирайте ознаку для того результату, який справді хочете отримати, і не приписуйте їй зайвого.

Що це змінює в роботі

Для свого завдання можна пройти той самий короткий маршрут:

• зрозумілий результат і доступний спосіб його перевірити;
• умова з межами правок і зупинки, задана командою /goal;
• статус, який можна подивитися в будь-який момент - /goal без аргументів;
• підсумок, підкріплений спостереженнями і результатами перевірок;
• ціль, знята вручну командою /goal clear, якщо робота застрягла або умова виявилася невдалою.

Автоматичне продовження роботи і рішення про те, що робити далі, - це дві різні речі. Перше можна довірити /goal усередині однієї сесії. А ось розбиратися, що реально вийшло, знімати незакінчену ціль і ставити наступне завдання - тут, як і раніше, рішення за вами.

Точна поведінка оцінювача і формат статусу можуть трохи відрізнятися залежно від версії Claude Code. Загальний принцип - оцінка за розмовою, а не за прямим доступом до сторінки - зберігається.