| name | goal-pursuit |
| description | Use when the user wants to achieve multi-step development goals using structured goal mode. Guides the agent through creating, driving, completing, blocking, and resuming goals with clear state management and user interaction patterns. |
Goal Pursuit
Достижение целей в разработке с помощью структурированного режима goal. Этот skill реализует механику, описанную в GOAL.md, в виде практических инструкций для агента.
Обзор
Режим goal позволяет агенту выполнять многошаговые задачи автономно, с контролем состояния, возможностью паузы/возобновления и прозрачностью для пользователя. Этот skill учит агента правильно создавать, вести и завершать цели.
Ключевая идея: цель — это не просто запрос в чате, а структурированное состояние с жизненным циклом: active → paused/blocked → complete.
1. Когда использовать goal mode
Используй goal mode, когда задача требует трёх и более последовательных шагов, которые не требуют постоянного подтверждения пользователя.
✅ Подходит для goal
- Рефакторинг большого модуля (разбить на файлы, обновить импорты, поправить тесты)
- Добавление новой функциональности (создать компонент, стили, тесты, документацию)
- Миграция кода с одной версии API на другую
- Исследование кодовой базы и документирование архитектуры
- Автоматическое исправление серии однотипных ошибок в нескольких файлах
❌ НЕ подходит для goal
- Одношаговый запрос («создай файл», «напиши функцию»)
- Вопрос, требующий только информации («как работает X?»)
- Дискуссия или brainstorming
- Задача, где каждый шаг требует решения пользователя
Правило принятия решения
Если пользователь явно сказал «запусти goal», «сделай в фоне», «выполни автономно» — создавай goal. Если пользователь просто задал вопрос или дал задачу, не предполагающую много шагов — не создавай goal.
2. Создание цели (CreateGoal)
Проверки перед созданием
- Цель не пустая — есть конкретное описание того, что нужно сделать.
- Цель не слишком длинная — умещается в разумный абзац.
- Нет уже активной цели — если есть active/paused/blocked goal, предложи пользователю завершить или отменить старую перед созданием новой.
Структура хорошей цели
Хорошая цель должна содержать:
- end state: какие условия должны стать истинными (что значит «готово»)
- proof: какие observable-доказательства подтвердят завершение (проходят тесты? собран билд?)
- boundaries: область работы — какие файлы/модули трогать можно, какие нельзя
- loop: как итеративно продвигаться (по файлам, по этапам)
- stop rule: когда остановиться и сообщить пользователю, а не продолжать насильно
Пример формулировки цели
Рефакторинг модуля валидации в src/validation/
end state: Все функции вынесены в отдельные файлы по доменам,
старый index.ts перенаправляет экспорты, тесты проходят.
proof: pnpm test --filter validation проходит,
git diff показывает только перемещения и новые файлы.
boundaries: Не трогаем src/validation/types/ — там другая ответственность.
Не меняем публичное API.
loop: По одному домену за раз: strings → numbers → dates → compose.
stop rule: Если тесты падают и не удаётся починить за 3 попытки → blocked.
3. Жизненный цикл цели в работе
Active — выполнение
Когда цель активна, каждый твой turn — это шаг к её достижению.
Правила работы в active:
- Короткая самопроверка в начале каждого turn'а: «Что сделано? Что делать дальше?»
- Один связный фрагмент за turn — не пытайся сделать всё сразу.
- После каждого turn'а система сама проверит, активна ли цель, и продолжит.
- Не проси пользователя подтверждать каждый шаг — для этого есть paused/blocked.
Что делать НЕЛЬЗЯ:
- Не помечай complete, если сделал только план или первую версию.
- Не помечай complete, если не проверил результат (тесты, сборка, линтер).
- Не уходи в сторону от цели — не начинай несвязанную работу.
- Не говори пользователю «готово» на естественном языке — используй структурированный сигнал.
Paused — пауза
Цель приостанавливается, когда:
- Пользователь нажал паузу или прервал выполнение.
- Произошла техническая ошибка (rate limit, сбой provider'а, ошибка runtime).
- Сессия восстановлена, и активная цель понижена до paused (безопасность).
Что делать:
- Продолжай обрабатывать обычные запросы пользователя.
- Не пытайся автономно возобновить цель — жди явной команды от пользователя.
- Если пользователь спросит про цель, напомни, что она приостановлена, и спроси, возобновлять ли.
Blocked — блокировка
Цель блокируется, когда:
- Требуется внешний ввод или решение пользователя.
- Цель не может быть выполнена в текущей формулировке.
- Prompt hook запретил выполнение.
- Достигнут лимит бюджета (turn'ы, токены, время).
Что делать:
- Объясни пользователю, что именно заблокировало цель.
- Скажи, какой ввод или изменение нужны для продолжения.
- После получения необходимого — переведи цель обратно в active.
Complete — завершение
Цель завершается, когда:
- Все требования выполнены ✅
- Проверки пройдены (тесты, сборка, линтер) ✅
- Нет дальнейших полезных действий в рамках этой цели ✅
При завершении:
- Отправь сигнал complete через структурированное обновление состояния.
- Дай пользователю краткое резюме:
- Что сделано
- Какие проверки были запущены и их результаты
- Ключевые изменения (файлы, API, архитектура)
4. Continuation prompt — что проверять на каждом круге
Когда цель активна и runtime запускает continuation, ты должен заново оценить:
- Завершено? — Все ли пункты end state достигнуты? Все ли proof-проверки пройдены?
- Заблокировано? — Есть ли внешнее препятствие, которое нельзя обойти без пользователя?
- Следующий шаг? — Какой один связный фрагмент работы сделать сейчас?
- Не отклонился? — Не ушёл ли я в сторону от изначальной цели?
5. Типичные сценарии применения в разработке
Сценарий A: Рефакторинг
Цель: Переписать модуль X с использованием новой архитектуры.
Особенность: Идём по файлам, после каждого — тесты.
Стоп-правило: Если тесты падают — blocked, показываем ошибку пользователю.
Сценарий B: Добавление фичи
Цель: Добавить поддержку формата Y в парсер.
Особенность: Реализация → тесты → документация → примеры использования.
Стоп-правило: Если документация не готова — не complete.
Сценарий C: Исследование кодовой базы
Цель: Составить карту зависимостей между модулями A, B, C.
Особенность: Один модуль за раз, запись результатов в MARKDOWN.
Стоп-правило: Если модуль слишком сложный — blocked, запросить уточнение.
Сценарий D: Автоматическое исправление
Цель: Исправить однотипную ошибку линтера во всех файлах пакета.
Особенность: Пакет за пакетом, после каждого — проверка линтером.
Стоп-правило: Если автофикс недоступен — blocked, показать список файлов.
6. Правила безопасности и взаимодействия с пользователем
Модель не должна:
- Создавать goal без явного запроса пользователя, если только хост-система не требует этого.
- Повышать обычный запрос до goal — это решение пользователя.
- Изобретать бюджет (лимиты turn'ов, токенов, времени) — только если пользователь явно задал硬限制.
- Продолжать paused/blocked goal при получении обычного сообщения — ждать явной команды.
Модель должна:
- После каждого complete давать краткое резюме.
- После каждого blocked объяснять причину и необходимые действия.
- При отмене (cancel) игнорировать старый active reminder — не продолжать отменённую цель.
- При resume очищать старую причину остановки и начинать новую попытку.
Fork сессии
При создании fork'а сессии:
- Цель не наследуется от исходной сессии.
- Модель не должна продолжать старую цель.
- Нужно напомнить модели об этом правиле.
7. Вспомогательные инструменты
write-goal — помощь в формулировке цели
Если пользователь не уверен, как сформулировать цель:
- Задай уточняющие вопросы: «Что должно быть готово? Как проверить?»
- Предложи структуру с end state, proof, boundaries, loop, stop rule.
- После утверждения пользователем — создавай goal.
GetGoal, SetGoalBudget, UpdateGoal
Эти инструменты изменяют только runtime-состояние цели.
- По умолчанию могут быть одобрены легче.
- Настоящая запись файлов, запуск shell, доступ к путям — через обычную систему разрешений.
8. Аварийные ситуации
Технические сбои (→ paused)
- Прерывание пользователем
- Rate limit
- Ошибка подключения/аутентификации/API provider'а
- Ошибка конфигурации модели
- Исключение runtime
- Safety filter
Восстановление: после исправления причины пользователь явно вызывает resume.
Бизнес-блокировки (→ blocked)
- Prompt hook阻止了 цель
- Модель определила невозможность продолжения
- Достигнут бюджет
- Требуются новые условия от пользователя или внешней системы
Восстановление: пользователь предоставляет необходимый ввод или меняет условия.
Заключение
Goal mode — это мощный инструмент для автономной многошаговой разработки. Используй его осознанно:
- Создавай цель только когда задача действительно многошаговая.
- Формулируй цель чётко: end state, proof, boundaries, loop, stop rule.
- Работай по одному шагу за раз, перепроверяй на каждом continuation.
- Завершай только когда всё сделано и проверено.
- При блокировках чётко объясняй причину и необходимые действия.
- Не пытайся обойти paused/blocked — жди явной команды от пользователя.
