Работа с агентом

Роутер помогает сохранить согласованные границы задачи от запроса до проверенного результата.

Что делать на каждом этапе

Пример поручения после согласования задачи:

Продолжи задачу TASK-ID через project_context. Собери пакет для её модулей и файлов, прочитай инструкции и проверь готовую реализацию. Выполни согласованные изменения, запусти проверки, сохрани evidence и итог. Если какая-то проверка недоступна, укажи причину и фактическую степень готовности.

Замените TASK-ID реальным ID. Не назначайте задаче complete только ради завершения ответа.

Согласуйте задачу

Для новой реализации используйте validate_task и confirm_task_contract. Сохраните цель, границы, критерии приёмки, риски и ожидаемые проверки. При продолжении той же задачи используйте существующий подтверждённый контракт. Уточняйте сведения по доступному контексту; спрашивайте о реальных блокерах.

Обсуждение идеи не даёт разрешения на реализацию. Используйте context-research для выводов, вариантов и результатов исследования; согласованную работу передавайте в связанный черновик backlog.

Соберите контекст

Вызовите build_context_pack с задачей и конкретными модулями/файлами. Прочитайте выбранные источники и плейбуки. Перед добавлением переиспользуемого кода вызовите find_existing_capability.

Схема сборки пакета, входные параметры и разбор ответа помогают проверить, что агент получил контекст нужной области.

npx project-context pack "Update customer service" --modules app --file src/customer.ts
npx project-context reuse-scan "CustomerService" --modules app

Нативный MCP остаётся привязан к настроенному репозиторию после shell-команды cd. Если сервер смотрит в другой проект, используйте настроенный CLI из нужного корня. Статус и дата записи описывают знание, но не доказывают работоспособность реализации.

Реализация и проверки

Получите план через get_verification_plan. Выполните проверки, прочитайте diff и используйте review_diff_for_refactor для его эвристики по выбранным файлам. Эвристика не заменяет содержательное ревью и не разрешает посторонний рефакторинг.

Сохраните реальные команды, результаты, причины пропуска и границы окружения через record_verification_evidence. Тест с локальным примером не доказывает работу боевого стенда или интеграции.

Сохранение результата

finalize_work сохраняет last_result в подтверждённой задаче. Возвращает FINALIZED, taskPath, completion и taskStatus; отдельный черновик отчёта не создаётся.

Явный partial сохраняет работу в процессе, blocked фиксирует блокер. Без явного completion статус задачи сохраняется. Для complete нужен свежий запуск ready_to_merge с независимой приёмкой. Одних успешных тестов недостаточно. Инструменты выполнения/приёмки доступны в developer, admin и full; остаются CLI-эквиваленты.

npx project-context verify-task TASK-ID
npx project-context refactor-review --task TASK-ID
npx project-context finalize-work TASK-ID --input .project-context/drafts/result.json

Замените TASK-ID на реальный ID. Минимальный файл результата:

{
  "summary": "Implemented the agreed change",
  "changedFiles": ["src/customer.ts"],
  "completion": "partial",
  "tests": [{ "command": "npm test", "status": "passed" }]
}

Подробности запусков — в инструкции execution.

Skills из пакета

npx project-context init --with-skills

project-context-workflow ведёт по этому процессу; context-research помогает исследовать идеи. Существующие копии сохраняются, обновление — вручную. Skill направляет агента, а MCP обеспечивает свои проверки. Публикация, деплой и внешние сообщения требуют разрешения на эти действия.

Необязательные хуки Codex

npx project-context init --with-hooks --with-skills

--with-hooks создаёт .codex/hooks.json с событиями UserPromptSubmit, PostToolUse и Stop. Обычный init хуки не устанавливает. Существующие файлы хуков и настройки проекта сохраняются и попадают в skipped. Если хуки уже настроены, вручную объедините их с шаблоном. Пакет должен быть установлен локально, проект — находиться в Git. Команды находят корень репозитория при работе из вложенной папки; standalone-экспорт использует собственную папку hooks/.

Просмотрите команды, разрешите доверие к проекту и подтвердите конкретные определения хуков в Codex (/hooks в CLI). При необходимости перезапустите клиент. Установка не выдаёт доверие автоматически и не доказывает, что хуки активны. См. официальную инструкцию Codex.

Хук перед запросом подсказывает рабочий процесс. Хук после инструмента отслеживает содержимое изменённых, staged, новых и удалённых файлов. Перед ответом Stop проверяет все подтверждённые задачи, чьи files пересекаются с изменениями: сначала сохраните свежие record_verification_evidence, затем finalize_work. Обязательные проверки должны пройти; для каждой нерешённой проверки нужны явный результат partial/blocked и причина в checks[].reason либо skippedChecks: [{command, reason}]. Одной даты финализации недостаточно. Новая правка исходников требует новой проверки; чтение контекста, записи задач и результатов, индексы её не сбрасывают. Повторный Stop продолжает требовать недостающие данные.

Хуки проверяют записанные результаты: они не запускают тесты, не выполняют независимую приёмку и не закрывают задачи. Не все операции клиента вызывают хуки. Для completion: "complete" по-прежнему нужен независимо принятый execution run. Честно описанный частичный результат позволяет ответить пользователю без заявления о полной готовности. Git pre-commit устанавливается отдельно: npx project-context hooks install.

Временное состояние хранится в игнорируемой папке .project-context/indexes/hook-state/; файлы неактивных сессий удаляются через семь дней. При ошибке хранения или настроек исправьте указанный путь и повторите проверку. После обновления пакета сравните свой конфиг с новым шаблоном: пользовательские файлы автоматически не заменяются.