Документация

Настройка с помощью вашего ассистента AI

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

Эта страница — руководство по эксплуатации, предназначенное для помощника AI: Claude Code, Codex, Cursor или любого другого помощника, способного читать веб-страницы и, в идеале, работать с локальной копией вашего репозитория. Оно проведёт помощника через процесс настройки Coroid для одного или нескольких репозиториев. На каждом этапе, требующем участия человека — вход в систему, предоставление доступа, ввод секретного ключа или утверждение изменений — процесс приостанавливается до вашего вмешательства.

Передайте его своему помощнику

Откройте своего помощника в репозитории, над которым должен работать Coroid, и дайте ему следующее указание:

Set up Coroid for this repository. Follow the runbook at
https://coroid.ai/docs/export/en-US/getting-started/assistant-setup.md
step by step. Ask me before you change anything, and never ask me to paste a
password or token into this chat.

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

Основные правила для помощника

Вы определяете задачи; помощник готовит решения. Вы настраиваете Coroid — облачную платформу AI для автоматизированной разработки ПО, которая превращает описание задачи в протестированный и проверенный pull request в репозитории пользователя. Следуйте этим правилам на протяжении всего процесса:

  1. Пользователь действует; помощник подготавливает. Вы не можете регистрироваться, входить в систему, принимать условия использования, устанавливать приложения или предоставлять доступ от имени пользователя. Указывайте точно, что и где нужно сделать, а затем ждите подтверждения от пользователя.
  2. Не включайте секретные данные в диалог. Никогда не запрашивайте пароль, персональный токен доступа, ключ провайдера или токен MCP. Пользователь вводит такие данные в портал Coroid или в свою оболочку. Если кто-то всё же скопирует их в чат, попросите пользователя отозвать этот токен и создать новый.
  3. Запрашивайте разрешение перед каждым изменением: коммиты, ветки и запросы на объединение в репозитории пользователя, проекты Coroid и приглашения.
  4. Проверяйте каждый шаг перед переходом к следующему. Если проверка завершается ошибкой, используйте примечания, указанные на этом этапе, и продолжайте только после её успешного прохождения или если пользователь решит пропустить этот шаг.
  5. Следуйте продукту, а не собственным предположениям. Если в портале отображается что-то, не описанное в этом руководстве, сообщите пользователю, что вы видите, и действуйте в соответствии с интерфейсом портала. Не придумывайте параметры настройки.
  6. Ведите запись процесса настройки фиксируйте каждый шаг и его результат для последующего анализа.

Каждый шаг содержит ссылки на соответствующие страницы с подробностями. https://coroid.ai/llms.txt индексирует всю документацию.

Шаг 1: Согласуйте план

Задайте пользователю эти вопросы одновременно, а не по отдельности:

ВопросПочему это важно
Над какими репозиториями должен работать Coroid?Один проект на один репозиторий.
GitHub или GitLab? Принадлежит ли он частному лицу или организации?От этого зависит способ подключения Coroid и кто будет утверждать изменения.
Должен ли Coroid создавать запросы на объединение (Синхронизировано), или пока оставлять работу внутри Coroid (Только локально)?Режим «только локально» никогда не записывает данные в репозиторий.
Существует ли уже организация Coroid, и на каком тарифе она находится?В бесплатном тарифе поддерживается один проект без других участников.
Кто ещё будет проверять выполненную работу и в какой роли?Для приглашения участников требуется тариф Professional.
Следует ли Coroid использовать ключи провайдера моделей самой организации?Это необязательно. Для моделей с маршрутизацией через Coroid ключи не нужны.

Затем повторите план: указанные ниже шаги, требующие участия пользователя, и охватываемые репозитории.

См. Планы и цены, Ограничения и квоты и Синхронизировано или только локально.

Шаг 2: Проверьте, что каждый репозиторий собирается и тестируется из чистого клона

Это самая полезная операция, которую можно выполнить. Каждая задача Coroid выполняется в чистой, разовой рабочей среде Linux: свежий клон, ничего не закэшировано, ничего не установлено, кроме инструментария образа. Агент, не способный собрать и протестировать проект, не может подтвердить корректность своей работы, а его задачи завершаются с ошибкой проверки по причинам, не связанным с самим изменением.

Если вы можете работать с репозиторием локально, выполните следующее для каждого из них:

  1. Определите используемые языки, менеджер пакетов и является ли проект монорепозиторием.
  2. Найдите команды установки, сборки и тестирования в README, конфигурации CI и манифестах.
  3. Спросите разрешения перед выполнением любых команд. Затем склонируйте репозиторий в пустую временную директорию и запустите там установку, сборку и тестирование без каких-либо дополнительных настроек. В рабочей копии пользователя имеются кэши и .env файлы, которые скрывают проблемы.
  4. Запишите всё, что потребовалось для выполнения, но чего нет в свежем клоне:
    • сервисы, необходимые для работы тестов, такие как база данных, кэш или очередь
    • этапы перед запуском тестов, например генерация кода, миграции или фикстуры
    • переменные окружения или .env файл, который не попал в коммит
    • приватные реестры пакетов
    • среда выполнения, отсутствующая в среде агента

Никогда не выполняйте команды, предназначенные для деплоя, публикации или изменения общих сред. Если набор тестов работает медленно или использует платные сервисы, сначала спросите у пользователя.

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

НедостатокПредлагаемое решение
Для тестов необходима база данных или другой сервис.Dockerfile или файл Compose, позволяющий запустить тестовый набор со всеми необходимыми сервисами.
Необходимый .env Файл не был зафиксирован в версии.Значения по умолчанию для тестов указаны в коде, либо существует зафиксированная конфигурация тестов с несекретными параметрами.
Для тестов требуется настоящий секретный параметр.Имитируйте эту зависимость в тестах. Никогда не фиксируйте секретные параметры в версии.
Зависимости загружаются из приватного реестра.Сообщите пользователю: Coroid требует учетные данные для работы с этим реестром в качестве параметров конфигурации Проекта.
Команды работают только из поддиректории.Укажите точную директорию и любые фильтры рабочей области.

Отсутствие нужной среды выполнения не является препятствием: контейнер с нужным стеком инструментов решает эту проблему. Если у вас нет доступа к репозиторию локально, соберите от пользователя всю доступную информацию и отметьте, что проверка чистого клонирования не была выполнена.

Смотрите Настройки сборки и тестирования и Поддержка языков и среда агентов.

Шаг 3: Напишите инструкции, которые будут считывать агенты Coroid.

Перед выполнением каждой задачи агенты Coroid считывают файлы памяти из репозитория: AGENTS.md, CLAUDE.md или GEMINI.md в корне репозитория и .cursor/rules. Команды, которые вы проверили на Шаге 2, должны быть размещены там.

Предложите AGENTS.md, либо дополнение к уже существующему файлу, с следующим содержанием:

  • Команды установки, сборки и тестирования, проверенные на чистом клонировании, а также директория для их запуска.
  • Шаги и сервисы, необходимые для выполнения тестов.
  • Как запустить минимально необходимый набор тестов — например, один пакет или один файл.
  • Правила и ограничения, не видимые в коде: замороженные модули, участки кода, которые нельзя изменять, зависимости, которые нельзя добавлять.

Не включайте в файл то, что уже указано в коде, и делайте его кратким. Если CLAUDE.md или .cursor/rules содержат одинаковые инструкции, оставьте их в одном месте в AGENTS.md и подключите его из другого файла с помощью строки @AGENTS.md .

Покажите пользователю различия в коде. После его одобрения зафиксируйте изменения в новой ветке и откройте pull request, либо оставьте возможность для самостоятельного коммита. Изменения должны попасть в базовую ветку до начала выполнения первой задачи, так как каждая задача считывает файлы памяти из своего экземпляра этой ветки. Исправления, принятые пользователем на Шаге 2, обработайте аналогичным образом.

Смотрите Настройки контекста Проекта и Контекст Проекта.

Шаг 4: Аккаунт и организация (пользователь)

Пропустите этот шаг, если пользователь уже является Владельцем или Администратором в организации Coroid.

Попросите пользователя:

  1. зарегистрироваться на https://client.coroid.ai/auth/signup используя рабочую электронную почту и подтвердить адрес
  2. принять условия использования
  3. создать организацию

Проверьте: пользователь может открыть https://client.coroid.ai/projects. Человек, который завершает эту настройку, должен иметь роль Владельца или Администратора, так как только эти роли позволяют подключать систему контроля версий и добавлять ключи провайдера.

См. Создание аккаунта и организации.

Шаг 5: Подключение системы контроля версий (пользователь)

Заранее обсудите с пользователем требования к доступу перед началом работы. Обычно именно необходимость получения чужого одобрения для завершения установки приводит к тому, что этот шаг занимает целый день вместо минуты.

GitHub

Пользователь открывает Настройки → Подключения → Управление исходным кодом (https://client.coroid.ai/settings/connections/source-control).

ВариантИспользуйте его, когдаЧто нужно пользователю в GitHub
GitHub App (рекомендуется)Почти всегдаРазрешение на установку приложений в аккаунте или организации, которой принадлежат репозитории. В организации такое разрешение обычно имеет Владелец; другие участники могут запросить установку, а Владелец даст на неё одобрение.
Личный токен доступаПриложению требуется одобрение, которого у пользователя нетСтандартный токен с областью действия repo , или точечный токен с правами чтения и записи для Содержимое и Запросы на объединение для выбранных репозиториев
Подключение по URL, без подключенияПубличный репозиторий, проверенный в Только локальноНичего

GitHub App: на экране установки GitHub пользователь выбирает Выберите только нужные репозитории и выбирает те варианты, которые были согласованы на Шаге 1. Приложение продолжает работать даже после ухода пользователя, установившего его, получает вебхук-события и благодаря этому позволяет Coroid публиковать свои проверки в запросах на объединение. Токен не может публиковать проверки GitHub.

Персональный доступный токен: пользователь создает его в GitHub с указанием срока действия и вставляет его в портал Coroid. Рекомендуется использовать токен с точечными разрешениями, ограниченный нужными репозиториями. Запросы на объединение приписываются владельцу токена, а соединение разрывается, если у этого пользователя отзывают доступ.

GitLab

GitLab находится в закрытом режиме предварительного доступа и отображается только на аккаунтах, где он включен. Он подключается с помощью персонального доступного токена со api областью действия. Если GitLab не отображается в разделе «Управление исходным кодом», порекомендуйте пользователю обратиться в службу поддержки Coroid и не стройте планы с учетом его функциональности.

Защита ветки

Coroid создает обычные запросы на объединение, поэтому правила защиты веток, обязательные проверки и правила рецензирования по-прежнему применяются. Рекомендуем оставить защиту включенной. Если правила требуют подписанных коммитов или статусной проверки, которую Coroid не может выполнить, его запросы на объединение будут открыты и останутся неслитыми. Сообщите об этом пользователю и не меняйте их правила.

Проверка: поставщик отображается как подключенный в разделе «Управление исходным кодом». Настоящее подтверждение появляется на Шаге 6, когда репозитории отображаются в списке проектов.

Смотрите Подключите свой код, GitHub, GitLab и Настройки репозитория и ветки.

Шаг 6: Создание проектов (пользователь)

Создайте один проект на один репозиторий, никогда не создавайте два проекта для одного репозитория. Пользователь открывает Проекты → Новый (https://client.coroid.ai/projects/new) и для каждого репозитория:

  1. выбирает его из подключенного поставщика или использует Подключиться по URL для публичного репозитория
  2. выбирает Режим репозитория: «Синхронизировано», при котором Coroid создает ветки и открывает запросы на объединение, или «Только локально», при котором Coroid никогда не записывает данные в репозиторий, пока кто-то не выберет Начать синхронизацию
  3. проверяет основную ветку
  4. создает проект

Если команда объединяет изменения не в основную ветку, например develop, установите базовую ветку в настройках репозитория проекта. Неправильная базовая ветка приведет к тому, что запросы на объединение будут отправлены в ветку, которую никто не будет рецензировать.

Если репозиторий отсутствует в списке, причина почти всегда одна из следующих:

  • приложению GitHub не предоставили доступ к этому репозиторию
  • область действия токена слишком ограничена, чтобы его отобразить
  • репозиторий принадлежит другой организации, отличной от подключенной

Смотрите Создать первый проект и Настройки репозитория и ветки.

Шаг 7: Проверить результаты работы Coroid

Попросите пользователя открыть обзор каждого проекта и зачитать Репозиторий сведения и всё, что указано в разделе Завершить настройку:

  • Статус и Ветка: репозиторий клонируется в указанную базовую ветку. Если в обзоре указано, что репозиторий ещё не был склонирован, пользователь выбирает Клонировать репозиторий.
  • Стек: языки, фреймворки, менеджеры пакетов и инструменты тестирования, которые определил Coroid. Сравните их с результатами проверки готовности. Если после первой синхронизации стек пустой или неверный, пользователь может повторно его просканировать.
  • Завершить настройку: такие элементы, как «Зависимости не установились корректно», указывают на те же пробелы, что и на Шаге 2. Разберитесь с ними вместе с пользователем.

Затем пользователь открывает в проекте Настройки → Знания → Контекст. Файл памяти с Шага 3 должен быть перечислен в разделе Источники репозитория и быть включённым. Если там отображается Создать вместо этого, значит файл ещё не попал в подключённую ветку.

Смотрите Настройки контекста проекта и Настройка сборки и тестирования.

Шаг 8: Настройки организации (необязательно)

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

  • Участники, в разделе Настройки → Участники: люди, которые будут рецензировать pull-запросы, в роли Владельца, Администратора, Участника или Рецензента. Рекомендуется назначать роль Администратора только тем, кто должен изменять политики и ключи провайдера. Требуется тариф Professional.
  • Ключи провайдера, в разделе Настройки → Ключи провайдера: только для использования учётных записей провайдера моделей самой организации. Пользователь вводит ключ в портале. Рекомендуется использовать ограниченный ключ с лимитом расходов у провайдера.
  • Настройки из другой организации: экспортируйте там пакет настроек и импортируйте его в разделе Настройки → Данные → Экспортировать настройки. Конфиденциальные данные передаются в виде заполнителей, поэтому каждый needsRebind элемент в предпросмотре требует внимания.

Смотрите Создайте свой аккаунт и организацию, Ключи провайдера и Экспорт и импорт настроек.

Шаг 9: Подключитесь к Coroid (необязательно)

Если ваш клиент поддерживает удалённые серверы MCP, вы можете получить доступ к Coroid через его сервер MCP по адресу https://api.coroid.ai/mcp. Настройка не зависит от этого, но это позволяет вам самостоятельно проверять проекты и помогать пользователю запускать задачи позже.

  1. Пользователь открывает Настройки → Подключения → Coroid MCP сервер (https://client.coroid.ai/settings/connections/coroid-mcp). Если он недоступен для их организации, пропустите этот шаг.
  2. Настройка клиента показывает команды для каждого клиента. При использовании OAuth пользователь утверждает ваш доступ в своём браузере. При использовании персонального токена доступа пользователь создаёт его в разделе Токены доступа и сохраняет его в переменной среды в своей оболочке. Вам никогда не потребуется видеть его значение.
  3. Рекомендуем использовать минимально необходимые права доступа: mcp.read для проверки настройки, а также mcp.work.write только если вы собираетесь создавать задачи. Ограничьте токен этими проектами, укажите срок его действия и установите Политики автоматизации перед тем, как любой клиент будет запускать задачи автоматически.

Проверьте: вызовите list_projects, затем get_project для каждого проекта из Шага 6, и подтвердите репозиторий и ветку.

Используйте только api.coroid.ai для работы с MCP. Имя хоста клиентского портала для этого не подходит.

Смотрите Coroid в качестве сервера MCP.

Шаг 10: Составьте первую задачу

Завершите процесс составлением небольшой первой задачи вместе с пользователем в одном из новых проектов. Хорошая первая задача — реальная, небольшая, соответствующая существующим тестам и имеющая чёткую цель. Избегайте задач, связанных с аутентификацией, платежами, миграцией данных, бесконечными уборками или чем-то, требующим принятия решения по дизайну, которое ещё не было принято.

Опишите результат, а не способ реализации: что должно быть верным после завершения работы, какие файлы имеют значение и что не следует трогать. Пользователь отправляет её из Новая работа (https://client.coroid.ai/work/new), прочитает спецификацию и утвердит план. Запуск задач требует времени агентов, а в бесплатном тарифе выделено 2 часа в сутки по UTC, поэтому позвольте пользователю самому решить, когда запускать задачу.

Смотрите Запустите свою первую задачу и Спецификации.

Шаг 11: Передайте всё пользователю

Предоставьте пользователю информацию о настройке:

  • каждый репозиторий, его проект, режим репозитория и базовая ветка
  • как установлена связь с системой контроля версий, и кто отвечает за эту связь: установщик приложения или владелец токена с указанием срока его действия
  • по каждому репозиторию: исправленные проблемы, оставшиеся нерешёнными (например, открытый пулл-реквест с AGENTS.md), и те, которые пользователь решил оставить без изменений
  • выполненные и пропущенные дополнительные настройки, а также составленная первая задача

Затем направьте пользователя на Рецензирование и объединение результата чтобы увидеть, что приходит с первым pull request.

Далее

Создайте свой аккаунт и организацию — такая же настройка, выполненная вручную.