Эта страница представляет собой руководство, предназначенное для помощника 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 в репозитории пользователя. Следуйте этим правилам на протяжении всего процесса:
- Пользователь действует; вы готовите. Вы не можете регистрироваться, входить в систему, принимать условия использования, устанавливать приложения или предоставлять доступ от имени пользователя. Указывайте точно, что и где нужно сделать, а затем ждите подтверждения от пользователя о завершении операции.
- Не упоминайте секреты в диалоге. Никогда не запрашивайте пароль, персональный токен доступа, ключ провайдера или токен MCP. Пользователь вводит такие данные в портал Coroid или в свою командную строку. Если секретный ключ всё же был вставлен в чат, попросите пользователя отозвать его и создать новый.
- Запрашивайте разрешение перед каждым изменением: коммиты, ветки и запросы на объединение в репозитории пользователя, проекты Coroid и приглашения.
- Проверяйте каждый шаг перед переходом к следующему. Если проверка завершается неудачно, используйте примечания из соответствующего шага и продолжайте только после её успешного прохождения или если пользователь решит пропустить этот этап.
- Следуйте продукту, а не собственным предположениям. Если в портале отображается что-то, не описанное в этом руководстве, сообщите пользователю, что вы видите, и следуйте инструкциям портала. Не придумывайте дополнительные настройки.
- Ведите запись процесса настройки — фиксируйте каждый шаг и его результат для последующего анализа.
Каждая шаговая инструкция связывает страницы с подробными сведениями.
https://coroid.ai/llms.txt Производится индексация всей документации.
Шаг 1: Согласуйте план
Задайте пользователю все эти вопросы сразу, а не по отдельности:
| Вопрос | Почему это важно |
|---|---|
| Над какими репозиториями должен работать Coroid? | Один проект на один репозиторий. |
| GitHub или GitLab? Принадлежит ли он человеку или организации? | Это определяет способ подключения Coroid и того, кто даст разрешение. |
| Должен ли Coroid создавать запросы на объединение (Синхронизировано), или сначала оставлять результаты работы внутри Coroid (Только локально)? | Режим «Только локально» никогда не записывает данные в репозиторий. |
| Существует ли уже организация Coroid, и на каком тарифе она находится? | Бесплатный тариф поддерживает один проект без других участников. |
| Кто еще будет рецензировать работу и в какой роли? | Для приглашения участников требуется тариф Professional. |
| Должен ли Coroid использовать собственные ключи провайдера моделей организации? | Это необязательно. Для моделей, маршрутизируемых через Coroid, ключи не нужны. |
Затем повторите план: приведённые ниже шаги, требующие участия пользователя, и охватываемые репозитории.
См. Планы и цены, Ограничения и квоты и Синхронизировано или только локально.
Шаг 2: Проверьте, что каждый репозиторий успешно собирается и тестируется из чистой копии.
Это самая полезная задача, которую можно выполнить. Каждая задача Coroid выполняется в чистой, разовой рабочей среде Linux: свежий клон репозитория, без кэша и без установленных дополнительных компонентов, кроме инструментария из образа. Агент, который не может собрать и протестировать проект, не способен подтвердить корректность своей работы, а его задачи будут завершаться с ошибкой проверки по причинам, не связанным с внесёнными изменениями.
Если вы можете работать с репозиторием локально, выполните следующие действия для каждого из них:
- Определите используемые языки программирования, менеджер пакетов и является ли репозиторий монорепозиторием.
- Найдите команды установки, сборки и тестирования в файле README, конфигурации CI и манифестах.
- Перед запуском любых команд уточните у пользователя разрешение. Затем склонируйте репозиторий в пустую временную директорию и выполните там команды установки, сборки и тестирования без каких-либо дополнительных настроек. В рабочей копии пользователя имеются кэши и файлы, которые скрывают возникающие проблемы.
.envфайлы, которые скрывают проблемы. - Запишите всё, что потребовалось для запуска, но отсутствует в свежем клоне:
- Сервисы, необходимые для работы тестов, такие как база данных, кэш или очередь сообщений.
- Шаги, предшествующие запуску тестов, например генерация кода, миграции или создание тестовых данных.
- Переменные окружения или
.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.
Попросите пользователя:
- зарегистрироваться на
https://client.coroid.ai/auth/signupиспользуя рабочую электронную почту и подтвердить адрес - принять условия использования
- создать организацию
Проверьте: пользователь может открыть https://client.coroid.ai/projects. Человек, завершающий эту настройку, должен иметь роль Владельца или Администратора, так как только эти роли позволяют подключать управление исходным кодом и добавлять ключи провайдера.
Смотрите Создайте свой аккаунт и организацию.
Шаг 5: Подключение управления исходным кодом (пользователь)
Перед началом работы обсудите с пользователем требования к доступу. Обычно именно прерывание установки для получения чужого одобрения приводит к тому, что этот шаг занимает целый день вместо минуты.
GitHub
Пользователь открывает Настройки → Подключения → Управление исходным кодом
(https://client.coroid.ai/settings/connections/source-control).
| Вариант | Используйте его, когда | Что нужно пользователю в GitHub |
|---|---|---|
| GitHub App (рекомендуется) | Почти всегда | Разрешение на установку приложений в аккаунте или организации, владеющей репозиториями. В организации обычно это роль владельца; другие участники могут запросить установку для последующего одобрения владельцем. |
| Персональный токен доступа | Приложению требуется одобрение, которое не может получить пользователь | Стандартный токен с repo областью действия или точечный токен с правами чтения и записи для Содержимое и Pull-запросы для выбранных репозиториев |
| Подключение по URL, без подключения | Публичный репозиторий, протестированный в Только локально | Ничего |
GitHub App: на экране установки GitHub, пользователь выбирает Выберите только нужные репозитории и отметьте те, которые были согласованы на шаге 1. Приложение продолжит работу даже после ухода человека, установившего его; оно будет получать события вебхуков и позволять Coroid публиковать проверки в pull-запросах. Токен не способен публиковать проверки GitHub.
Персональный токен доступа: пользователь создает его на GitHub с указанием срока действия и вставляет в портал Coroid. Рекомендуется использовать точечный токен, ограниченный согласованными репозиториями. Pull-запросы будут приписаны владельцу токена, а подключение прекратится, если этот человек потеряет доступ.
GitLab
GitLab находится в закрытом режиме предварительного просмотра и отображается только на аккаунтах, где он включен.
Для подключения требуется персональный токен доступа с api областью действия. Если GitLab не появляется в разделе «Управление исходным кодом», порекомендуйте пользователю обратиться в службу поддержки Coroid и не стройте планов с учетом его использования.
Защита ветки
Coroid создает обычные запросы на объединение, поэтому правила защиты веток, обязательные проверки и правила рецензирования по-прежнему применяются. Рекомендуется оставить защиту включенной. Если правила требуют подписанных коммитов или проверки статуса, которые Coroid не может выполнить, его запросы на объединение будут открыты и останутся не объединёнными. Сообщите об этом пользователю и не меняйте эти правила.
Проверьте: что провайдер отображается как подключенный в разделе Управление исходным кодом. Действительное подтверждение появляется на шаге 6, когда репозитории отображаются в списке проектов.
Смотрите Подключите свой код, GitHub, GitLab и Настройки репозитория и ветки.
Шаг 6: Создать проекты (пользователь)
Создайте один проект на один репозиторий, никогда не создавайте два проекта для одного репозитория. Пользователь открывает Проекты → Создать (https://client.coroid.ai/projects/new) и для
каждого репозитория:
- выбирает его из подключенного провайдера или использует Подключиться по URL для публичного репозитория
- выбирает Режим репозитория: «Синхронизированный», при котором Coroid отправляет ветки и открывает запросы на объединение, или «Только локальный», при котором Coroid никогда не записывает данные в репозиторий, пока пользователь не выберет Начать синхронизацию
- проверяет основную ветку
- создает проект
Если команда объединяет изменения в другую ветку, отличную от основной, например
develop, установите базовую ветку в настройках репозитория проекта. Неправильная
базовая ветка приведет к тому, что запросы на объединение будут отправлены в ветку, которую никто не будет рецензировать.
Если репозиторий отсутствует в списке, причина почти всегда заключается в следующем:
- приложению GitHub не предоставили доступ к этому репозиторию
- область действия токена слишком узкая, чтобы перечислить его
- репозиторий принадлежит другой организации, отличной от подключенной
Смотрите Создать свой первый проект и Настройки репозитория и ветки.
Шаг 7: Проверьте, что нашел Coroid
Попросите пользователя открыть обзор каждого проекта и зачитать Репозиторий сведения и всё, что указано в разделе Завершить настройку:
- Статус и Ветка: репозиторий склонирован, находится на согласованной базовой ветке. Если в обзоре указано, что репозиторий еще не склонирован, пользователь выбирает Склонировать репозиторий.
- Стек: языки, фреймворки, менеджеры пакетов и инструменты тестирования, которые определил Coroid. Сравните их с результатами проверки готовности. Если стек пустой или неверный после первой синхронизации, пользователь может повторно его просканировать оттуда.
- Завершить настройку: пункты вроде «Зависимости не установились корректно» указывают на те же проблемы, что и на шаге 2. Разберитесь с ними вместе с пользователем.
Затем пользователь открывает в проекте Настройки → Знания → Контекст. Файл памяти с шага 3 должен быть указан в разделе Источники репозитория и быть включенным. Если там отображается Создать — значит файл еще не попал в подключенную ветку.
Смотрите Настройки контекста проекта и Настройка сборки и тестирования.
Шаг 8: Настройки организации (необязательно)
Спросите пользователя, нужны ли ему эти параметры сейчас. Для всех них предусмотрены рабочие значения по умолчанию:
- Участники, в разделе Настройки → Участники: люди, которые будут рецензировать pull-запросы в качестве Владельца, Администратора, Участника или Рецензента. Рекомендуется назначать роль Администратора только тем, кто должен изменять политики и Ключи провайдера. Требуется тариф Professional.
- Ключи провайдера, в разделе Настройки → Ключи провайдера: используются исключительно для учетных записей собственных провайдеров моделей организации. Пользователь вводит ключ в портале. Рекомендуется использовать ограниченный ключ с лимитом расходов у провайдера.
- Настройки из другой организации: экспортируйте пакет настроек туда и импортируйте его в разделе Настройки → Данные → Экспорт настроек. Секреты передаются в виде плейсхолдеров, поэтому каждый
needsRebindэлемент в предварительном просмотре требует внимания.
См. Создание аккаунта и организации, Ключи провайдера и Экспорт и импорт настроек.
Шаг 9: Подключение к Coroid (необязательно)
Если ваш клиент поддерживает удаленные MCP-серверы, вы можете получить доступ к Coroid через его MCP-сервер по адресу https://api.coroid.ai/mcp. Настройка не зависит от этого, но это позволяет самостоятельно проверять проекты и помогать пользователю выполнять задачи позже.
- Пользователь открывает Настройки → Автоматизация → Coroid MCP сервер
(
https://client.coroid.ai/settings/automation/coroid-mcp). Если этот сервер недоступен для их организации, пропустите этот шаг. - Настройка клиента Здесь отображаются команды для каждого клиента. При использовании OAuth пользователь утверждает ваш доступ в своем браузере. При использовании личного токена доступа пользователь создает его в разделе Токены доступа и сохраняет его в переменной среды в своей оболочке. Вам никогда не придется видеть его значение.
- Рекомендуем использовать минимально необходимый уровень доступа:
mcp.readдля проверки настройки, а такжеmcp.work.writeтолько если вы собираетесь создавать задачи. Ограничьте токен этими проектами, задайте ему срок действия и настройте Политики автоматизации перед тем, как любой клиент начнет работу без участия человека.
Проверьте: выполните вызов list_projects, затем get_project для каждого проекта из шага 6,
и подтвердите репозиторий и ветку.
Используйте только api.coroid.ai для работы с MCP. Хост-имя клиентского портала не поддерживает эту функцию.
Смотрите Coroid в качестве Coroid MCP сервера.
Шаг 10: Составьте первую задачу
Завершите процесс составлением небольшой первой задачи совместно с пользователем в одном из новых проектов. Хорошая первая задача — это реальная, небольшая задача, близкая к существующим тестам, с четко определенным результатом. Избегайте задач, связанных с аутентификацией, платежами, миграцией данных, бесконечными работами по очистке кода и любых задач, требующих принятия решений по дизайну, которые еще не были приняты.
Опишите итоговый результат, а не способ реализации: что должно быть достигнуто после завершения работы,
какие файлы имеют значение и что не следует трогать. Пользователь отправляет её из Новая работа (https://client.coroid.ai/work/new), система считывает
спецификации и утверждает план. Выполнение задач расходует часы работы агентов, а в тарифе Free предусмотрено 2 часа в сутки по UTC, поэтому позвольте пользователю самому решить, когда запускать задачу.
Смотрите Запустите свою первую задачу и Спецификации.
Шаг 11: Передайте управление
Предоставьте пользователю запись о настройке:
- Каждый репозиторий, его проект, режим репозитория и базовая ветка
- Способ подключения к системе управления исходным кодом, а также владелец этого подключения: установщик приложения, владелец токена и дата его истечения
- Для каждого репозитория — исправленные ошибки, ошибки, которые еще предстоит устранить (например, открытый запрос на объединение
AGENTS.md), а также ошибки, которые пользователь решил оставить без изменений - Необязательные параметры, которые были применены или пропущены, а также черновик первой задачи
Затем направьте пользователя на Проверьте и объедините полученный результат — чтобы понять, что содержится в первом pull request.
Далее
Создайте свой аккаунт и организацию — такая же настройка, выполненная вручную.