Configurer l'assistant AI

Cette page constitue un guide pratique destiné à un assistant AI : Claude Code, Codex, Cursor ou tout autre assistant capable de lire une page web et, idéalement, d'interagir avec une copie locale de votre dépôt. Ce guide accompagne l'assistant dans la configuration de Coroid pour un ou plusieurs dépôts. Il vous interrompt à chaque étape nécessitant une action humaine : se connecter, accorder des accès, saisir un secret ou approuver un changement.

Transmettez-le à votre assistant.#

Ouvrez votre assistant dans le dépôt sur lequel vous souhaitez que Coroid intervienne, 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 effectuera l'inspection et la vérification, et vous indiquera précisément ce qu'il faut faire à chaque étape nécessitant votre intervention.

Règles fondamentales à respecter par l'assistant.#

Vous configurez Coroid, une usine logicielle hébergée AI qui transforme une description de tâche en demande de fusion testée et révisée pull request au sein du dépôt de l'utilisateur. Suivez 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 accorder des droits d'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 avoir terminé.
2. Ne mentionnez jamais de secrets dans la conversation. Jamais de demande de mot de passe, de jeton d'accès personnel, de clé de fournisseur ou de jeton MCP. L'utilisateur saisit ces éléments sensibles dans le portail Coroid ou via son propre terminal. Si un tel élément est quand même collé dans le chat, 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 de fusion dans le dépôt de l'utilisateur, les projets Coroid et les 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 lorsque celle-ci réussit ou si l'utilisateur décide de la sauter.
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 instructions 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, en fin de processus.

Chaque étape relie les pages aux détails. https://coroid.ai/llms.txt 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 nécessitant l'intervention de l'utilisateur et les dépôts concernés.

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

Étape 2 : Vérifier que chaque dépôt peut être compilé et testé à partir d'une copie propre.#

C'est le travail le plus utile que vous puissiez effectuer. Chaque tâche Coroid s'exécute dans un espace de travail Linux propre et temporaire : un clone frais, sans aucun élément en cache ni aucune installation au-delà de la chaîne d'outils de l'image. Un agent incapable de compiler et de tester le projet ne peut pas vérifier son propre travail, et ses tâches échouent lors de la vérification pour des raisons sans rapport avec la modification.

Si vous pouvez travailler localement sur le dépôt, procédez ainsi pour chaque dépôt :

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 les commandes d'installation, de compilation et de test 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 et que le clone frais 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 de test
   • Des variables d'environnement ou un .env fichier non validé
   • Des registres de paquets privés
   • Un environnement d'exécution absent du environnement de l'agent

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

Rapportez une brève vérification de prêt par dépôt : les commandes, la durée d'exécution de la suite, ce qui a réussi et chaque lacune avec une solution proposée.

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

Consultez Configuration de compilation et de test et Prise en charge des langages et environnement de l'agent.

Étape 3 : Rédigez les instructions que lisent les agents Coroid#

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

Proposez un AGENTS.md, ou une addition au fichier existant, indiquant :

• Les commandes d'installation, de compilation et de test, vérifiées à partir d'un clone propre, ainsi que le répertoire où les exécuter
• Les étapes et services nécessaires aux 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 que le code ne montre pas : modules figés, zones à ne pas modifier, dépendances à ne pas ajouter

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

Affichez la différence au utilisateur. Après son approbation, validez-la sur une nouvelle branche et ouvrez un pull request, ou laissez-le le faire 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 de la même manière les corrections acceptées par l'utilisateur lors de l'étape 2.

Voir 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.

Demandez à 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érification : 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 permettent de connecter le contrôle de source et d'ajouter des clés de fournisseur.

Voir Créer votre compte et organisation.

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

Examinez les exigences d'accès avec l'utilisateur avant qu'il ne commence. Une installation interrompue en attente de 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).

Application GitHub : sur l'écran d'installation de GitHub, l'utilisateur sélectionne Sélectionner uniquement les dépôts et choisit ceux convenus lors de l'étape 1. L'application continue de fonctionner même après le départ de la personne qui l'a installée, reçoit les événements de webhook et permet à Coroid de publier ses vérifications sur les demandes de tirage. Un jeton ne peut pas publier de vérifications GitHub.

Jeton d'accès personnel : l'utilisateur le crée sur GitHub avec une date d'expiration, et le colle dans le portail Coroid. Privilégiez un jeton granulé limité aux dépôts convenus. Les demandes de tirage sont attribuées au propriétaire du jeton, et la connexion est rompue si cette personne perd l'accès.

GitLab#

GitLab est en prévisualisation 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 le api champ. Si GitLab n'apparaît pas sous Contrôle de source, demandez à l'utilisateur de contacter Coroid, et ne comptez pas sur cette fonctionnalité.

Protection de branche#

Coroid génère des demandes de fusion classiques, donc la protection des branches, les vérifications requises et les règles de révision restent applicables. Il est recommandé de conserver cette protection activée. Si les règles exigent des commits signés ou une vérification d'état que Coroid ne peut pas produire, ses demandes de fusion seront ouvertes mais resteront non fusionnables. Informez l'utilisateur et ne modifiez pas ses règles.

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

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

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

Créez un projet par dépôt ; ne créez jamais deux projets 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 de fusion, ou Local uniquement, où Coroid n'écrit jamais dans le dépôt avant qu'une personne n'active Démarrer la synchronisation
3. vérifie la branche par défaut
4. crée le projet

Si l'équipe effectue la fusion dans une branche autre que la branche par défaut, comme develop, définissez la branche de base dans les paramètres du dépôt du projet. Une mauvaise branche de base envoie les demandes de fusion 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 pour ce dépôt
• la portée du jeton est trop limitée pour l'afficher dans la liste.
• Le dépôt appartient à une organisation différente de celle qui est connectée.

Consultez 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 ainsi que 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 convenu. 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 détecte. Comparez-les avec le résultat de 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 cet endroit.
• Terminer la configuration: des éléments tels que « Les dépendances n'ont pas été installées correctement » signalent les mêmes problèmes que lors de l'étape 2. Résolvez-les 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 à la place, le fichier n'a pas encore atteint la branche connectée.

Consultez Paramètres du contexte du projet et Configuration de la compilation et des tests.

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

Demandez à l'utilisateur s'il souhaite configurer l'un de ces éléments maintenant. Tous disposent de valeurs par défaut fonctionnelles.

• Membres, sous Paramètres → Membres: les personnes qui effectueront la révision des demandes d'intégration en tant que Propriétaire, Administrateur, Membre ou Reviewer. Ne recommandez l'attribution du rôle d'Administrateur qu'aux personnes pouvant modifier les politiques et les clés de fournisseur. Cette fonctionnalité nécessite un abonnement Professional.
• Clés de fournisseur, sous Paramètres → Clés de fournisseur: uniquement pour utiliser les comptes de fournisseurs de modèles propres à l'organisation. L'utilisateur saisit la clé dans le portail. Il est conseillé d'utiliser une clé à accès restreint avec une limite de dépense définie chez le fournisseur.
• Paramètres provenant d'une autre organisation: exportez un lot de paramètres là-bas et importez-le sous Paramètres → Données → Exporter les paramètres. Les secrets sont transmis sous forme de place-holders ; chaque needsRebind élément de l'aperçu nécessite donc une attention particulière.

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

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

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 cette fonctionnalité 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 → Automatisation → Coroid MCP server (https://client.coroid.ai/settings/automation/coroid-mcp). Si cette fonctionnalité n'est pas disponible pour son organisation, ignorez cette étape.
2. Configuration du client affiche les commandes spécifiques à chaque 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'aurez 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 aux projets concernés, attribuez-lui une date d'expiration et configurez Politiques d'automatisation avant que tout client ne s'exécute sans surveillance.

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

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

Consultez 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, de petite taille, 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 attendu, pas l'implémentation : ce qui doit être vrai à l'issue du travail, 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 ; le forfait Gratuit inclut 2 heures par jour UTC, laissez donc l'utilisateur décider du moment de leur exécution.

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

Étape 11 : Transférer la responsabilité#

Remettez à l'utilisateur l'enregistrement de la configuration :

• Chaque dépôt, son projet, le mode de dépôt et la branche de base
• La manière dont le contrôle de source est connecté, ainsi que le propriétaire de cette connexion : l'installateur de l'application, ou le détenteur 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 et ignorés, ainsi que la première tâche rédigée

Ensuite, orientez l'utilisateur vers Réviser et fusionner le résultat pour connaître le contenu de la première pull request.

Suivant#

Créer votre compte et votre organisation — la même configuration, effectuée manuellement.