Configurer l'assistant AI

Cette page est un guide d'utilisation rédigé pour un assistant AI : Claude Code, Codex, Cursor, ou tout autre assistant capable de lire une page web et, idéalement, de travailler sur une copie locale de votre dépôt. Il guide l'assistant dans la configuration de Coroid pour un ou plusieurs dépôts. Il s'arrête à chaque étape qui nécessite une intervention humaine : connexion, attribution d'accès, saisie d'un secret ou approbation d'une modification.

Confiez-le à votre assistant#

Ouvrez votre assistant dans le dépôt sur lequel vous souhaitez que Coroid travaille, puis donnez-lui cette instruction :

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.

Pour plusieurs dépôts, ouvrez l'assistant dans un répertoire les contenant tous, et mentionnez-les dans l'instruction. L'assistant effectue l'inspection et la vérification, et vous indique précisément ce qu'il faut faire à chaque étape nécessitant votre intervention.

Règles de base pour l'assistant#

Vous définissez la configuration de Coroid, une usine logicielle hébergée AI qui transforme une description de tâche en une demande d'intégration testée et validée pull request dans le dépôt de l'utilisateur. Respectez ces règles tout au long du processus :

1. L'utilisateur agit ; vous préparez. Vous ne pouvez pas vous inscrire, vous connecter, accepter les conditions générales, installer des applications ou attribuer des accès pour le compte de l'utilisateur. Indiquez précisément ce qu'il faut faire et où, puis attendez que l'utilisateur confirme l'achèvement de l'opération.
2. Gardez les secrets hors de la conversation. Jamais vous ne devriez demander un mot de passe, un jeton d'accès personnel, une clé de fournisseur ou un jeton MCP. L'utilisateur saisit ces secrets dans le portail Coroid ou via son propre terminal. Si l'un d'eux est quand même collé dans la discussion, demandez à l'utilisateur de le révoquer et d'en créer un nouveau.
3. Demandez l'autorisation avant chaque modification: commits, branches et demandes d'intégration dans le dépôt de l'utilisateur, projets Coroid et invitations.
4. Vérifiez chaque étape avant de passer à la suivante. Si une vérification échoue, utilisez les notes de cette étape et continuez uniquement après validation ou si l'utilisateur décide de la contourner.
5. Suivez le produit, pas vos suppositions. Si le portail affiche quelque chose que ce guide d'utilisation ne décrit pas, indiquez à l'utilisateur ce que vous voyez et suivez les indications du portail. Ne créez pas de paramètres fictifs.
6. Conservez un enregistrement de la configuration de chaque étape et de son résultat, pour la fin.

Chaque étape renvoie vers les pages détaillées. https://coroid.ai/llms.txt Il indexe l'ensemble de la documentation.

Étape 1 : Valider le plan#

Posez ces questions à l'utilisateur en même temps, et non une par une :

Ensuite, répétez le plan : les étapes ci-dessous qui requièrent l'intervention de l'utilisateur et les dépôts concernés.

Voir Plans et tarifs, Limites et quotas et Synchronisé ou en local uniquement.

Étape 2 : Vérifier que chaque dépôt se compile et passe les tests à partir d'une copie propre.#

C'est la tâche la plus utile à accomplir. Chaque tâche Coroid s'exécute dans un espace de travail Linux propre et éphémère : une nouvelle copie, rien en cache, rien d'installé en dehors de la chaîne d'outils de l'image. Un agent incapable de compiler et de tester le projet ne peut pas valider son propre travail, et ses tâches échouent lors de la vérification pour des raisons sans rapport avec le changement.

Si vous pouvez travailler sur le dépôt en local, faites ceci pour chacun d'eux :

1. Identifiez les langages, le gestionnaire de paquets et si c'est un monorepo.
2. Trouvez les commandes d'installation, de compilation et de test dans le README, la configuration CI et les manifestes.
3. Demandez avant d'exécuter quoi que ce soit. Ensuite, clonez le dépôt dans un répertoire temporaire vide et exécutez y l'installation, la compilation et les tests sans aucune autre configuration. La copie de travail de l'utilisateur contient des caches et .env des fichiers qui masquent les problèmes.
4. Notez tout ce dont l'exécution avait besoin mais que la nouvelle copie ne possède pas :
   • les services attendus par les tests, comme une base de données, un cache ou une file d'attente
   • les étapes précédant les tests, comme la génération de code, les migrations ou les jeux de données
   • les variables d'environnement ou un .env fichier qui n'est pas validé
   • des registres de paquets privés
   • un environnement d'exécution qui n'est pas présent dans le environnement de l'agent

Jamais exécutez de commandes qui déploient, publient ou touchent aux environnements partagés. Si la suite est lente ou utilise des services payants, demandez d'abord à l'utilisateur.

Générez un bref rapport de vérification de la préparation par dépôt : les commandes utilisées, la durée d'exécution du suite de tests, ce qui a réussi et chaque écart avec une correction proposée.

L'absence d'un environnement d'exécution n'est pas un obstacle : un conteneur intégrant l'ensemble de l'outilchain résout ce problème. Si vous ne pouvez pas accéder au dépôt en local, collectez les informations disponibles auprès de l'utilisateur et notez que la vérification du clonage propre n'a pas eu lieu.

Consultez Configuration de build et de test et Prise en charge des langages et environnement des agents.

Étape 3 : Rédigez les instructions que les agents de Coroid vont lire.#

Avant chaque tâche, les agents de Coroid lisent les fichiers de mémoire présents dans le dépôt : AGENTS.md, CLAUDE.md ou GEMINI.md à la racine, et .cursor/rules. Les commandes que vous avez vérifiées lors de l'étape 2 doivent y être inscrites.

Proposez un AGENTS.md, ou une ajout à celui existant, indiquant :

• les commandes d'installation, de build et de test, vérifiées à partir d'un clonage propre, ainsi que le répertoire où les exécuter.
• les étapes et services requis pour les tests.
• Comment exécuter l'ensemble le plus restreint et utile de tests, comme un seul paquet ou un seul fichier.
• Les conventions et limites non visibles dans le code : modules figés, zones à ne pas modifier, dépendances à ne pas ajouter.

Omettez ce que le code indique déjà et gardez le fichier concis. Si CLAUDE.md or .cursor/rules contient les mêmes instructions, conservez-les une seule fois dans AGENTS.md et importez-le depuis l'autre fichier via une ligne @AGENTS.md .

Montrez la différence à l'utilisateur. Après son approbation, validez-la sur une nouvelle branche et ouvrez une pull request, ou laissez-le effectuer la validation lui-même. Cette modification doit atteindre la branche de base avant la première tâche, car chaque tâche lit les fichiers de mémoire depuis sa propre copie de cette branche. Traitez les corrections de l'étape 2 acceptées par l'utilisateur de la même manière.

Consultez Paramètres du contexte du projet et Contexte du projet.

Étape 4 : Compte et organisation (l'utilisateur)#

Sauter cette étape si l'utilisateur appartient déjà à une organisation Coroid en tant que Propriétaire ou Administrateur.

Demander à l'utilisateur de :

1. s'inscrire sur https://client.coroid.ai/auth/signup avec son adresse e-mail professionnelle, et vérifier l'adresse.
2. accepter les conditions d'utilisation.
3. créer l'organisation.

Vérifier : que l'utilisateur peut ouvrir https://client.coroid.ai/projects. La personne qui effectue cette configuration doit avoir le rôle de Propriétaire ou d'Administrateur, car seuls ces rôles peuvent connecter le contrôle de code source et ajouter les clés de fournisseur.

Consulter Créer votre compte et organisation.

Étape 5 : Connecter le contrôle de code source (l'utilisateur)#

Passer en revue les exigences d'accès avec l'utilisateur avant qu'il ne commence. Une installation qui s'interrompt à mi-chemin pour attendre l'approbation d'une autre personne est la raison habituelle pour laquelle cette étape prend un jour au lieu d'une minute.

GitHub#

L'utilisateur ouvre Paramètres → Connexions → Contrôle de source (https://client.coroid.ai/settings/connections/source-control).

GitHub App : sur l'écran d'installation de GitHub, l'utilisateur sélectionne Ne sélectionner que les dépôts et sélectionne celles qui ont été convenues lors de l'étape 1. L'application continue de fonctionner même si la personne qui l'a installée quitte l'entreprise ; elle reçoit les événements de webhook et permet à Coroid de publier ses vérifications sur les demandes d'intégration. Un jeton ne peut pas publier les vérifications GitHub.

Jeton d'accès personnel : L'utilisateur le crée sur GitHub avec une date d'expiration, puis le colle dans le portail Coroid. Il est préférable d'utiliser un jeton à portée restreinte limité aux dépôts convenus. Les demandes d'intégration sont attribuées au propriétaire du jeton, et la connexion est interrompue si cette personne perd l'accès.

GitLab#

GitLab est en version d'aperçu privée et n'apparaît que sur les comptes où il est activé. Il se connecte via un jeton d'accès personnel avec la api portée. Si GitLab n'apparaît pas sous Contrôle de source, indiquez à l'utilisateur de contacter Coroid et ne planifiez rien autour de cette fonctionnalité.

Protection des branches#

Coroid ouvre des demandes d'intégration classiques, donc la protection des branches, les vérifications requises et les règles de révision restent applicables. Il est recommandé de maintenir cette protection active. Si les règles exigent des commits signés ou une vérification d'état que Coroid ne peut pas produire, ses demandes d'intégration s'ouvriront mais resteront non fusionnables. Informez l'utilisateur et ne modifiez pas ses règles.

Vérification : Le fournisseur apparaît comme connecté sous Contrôle de source. La preuve concrète intervient à l'étape 6, lorsque les dépôts apparaissent dans la liste des projets.

Voir Connecter votre code, GitHub, GitLab et Paramètres de dépôt et de branche.

Étape 6 : Créer les projets (l'utilisateur)#

Créez un projet par dépôt ; jamais deux pour un même dépôt. L'utilisateur ouvre Projets → Nouveau (https://client.coroid.ai/projects/new) et, pour chaque dépôt :

1. le sélectionne parmi le fournisseur connecté, ou utilise Se connecter via URL pour un dépôt public
2. choisit le Mode de dépôt: Synchronisé, où Coroid pousse les branches et ouvre des demandes d'intégration, ou Local uniquement, où Coroid n'écrit jamais dans le dépôt tant que quelqu'un ne choisit pas Démarrer la synchronisation
3. vérifie la branche par défaut
4. crée le projet

Si l'équipe effectue des fusions dans une branche autre que la branche par défaut, comme develop, définissez la branche de base dans les paramètres de dépôt du projet. Une mauvaise branche de base envoie les demandes d'intégration vers une branche que personne ne révise.

Si un dépôt manque dans la liste, la cause est presque toujours l'une des suivantes :

• l'application GitHub n'a pas reçu l'autorisation d'accéder à ce dépôt
• la portée du jeton est trop restreinte pour le lister
• le dépôt appartient à une organisation différente de celle qui est connectée

Voir Créer votre premier projet et Paramètres du dépôt et de la branche.

Étape 7 : Vérifier ce que Coroid a trouvé#

Demandez à l'utilisateur d'ouvrir la vue d'ensemble de chaque projet et de lire les Dépôt détails et tout ce qui est listé sous Terminer la configuration:

• État et Branche: le dépôt est cloné sur la branche de base que vous avez convenue. Si la vue d'ensemble indique que le dépôt n'a pas encore été cloné, l'utilisateur choisit Cloner le dépôt.
• Stack: les langages, frameworks, gestionnaires de paquets et outils de test que Coroid a détectés. Comparez-les avec votre vérification de préparation. Si la stack est vide ou incorrecte après la première synchronisation, l'utilisateur peut la scanner à nouveau depuis là.
• Terminer la configuration: des éléments tels que « Les dépendances n'ont pas été installées correctement » signalent les mêmes lacunes que l'Étape 2. Travaillez dessus avec l'utilisateur.

Ensuite, l'utilisateur ouvre les Paramètres → Connaissances → Contexte. Le fichier de mémoire de l'Étape 3 doit être listé sous Sources du dépôt et être activé. S'il affiche Créer au lieu de cela, le fichier n'a pas encore atteint la branche connectée.

Voir Paramètres du contexte du projet et Configuration de build et de test.

Étape 8 : Paramètres de l'organisation (optionnel)#

Demandez à l'utilisateur s'il souhaite configurer l'un de ces éléments maintenant. Tous ont des valeurs par défaut utilisables :

• Membres, sous Paramètres → Membres: les personnes qui réviseront les demandes de fusion, en tant que Propriétaire, Administrateur, Membre ou Réviseur. Recommandez l'Administrateur uniquement pour les personnes qui doivent modifier les politiques et les clés de fournisseur. Nécessite l'offre Professional.
• Clés de fournisseur, sous Paramètres → Clés de fournisseur: uniquement pour utiliser les comptes de fournisseur de modèles propres à l'organisation. L'utilisateur saisit la clé dans le portail. Recommandez une clé restreinte avec une limite de dépense chez le fournisseur.
• Paramètres d'une autre organisation: exportez un lot de paramètres là-bas et importez-le sous Paramètres → Données → Exporter les paramètresLes secrets circulent sous forme de espaces réservés, donc chaque needsRebind élément dans l'aperçu nécessite une attention particulière.

Voir Créez votre compte et votre organisation, Clés de fournisseur et Exporter et importer les paramètres.

Étape 9 : Se connecter à Coroid (facultatif)#

Si votre client prend en charge les serveurs MCP distants, vous pouvez accéder à Coroid via son serveur MCP à l'adresse https://api.coroid.ai/mcp. La configuration n'en dépend pas, mais cela vous permet de vérifier les projets vous-même et d'aider l'utilisateur à exécuter des tâches ultérieurement.

1. L'utilisateur ouvre Paramètres → Connexions → Coroid MCP server (https://client.coroid.ai/settings/connections/coroid-mcp). Si cette fonctionnalité n'est pas disponible pour son organisation, ignorez cette étape.
2. Configuration du client affiche les commandes par client. Avec OAuth, l'utilisateur approuve votre accès dans son navigateur. Avec un jeton d'accès personnel, l'utilisateur le crée sous Jeton d'accès et le stocke dans une variable d'environnement de son propre shell. Vous n'avez jamais besoin de voir sa valeur.
3. Recommandez le niveau d'accès minimal suffisant : mcp.read pour vérifier la configuration, plus mcp.work.write uniquement si vous devez créer des tâches. Limitez le jeton à ces projets, fixez-lui une date d'expiration et définissez Politiques d'automatisation avant que tout client n'exécute des tâches en autonomie.

Vérification : appelez list_projects, puis get_project pour chaque projet de l'étape 6, et confirmez le dépôt et la branche.

N'utilisez que api.coroid.ai pour MCP. L'hôte du portail client ne le prend pas en charge.

Voir Coroid en tant que serveur MCP.

Étape 10 : Rédiger une première tâche#

Terminez en rédigeant une petite première tâche avec l'utilisateur dans l'un des nouveaux projets. Une bonne première tâche est réelle, petite, proche des tests existants et possède une fin clairement définie. Évitez l'authentification, les paiements, les migrations de données, les nettoyages sans objectif précis et tout ce qui nécessite une décision de conception non encore prise.

Décrivez le résultat, pas l'implémentation : ce qui doit être vrai une fois le travail terminé, quels fichiers sont concernés et ce qu'il faut éviter de modifier. L'utilisateur la soumet depuis Nouveau travail (https://client.coroid.ai/work/new), lit la spécification et approuve le plan. L'exécution des tâches consomme des heures d'agent ; l'offre gratuite en inclut 2 par jour UTC, laissez donc l'utilisateur décider quand elles seront exécutées.

Voir Exécutez votre première tâche et Spécifications.

Étape 11 : Transférer la responsabilité#

Donnez à l'utilisateur le relevé de configuration :

• chaque dépôt, son projet, le mode de dépôt et la branche de base
• comment le contrôle des sources est connecté, et qui en est propriétaire : l'installateur de l'application, ou le propriétaire du jeton et sa date d'expiration
• par dépôt, les corrections apportées, celles en attente (comme une demande de fusion ouverte avec AGENTS.md), et celles que l'utilisateur a choisi de laisser de côté
• les paramètres optionnels configurés ou ignorés, ainsi que la première tâche rédigée

Indiquez ensuite à l'utilisateur l'emplacement de Réviser et fusionner le résultat pour connaître le contenu de la première livraison de pull request.

Suivant#

Créez votre compte et votre organisation — la même configuration, réalisée manuellement.