Baton

1. Что такое Baton

Baton — консольная утилита ./baton и набор скиллов для ИИ-агентов Codex и Claude Code. Она ведёт задачу от описания до слитого Pull/Merge Request и следит, чтобы агенты работали по правилам: не пропускали проверки, не меняли то, что менять нельзя, и не создавали PR в обход ревью.

Проект на Baton — это корневой репозиторий-оркестратор, к которому репозитории проекта (backend, frontend и т. д.) подключены Git-сабмодулями. Одна задача может затрагивать несколько репозиториев сразу: в каждом создаётся своя ветка и свой PR/MR.

В работе участвуют:

• Вы — ставите задачу, подтверждаете ключевые шаги, принимаете или отклоняете результат.
• Координатор — ваша сессия Codex или Claude Code, в которой вы вызываете скиллы $plan, $implement, $revise. Он пишет план, запускает остальных агентов и собирает результат. Код в репозиториях он сам не пишет.
• Исполнители (implementer) — отдельные агенты, по одному на репозиторий. Работают параллельно, каждый в своём репозитории, в sandbox без сети, и коммитят изменения.
• Critic — независимый агент, который проверяет план до реализации.
• Checker — независимый агент, который проверяет реализацию до создания PR/MR.
• Changelog — агент, который после слияния кратко описывает изменения задачи.

По умолчанию исполнители работают на Codex, а проверяющие — на Claude Code. Модели и runner'ы настраиваются, см. Агенты и модели.

2. Как проходит задача

1. Обсуждение (по желанию): $research помогает сформулировать задачу и выдаёт готовый текст Issue.
2. Задача: ./baton create-issue создаёт Issue в GitHub/GitLab или задачу в Plane.
3. План: $plan 42 исследует код, пишет технический план, отправляет его critic и публикует комментарием в задаче.
4. Реализация: $implement 42 создаёт ветки, запускает исполнителей, проверки, E2E и checker, затем открывает PR/MR как черновики.
5. Правки (сколько угодно раз): $revise 42 <что поправить> — нумерованная ревизия в тех же ветках и PR/MR.
6. Итог: ./baton approve 42 сливает PR/MR, или ./baton reject 42 отклоняет реализацию и возвращает задачу к утверждённому плану.

В любой момент ./baton status 42 показывает, на каком этапе задача и что сейчас делают агенты.

↑ к началу

3. Требования

3.1. Обязательные

• Платформа: Linux или macOS, процессор amd64 (x86_64) или arm64 (Apple Silicon, ARM-серверы). Windows не поддерживается — используйте WSL 2.
• bash, curl, sha256sum (Linux) или shasum (macOS) — для установки.
• git с поддержкой сабмодулей.
• CLI Git-провайдера, авторизованный: gh для GitHub (gh auth login) или glab для GitLab (glab auth login). Нужен всегда: через него создаются и сливаются PR/MR, а при задачах в Git-провайдере — ведутся Issue.
• Авторизованные CLI агентов для каждого runner'а из настроек: codex (Codex CLI, по умолчанию у исполнителей) и claude (Claude Code, по умолчанию у проверяющих).
• Для claude на Linux — пакеты bubblewrap (bwrap) и socat: без них Claude Code не включит sandbox, и Baton его не запустит. На macOS не нужны.
• Для задач в Plane — доступ к серверу Plane и личный API-ключ.
• Доступ к этому серверу — для установки и обновления Baton.

Всё перечисленное проверяет ./baton doctor, см. Проверка окружения.

3.2. Для E2E-тестов

Нужны, если E2E включены (e2e.enabled: true, по умолчанию). Отключить для проекта: ./baton init --no-e2e или e2e.enabled: false; для одной задачи: $plan 42 --no-e2e.

• Node.js и менеджер пакетов (bun, npm и т. п.).
• package.json с @playwright/test в корне оркестратора и установленные зависимости: должен существовать ./node_modules/.bin/playwright.
• Браузеры Playwright: bunx playwright install или npx playwright install.
• playwright.config.* в корне оркестратора с адресом тестируемого приложения.
• Запущенное приложение и тестовые данные. Как их запускать и готовить, решает проект — Baton этого не делает.

↑ к началу

4. Установка и настройка

4.1. Новый проект с нуля

Создайте корневой репозиторий и подключите репозитории проекта сабмодулями:

mkdir my-project && cd my-project
git init
git remote add origin git@github.com:acme/my-project.git

git submodule add git@github.com:acme/backend.git backend
git submodule add git@github.com:acme/frontend.git frontend

Если репозиторий-оркестратор уже есть, переходите к следующему шагу.

4.2. Подключить Baton

В корне оркестратора:

curl -fsSL https://baton.example.com/install.sh | bash
./baton init

Установщик скачивает ./baton в текущий каталог и проверяет контрольную сумму. Конкретная версия: curl -fsSL https://baton.example.com/install.sh | bash -s -- 1.4.0.

init спрашивает Git-провайдер, провайдер задач (Issue в Git-провайдере или Plane), базовую ветку и нужны ли E2E. Затем создаёт:

• baton.yml — настройки проекта;
• скиллы в .ai/skills/ и манифест .ai/skills/.baton.json с версией Baton;
• ссылки .claude/skills и .codex/skills, чтобы оба агента видели скиллы;
• шаблоны Issue и PR/MR для выбранного провайдера;
• .env.example с описанием переменных;
• README.md с инструкциями для команды, если его ещё нет (существующий не меняется);
• строки в .gitignore: бинарник ./baton, .env и локальное состояние .baton/ в Git не попадают.

Неинтерактивный вариант:

./baton init --yes --git github --issue git --base-branch dev --no-e2e

Закоммитьте настройку:

git add .
git commit -m "chore: подключить Baton"
git push -u origin HEAD

4.3. Файл .env

Модели агентов и доступ к Plane задаются в .env рядом с baton.yml. Создайте его по образцу:

cp .env.example .env

Пустая переменная означает значение по умолчанию. Переменные окружения shell имеют приоритет над .env.

4.4. Проверка окружения

./baton doctor

Команда проверяет всё, что нужно для работы, и печатает таблицу с результатом по каждому пункту:

• baton.yml корректен, .env создан;
• git установлен, сабмодули инициализированы;
• скиллы Baton установлены и совпадают с версией бинарника, ссылки .claude/skills и .codex/skills работают;
• gh/glab установлен и авторизован;
• codex/claude из ваших профилей установлены и авторизованы, для Claude Code на Linux есть bwrap и socat;
• Plane доступен и статусы из настроек существуют;
• для E2E есть node, Playwright и playwright.config.*.

У каждой ошибки указано, как её исправить. Если есть хотя бы одна ошибка, команда завершается с кодом 1. Запускайте doctor после установки, после клонирования проекта и при любой непонятной ошибке окружения.

4.5. Коллеге после git clone

git clone --recurse-submodules git@github.com:acme/my-project.git
cd my-project
curl -fsSL https://baton.example.com/install.sh | bash
cp .env.example .env
./baton doctor

Установщик ставит ту версию Baton, что записана в .ai/skills/.baton.json, — ту же, что у остальной команды. Если проект склонирован без --recurse-submodules: git submodule update --init --recursive.

↑ к началу

5. Работа с задачей

5.1. Где что запускать

• Скиллы вызываются в чате агента, запущенного в корне оркестратора: $plan 42 в Codex, /plan 42 в Claude Code. Дальше на этой странице используется запись $plan.
• Команды ./baton запускаются в терминале, в корне оркестратора.
• Команды ./baton ai … служебные: их вызывают агенты по инструкциям скиллов. Запускать их вручную не нужно.

5.2. Обсудить задачу: $research

$research Хочу выгружать координаты площади в CSV

Необязательный шаг. Агент проверяет описание по кодовой базе, называет сложные места и задаёт вопросы — по одному, пока всё не прояснится. Код и Git он не трогает, Issue не создаёт.

В конце он записывает готовый текст задачи в .baton/research/<дата>-<название>.md и выводит его целиком для копирования. Разделы: заголовок, «Проблема», «Требуемый результат», «Как воспроизвести» (для ошибок), «Критерии приемки», «Решения и ограничения». Если нужно что-то поменять, просто скажите — агент обновит тот же файл.

5.3. Создать задачу: create-issue

./baton create-issue

Команда по очереди спрашивает заголовок, проблему, требуемый результат, шаги воспроизведения (необязательно) и критерии приемки, затем создаёт задачу у провайдера из baton.yml. В многострочных полях новая строка — Ctrl+J, завершить ввод — Enter.

Дополнительные аргументы передаются в gh issue create / glab issue create, например ./baton create-issue --label ai. Постоянные аргументы задаются в issue.providers.git.create_args.

Задачу можно создать и обычным способом в GitHub, GitLab или Plane — Baton работает с любой существующей задачей. Хорошая задача содержит проверяемые критерии приемки: план и checker сверяются именно с ними.

5.4. Спланировать: $plan

$plan 42
$plan 42 --no-critic
$plan 42 --no-e2e

Вместо номера можно передать ссылку на задачу или её код в Plane, например LKPS-50.

Что происходит

1. Агент показывает состояние Git-репозиториев и ждёт вашего подтверждения. Ответьте «да», чтобы продолжить. Незакоммиченные изменения сами по себе не мешают.
2. Загружает задачу в .baton/tasks/<провайдер>/42/issue.md. В Plane задача переводится в статус из states.in_progress.
3. Исследует код: существующие решения, контракты, тесты, правила репозиториев (AGENTS.md, скиллы).
4. Если без вашего решения не обойтись, задаёт один конкретный вопрос и ждёт ответа. Ответьте в чате — он продолжит.
5. Пишет plan.md: контекст, критерии приемки дословно из задачи, спецификацию поведения, контракты между репозиториями, отдельный блок для каждого репозитория (файлы, шаги, проверки) и E2E-сценарии.
6. Baton проверяет формат плана. Если формат нарушен, агент исправляет план сам.
7. План проверяет critic. Если есть замечания, агент исправляет обоснованные и отправляет план на повторную проверку. Число проверок ограничено (по умолчанию 3, см. Лимиты). Если лимит исчерпан, агент остановится и перечислит нерешённые замечания.
8. Утверждённый план публикуется комментарием в задаче. Повторная публикация обновляет тот же комментарий.

Флаги

5.5. Реализовать: $implement

$implement 42
$implement 42 --no-check

Что происходит

1. Ветки. Агент показывает состояние Git и ждёт подтверждения. После «да» Baton создаёт в каждом репозитории из плана рабочую ветку от свежей базовой ветки (по умолчанию ai/42-<название-задачи>) или переключается на уже существующую.
2. Исполнители. Baton запускает по исполнителю на каждый репозиторий, параллельно (по умолчанию до 4 одновременно). Каждый видит общий контекст плана и свой блок, работает только в своём репозитории, выполняет проверки из плана и коммитит результат. Перед запуском репозиторий должен быть чистым.
3. Сверка. Агент проверяет ветки, коммиты и чистоту деревьев.
4. Проверки. Агент повторно запускает проверки из плана (lint, типы, unit-тесты) уже вне sandbox исполнителей.
5. E2E. Если E2E нужны, агент пишет запланированные Playwright-сценарии и запускает их точечно.
6. Checker. Независимый checker проверяет весь diff по критериям приемки. При замечаниях исполнители нужных репозиториев получают их и исправляют, после чего проверка повторяется — до одобрения или исчерпания лимита.
7. PR/MR. Агент пишет описание (что изменено, критерии, выполненные проверки, ссылка на план), Baton пушит ветки и создаёт PR/MR черновиками во всех репозиториях с одним заголовком в формате Conventional Commits.
8. Агент сообщает ветку, ссылки на PR/MR и результаты проверок.

Пока идёт реализация, следите за ней через ./baton status 42 --watch в соседнем терминале, см. Наблюдение за работой.

Если что-то пошло не так

• Исполнитель вернул BLOCKED (не может продолжить без решения) или ERROR (техническая ошибка) — агент остановится и покажет причину, результаты проверок и путь к логу. Повторный запуск исполнителей — только по вашему указанию: скажите агенту «перезапусти исполнителей».
• Проверка упала из-за изменений задачи или E2E нашли дефект — агент остановится и опишет, что упало.

Флаг --no-check

Пропускает checker: PR/MR создаётся сразу после проверок и E2E. Используйте для мелких изменений, если готовы проверить код сами.

5.6. Внести правки: $revise

$revise 42 Сделать кнопку круглой
$revise 42 1) Переименовать колонку «Дата» в «Создано». 2) Сортировать по убыванию.

Правки после создания PR/MR вносятся ревизиями. Каждая ревизия:

1. получает следующий номер (1, 2, 3…);
2. записывает ваш текст без изменений и разбивает его на адресные правки по репозиториям в revisions/<номер>/request.md;
3. запускает исполнителей только в затронутых репозиториях;
4. проверяет результат checker'ом — всегда, пропустить нельзя;
5. пушит коммиты в те же ветки и PR/MR — новые не создаются.

Ревизии идут строго по очереди: следующая начинается после того, как предыдущая одобрена и опубликована. Правки, присланные во время ревизии, войдут в следующую.

5.7. Слить: approve

./baton approve 42

Запускается в терминале, когда вы проверили PR/MR и всё устраивает. По шагам:

1. Проверяет, что у всех репозиториев есть PR/MR и последняя ревизия, если она есть, одобрена и опубликована.
2. Запускает полный набор E2E, если они не были отключены для задачи. Если тесты упали, ничего не сливается.
3. Снимает с PR/MR отметку черновика и сливает их способом из git.merge_method (по умолчанию merge). Рабочие ветки удаляются.
4. Закрывает задачу при issue.close_on_approve: true. В Plane задача переходит в статус из states.done либо, если закрытие выключено, из states.in_review.
5. Агент changelog описывает изменения: запись с датой, списком изменений и диапазонами коммитов добавляется в .baton/tasks/CHANGELOG.md и комментарием в задачу.

5.8. Отклонить: reject

./baton reject 42

Если реализация не подходит и проще начать её заново. Команда:

• закрывает открытые PR/MR;
• удаляет рабочие ветки локально и в origin;
• удаляет артефакты реализации и сбрасывает checker и ревизии.

Задача, утверждённый план и его публикация сохраняются, поэтому можно сразу запустить $implement 42 заново или сначала поправить план через $plan 42. Отклонить нельзя, если какой-то PR/MR уже слит или в репозитории есть незакоммиченные изменения.

↑ к началу

6. Наблюдение за работой: status

./baton status              # все задачи и их этапы
./baton status 42           # подробно об одной задаче
./baton status 42 --watch   # то же с обновлением каждые 2 секунды, выход — Ctrl+C

Команда только читает локальные файлы Baton: она не обращается к агентам и не тратит токены. Удобно держать --watch в соседнем терминале, пока работают исполнители.

Список задач

╭────┬──────────────────────────┬──────────────────────────────┬────────╮
│ №  │ Задача                   │ Этап                         │ Агенты │
├────┼──────────────────────────┼──────────────────────────────┼────────┤
│ 42 │ Выгрузка координат в CSV │ реализация, checker: pending │ 2      │
│ 37 │ Фильтр по дате           │ PR/MR открыт                 │ -      │
╰────┴──────────────────────────┴──────────────────────────────┴────────╯

Этапы: «планирование», «планирование: замечания critic», «план одобрен, не опубликован», «план утверждён», «реализация, checker: …», «PR/MR открыт», «ревизия N: …», «слита». «Агенты» — сколько агентов задачи работает прямо сейчас.

Одна задача

Показывает статусы плана, critic и checker с числом использованных проверок (например, «проверок 1 из 3»), режим E2E, таблицу репозиториев с ветками и ссылками на PR/MR, список ревизий и запущенных агентов:

Запущенные агенты
╭─────────────────────┬───────────────────┬───────────┬────────────┬───────────────────────────╮
│ Агент               │ Модель            │ Работает  │ Активность │ Последнее действие        │
├─────────────────────┼───────────────────┼───────────┼────────────┼───────────────────────────┤
│ implementer backend │ codex gpt-6-astra │ 12m из 2h │ 3s назад   │ команда: bun run lint     │
│ implementer web     │ codex gpt-6-astra │ 12m из 2h │ 40s назад  │ правка файлов: src/map.ts │
╰─────────────────────┴───────────────────┴───────────┴────────────┴───────────────────────────╯
Логи:
  .baton/logs/git/42/20261114T101500.000000000Z-implementer-backend.jsonl

• Работает — сколько агент уже работает и его лимит времени, если он задан.
• Активность — когда агент последний раз что-то записал в лог. Если активности нет долго, агент, скорее всего, завис; его остановит лимит времени.
• Последнее действие — команда, правка файлов, размышление или сообщение агента.
• Если Baton был аварийно завершён, а агент продолжает работать, в строке будет «Baton завершён, агент работает без него» и команда, чтобы его остановить. Такого агента Baton также остановит сам при следующем запуске агентов этой задачи.

↑ к началу

7. Остановка, сбои и лимиты

Остановить агентов

Прервите работу координатора или нажмите Ctrl+C в терминале с командой ./baton. Baton остановит всех запущенных им агентов вместе с их дочерними процессами и сохранит логи. Повторный Ctrl+C завершает Baton немедленно. Незавершённые исполнители получают статус ERROR.

Лимиты времени

Critic и checker по умолчанию останавливаются через 1 час, changelog — через 15 минут. Для исполнителей лимит по умолчанию не задан: включите его через implementation.worker_timeout. Агент, превысивший лимит, останавливается с ошибкой «агент превысил timeout». См. Лимиты.

Лимит проверок

Critic проверяет план, а checker — реализацию не больше max_iterations раз (по умолчанию 3; для checker счётчик отдельный у первоначальной реализации и у каждой ревизии). Лимит соблюдает сам Baton: сверх него проверка не запускается, и агент останавливается со списком нерешённых замечаний. Дальше решаете вы: поправить план или код вручную, отклонить реализацию или увеличить лимит в baton.yml.

Повторить после сбоя

• Исполнитель упал или был остановлен — скажите координатору перезапустить исполнителей. В ревизии повторный запуск возьмёт только незавершённые репозитории.
• Упал approve — устраните причину и запустите его снова: слитые PR/MR будут пропущены.
• Не записался changelog после слияния — ./baton ai changelog 42.

Логи

Полный вывод каждого агента пишется во время работы в .baton/logs/<провайдер>/<номер>/: файл *.jsonl на каждый запуск и *.stderr.log при ошибке. Там же usage.jsonl — расход токенов каждого запуска.

↑ к началу

8. E2E-тесты

• Тесты лежат в корне оркестратора: сценарии — в e2e/specs/, fixtures — в e2e/fixtures/, работа с БД — в e2e/db/, seeds — в e2e/seeds/.
• План описывает минимальный Playwright-сценарий для каждого наблюдаемого критерия приемки. Реализацию и запуск выполняет координатор при $implement и $revise, точечно — только запланированные файлы.
• Перед слиянием ./baton approve запускает полный набор.
• Приложение и тестовые данные к моменту запуска должны быть подготовлены.

./baton run-tests                              # весь набор
./baton run-tests e2e/specs/export.spec.ts     # отдельный файл
./baton run-tests --grep "экспорт"             # любые аргументы Playwright

Команда запускает ./node_modules/.bin/playwright test и печатает краткую таблицу результатов; подробный отчёт — в test-results/e2e-report.json.

↑ к началу

9. Настройка baton.yml

Подсказки и проверка в редакторе работают через схему, подключённую первой строкой файла; ссылка обновляется вместе с Baton. В любом строковом значении можно сослаться на переменную окружения: ${VAR} или ${VAR:-значение по умолчанию}.

9.1. Полный пример

Обязательны только git.provider и issue.provider; для остального указаны значения по умолчанию.

# yaml-language-server: $schema=https://baton.example.com/releases/<версия>/baton.schema.json

# env_file: .env              # по умолчанию .env рядом с baton.yml, если он есть

storage:
  root: .baton                # локальное состояние Baton
  tasks_dir: tasks

git:
  provider: github            # github или gitlab
  merge_method: merge         # merge, squash или rebase

issue:
  provider: git               # git — Issue в GitHub/GitLab, plane — задачи Plane
  close_on_approve: false     # закрывать задачу после baton approve
  providers:
    git:
      create_args: []         # аргументы gh/glab для create-issue, например ["--label", "ai"]

e2e:
  enabled: true

implementation:
  default_base_branch: dev
  worker_timeout: 2h          # лимит времени исполнителя; по умолчанию без лимита
  max_parallel_workers: 4
  branch_name: "ai/{{ issue.number }}-{{ issue.slug }}"
  allow_root_repository: false

agents:
  profiles:
    implementer:
      runner: "${IMPLEMENTER_RUNNER:-codex}"
      model: "${IMPLEMENTER_MODEL:-gpt-6-astra}"
      reasoning_effort: "${IMPLEMENTER_REASONING_EFFORT:-xhigh}"
    reviewer:
      runner: "${REVIEWER_RUNNER:-claude}"
      model: "${REVIEWER_MODEL:-claude-opus-5-5}"
      reasoning_effort: "${REVIEWER_REASONING_EFFORT:-high}"
  roles:
    implementer: implementer
    critic: reviewer
    checker: reviewer
    changelog: reviewer
  limits:
    critic:
      timeout: 1h
      max_iterations: 3
    checker:
      timeout: 1h
      max_iterations: 3
    changelog:
      timeout: 15m

repositories:
  backend:
    agent: implementer
    base_branch: main
  frontend: {}

9.2. Агенты и модели

Профиль — набор настроек агента: runner (codex или claude), model, reasoning_effort и необязательный sandbox. Роли назначают профили исполнителю, critic, checker и changelog. Профилей может быть сколько угодно: например, отдельный дешёвый профиль для changelog.

sandbox: workspace-write — запись только в свой репозиторий (по умолчанию у исполнителей, иначе они не смогут работать), read-only — только чтение (по умолчанию у critic, checker и changelog).

9.3. Лимиты

Время задаётся в формате 30m, 1h30m; 0 отключает лимит. Можно указать только нужные поля — остальные сохранят значения по умолчанию. Изменение лимитов действует и на уже начатые задачи.

9.4. Репозитории

Раздел repositories необязателен: в задачу попадает любой сабмодуль, который нужен по плану. Ключ — путь сабмодуля. Настройки:

• agent — профиль исполнителя для этого репозитория (например, Claude Code для фронтенда и Codex для бэкенда);
• base_branch — своя базовая ветка вместо implementation.default_base_branch.

9.5. Plane

issue:
  provider: plane
  providers:
    plane:
      url: "${PLANE_URL}"                 # адрес сервера Plane
      workspace: "${PLANE_WORKSPACE}"     # slug рабочего пространства
      project: "${PLANE_PROJECT}"         # код проекта, например LKPS для задач LKPS-50
      project_id: "${PLANE_PROJECT_ID}"   # UUID проекта
      api_key: "${PLANE_API_KEY}"         # личный API-ключ
      states:                             # имена или UUID статусов
        in_progress: "In Progress"
        in_review: "In Review"
        done: "Done"

Значения задаются в .env. Статусы: in_progress — когда начинается планирование, in_review — после слияния при выключенном close_on_approve, done — после слияния при включённом. PR/MR добавляются в задачу ссылками. Доступ и статусы проверяет ./baton doctor.

↑ к началу

10. Где лежат файлы

Всё локальное состояние хранится в .baton/ (или в storage.root) и в Git не попадает.

.baton/
  research/                        тексты задач из $research
  tasks/
    CHANGELOG.md                   журнал изменений слитых задач
    <провайдер>/<номер>/
      issue.md                     исходная задача
      plan.md                      технический план
      critique.md                  отчёт critic
      review.md                    отчёт checker
      pr.md                        описание PR/MR
      changelog.md                 запись об изменениях задачи
      workflow.json                состояние задачи (меняет только Baton)
      revisions/<номер>/
        request.md                 правки ревизии
        review.md                  отчёт checker ревизии
  logs/<провайдер>/<номер>/
    *.jsonl                        полный вывод каждого запуска агента
    *.stderr.log                   ошибки неуспешного запуска
    usage.jsonl                    расход токенов

↑ к началу

11. Обновление Baton

./baton update --check   # проверить, есть ли новая версия
./baton update           # обновить бинарник, скиллы и шаблоны
./baton update --force   # обновить с перезаписью изменённых вручную скиллов и шаблонов

update скачивает последнюю версию, проверяет контрольную сумму и заменяет ./baton, затем обновляет скиллы, шаблоны и ссылку на схему в baton.yml. Остальные настройки сохраняются. Ваши собственные скиллы в .ai/skills/ не затрагиваются. Если вы меняли скиллы Baton вручную, update сообщит о конфликте и перезапишет их только с --force.

После обновления закоммитьте изменения в .ai/skills/, шаблонах и baton.yml: коллеги после git pull и установки получат ту же версию.

Синхронизировать скиллы с установленным бинарником без скачивания: ./baton skills sync (--check — только проверить, --force — перезаписать изменённые).

↑ к началу

12. Справочник команд

Скиллы (в чате агента)

Команды (в терминале)

Справка по любой команде: ./baton --help, ./baton <команда> --help.

↑ к началу

13. Частые проблемы

Непонятная ошибка окружения

Запустите ./baton doctor: он покажет, чего не хватает, и подскажет, как это исправить.

«для runner claude нужен sandbox Claude Code, не найдены: bwrap, socat»

Установите пакеты bubblewrap и socat (Linux). Например, sudo apt install bubblewrap socat.

«план не готов к реализации» или «план не опубликован в Issue»

Сначала завершите $plan: план должен быть одобрен critic (или запущен с --no-critic) и опубликован в задаче.

«перед запуском worker репозиторий должен быть чистым»

В репозитории реализации есть незакоммиченные изменения. Закоммитьте, спрячьте (git stash) или удалите их и попросите координатора перезапустить исполнителей.

«worker не создал commit»

Исполнитель завершился, ничего не закоммитив. Откройте лог из сообщения: обычно в конце видно, что ему помешало. Уточните план или перезапустите исполнителя.

«достигнут лимит независимых проверок»

Critic или checker исчерпал max_iterations. Прочитайте critique.md или review.md и решите сами: поправить план или код, отклонить реализацию (./baton reject) или увеличить лимит в baton.yml и продолжить.

«агент превысил timeout»

Агент не уложился в лимит времени. Посмотрите в лог, не завис ли он. Если задача просто большая, увеличьте лимит (см. Лимиты) и повторите шаг.

Агент «завис»

Посмотрите ./baton status 42: если «Активность» давно не меняется, остановите работу координатора или нажмите Ctrl+C в терминале с ./baton — агенты будут остановлены.

Скиллы не видны в агенте

Проверьте, что агент запущен в корне оркестратора и ссылки .claude/skills, .codex/skills существуют (./baton doctor). Восстановить их можно командой ./baton skills sync.

Скиллы другой версии, чем бинарник

Выполните ./baton skills sync или переустановите версию проекта: curl -fsSL https://baton.example.com/install.sh | bash.

Нужно начать реализацию заново

./baton reject 42, затем $implement 42. План сохранится.

↑ к началу