Einrichten mit Ihrem AI‑Assistenten

Diese Seite ist ein Leitfaden für einen AI-Assistenten: Claude Code, Codex, Cursor oder jeden anderen Assistenten, der eine Webseite lesen und idealerweise in einer lokalen Kopie Ihres Repositories arbeiten kann. Der Leitfaden führt den Assistenten durch die Einrichtung von Coroid für ein oder mehrere Repositories. Bei jedem Schritt, der nur von einer Person ausgeführt werden kann – etwa das Anmelden, Gewähren von Zugriff, Eingeben eines Geheimnisses oder Genehmigen einer Änderung –, hält der Prozess für Sie an.

Geben Sie es Ihrem Assistenten.#

Öffnen Sie Ihren Assistenten im Repository, in dem Coroid arbeiten soll, und geben Sie ihm diese Anweisung ein:

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.

Für mehrere Repositories öffnen Sie den Assistenten in einem Verzeichnis, das alle enthält, und nennen Sie sie in der Anweisung. Der Assistent führt die Überprüfung und Prüfung durch und teilt Ihnen genau mit, was bei jedem Schritt zu tun ist, der Ihre Mitwirkung erfordert.

Grundregeln für den Assistenten#

Sie richten Coroid ein, eine gehostete AI-Softwarefabrik, die aus einer Arbeitsbeschreibung einen getesteten und überprüften pull request im Repository des Nutzers hervorbringt. Befolgen Sie diese Regeln durchgehend:

1. Der Nutzer handelt; Sie bereiten vor. Sie können sich nicht anmelden, einloggen, Nutzungsbedingungen akzeptieren, Apps installieren oder dem Nutzer Zugriff gewähren. Teilen Sie genau mit, was zu tun ist und wo, und warten Sie, bis der Nutzer bestätigt, dass es erledigt ist.
2. Halten Sie Geheimnisse aus dem Gespräch heraus. Fragen Sie niemals nach einem Passwort, einem persönlichen Zugriffstoken, einem Anbieter-Schlüssel oder einem MCP-Token. Der Nutzer gibt Geheimnisse im Coroid-Portal oder in seiner eigenen Shell ein. Falls eines versehentlich in den Chat eingefügt wird, weisen Sie den Nutzer an, es zu widerrufen und ein neues zu erstellen.
3. Fragen Sie vor jeder Änderung.: Commits, Branches und Pull Requests im Repository des Nutzers, Coroid-Projekten sowie Einladungen.
4. Prüfen Sie jeden Schritt, bevor Sie zum nächsten übergehen. Fällt eine Prüfung fehl, nutzen Sie die Hinweise zu diesem Schritt und setzen Sie den Vorgang erst fort, wenn die Prüfung erfolgreich war oder der Nutzer beschließt, den Schritt zu überspringen.
5. Befolgen Sie das Produkt, nicht Ihre Annahmen. Zeigt das Portal etwas an, das in diesem Leitfaden nicht beschrieben wird, teilen Sie dem Nutzer mit, was Sie sehen, und folgen Sie dem Portal. Erfinden Sie keine Einstellungen.
6. Führen Sie ein Einrichtungsprotokoll. zu jedem Schritt und seinem Ergebnis, für das Ende.

Jeder Schritt verknüpft die Seiten mit den entsprechenden Details. https://coroid.ai/llms.txt Die gesamte Dokumentation wird indiziert.

Schritt 1: Den Plan vereinbaren#

Stellen Sie dem Nutzer diese Fragen gemeinsam, nicht einzeln:

Wiederholen Sie anschließend den Plan: die untenstehenden Schritte, die die Mitwirkung des Nutzers erfordern, sowie die betroffenen Repositories.

Sehen Sie sich Pläne und Preise, Grenzen und Kontingente und Synchronisiert oder nur lokal.

Schritt 2: Prüfen Sie, ob jedes Repository aus einem sauberen Klon kompiliert und getestet werden kann.#

Das ist die nützlichste Arbeit, die Sie leisten können. Jede Coroid-Aufgabe läuft in einer sauberen, verwertbaren Linux-Arbeitsumgebung: ein frischer Klon, ohne Cache und ohne zusätzliche Installationen außer dem Toolchain des Images. Ein Agent, der das Projekt nicht erstellen und testen kann, ist nicht in der Lage, seine eigene Arbeit zu verifizieren – und seine Aufgaben scheitern bei der Überprüfung aus Gründen, die nichts mit der Änderung zu tun haben.

Wenn Sie im Repository lokal arbeiten können, führen Sie dies für jedes Repository durch:

1. Identifizieren Sie die verwendeten Programmiersprachen, den Paketmanager sowie ob es sich um ein Monorepo handelt.
2. Suchen Sie in der README-Datei, der CI-Konfiguration und den Manifests nach den Installations-, Build- und Testbefehlen.
3. Fragen Sie vor dem Ausführen von Befehlen nach. Klonen Sie anschließend das Repository in ein leeres temporäres Verzeichnis und führen Sie dort Installations-, Build- und Testschritte ohne weitere Voraussetzungen aus. Die lokale Arbeitskopie des Nutzers enthält nämlich Caches und .env Dateien, die Probleme verbergen.
4. Notieren Sie sich alles, was für die Ausführung benötigt wird, aber bei einem frischen Klon fehlt:
   • Dienste, die die Tests erfordern – etwa eine Datenbank, einen Cache oder eine Warteschlange.
   • Schritte vor den Tests, wie Code-Generierung, Migrationen oder Fixtures.
   • Umgebungsvariablen oder ein .env Datei, die nicht committet wurde.
   • Private Paketregistries.
   • Eine Laufzeitumgebung, die nicht im Agenten-Umfeld enthalten ist.

Führen Sie niemals Befehle aus, die etwas deployen, veröffentlichen oder gemeinsam genutzte Umgebungen beeinflussen. Falls der Testlauf langsam ist oder kostenpflichtige Dienste nutzt, fragen Sie den Nutzer zuvor.

Berichten Sie für jedes Repository über eine kurze Bereitschaftsprüfung: die benötigten Befehle, die Dauer des Testlaufs, was erfolgreich war sowie jede Lücke mit einem vorgeschlagenen Fix.

Ein fehlendes Laufzeitmodul ist ebenfalls kein Hindernis: Ein Container, der die Toolchain enthält, löst das Problem. Falls Sie das Repository lokal nicht erreichen können, sammeln Sie vom Nutzer so viele Informationen wie möglich und vermerken Sie, dass die Prüfung mit einem sauberen Klon nicht stattgefunden hat.

Siehe Build- und Testkonfiguration und Sprachunterstützung und das Agenten-Umfeld.

Schritt 3: Verfassen Sie die Anweisungen, die die Agenten von Coroid lesen.#

Vor jeder Aufgabe lesen die Agenten von Coroid die Speicherdateien im Repository: AGENTS.md, CLAUDE.md oder GEMINI.md im Root-Verzeichnis und .cursor/rules. Die in Schritt 2 überprüften Befehle gehören dorthin.

Schlagen Sie eine AGENTS.mdvor – oder eine Ergänzung zur bestehenden Datei –, die Folgendes enthält:

• Die Installations-, Build- und Testbefehle, überprüft anhand eines sauberen Klons, sowie das Verzeichnis, in dem sie ausgeführt werden sollen.
• Die Schritte und Dienste, die die Tests benötigen.
• Wie der kleinste sinnvolle Testlauf ausgeführt wird – etwa für ein einzelnes Paket oder eine einzelne Datei.
• Konventionen und Grenzen, die im Code nicht ersichtlich sind: eingefrorene Module, Bereiche, die nicht verändert werden dürfen, sowie Abhängigkeiten, die nicht hinzugefügt werden sollen.

Vermeiden Sie Angaben, die bereits im Code stehen, und halten Sie die Datei kurz. Falls CLAUDE.md oder .cursor/rules dieselben Anweisungen enthalten, notieren Sie sie einmal in AGENTS.md und importieren Sie sie aus der anderen Datei mit einer @AGENTS.md Zeile.

Zeigen Sie dem Nutzer die Unterschiede an. Nach seiner Freigabe wird der Commit auf einem neuen Branch erstellt und ein pull request geöffnet – oder der Nutzer kann den Commit selbst vornehmen. Der Branch muss vor dem ersten Task den Basissbranch erreichen, da jeder Task die Speicherdateien aus seinem eigenen Checkout dieses Branches liest. Behebungen aus Schritt 2, die der Nutzer akzeptiert hat, werden auf dieselbe Weise behandelt.

Sehen Sie sich an Projektkontext-Einstellungen und Projektkontext.

Schritt 4: Konto und Organisation (der Nutzer)#

Überspringen Sie diesen Schritt, wenn der Nutzer bereits als Inhaber oder Administrator zu einer Coroid-Organisation gehört.

Bitten Sie den Nutzer:

1. sich bei https://client.coroid.ai/auth/signup mit seiner Arbeits-E-Mail anzumelden und die Adresse zu verifizieren
2. die Nutzungsbedingungen zu akzeptieren
3. die Organisation zu erstellen

Prüfen Sie: ob der Nutzer https://client.coroid.ai/projectsöffnen kann. Die Person, die diese Einrichtung abschließt, benötigt die Rolle des Inhabers oder Administrators, denn nur diese Rollen können die Quellcode-Verwaltung verbinden und Anbieter-Schlüssel hinzufügen.

Sehen Sie sich an Ihr Konto und Ihre Organisation erstellen.

Schritt 5: Quellcode-Verwaltung verbinden (der Nutzer)#

Gehen Sie vor Beginn mit dem Nutzer die Zugriffsanforderungen durch. Eine Installation, die zur Freigabe durch eine andere Person unterbrochen wird, ist der übliche Grund dafür, dass dieser Schritt einen Tag statt einer Minute dauert.

GitHub#

Der Nutzer öffnet Einstellungen → Verbindungen → Quellcode-Verwaltung (https://client.coroid.ai/settings/connections/source-control).

GitHub App: auf dem Installationsbildschirm von GitHub wählt der Nutzer Nur die gewünschten Repositories auswählen und markiert die in Schritt 1 vereinbarten Repositories. Die App bleibt auch dann aktiv, wenn die Person, die sie installiert hat, das Unternehmen verlässt; sie empfängt Webhook-Events und ermöglicht es Coroid, seine Prüfungen zu Pull Requests zu veröffentlichen. Ein Token kann GitHub-Prüfungen nicht veröffentlichen.

Persönliches Zugriffstoken: der Nutzer erstellt es auf GitHub mit einem Ablaufdatum und fügt es anschließend in das Coroid-Portal ein. Es ist besser, ein feingranulares Token zu verwenden, das auf die vereinbarten Repositories beschränkt ist. Pull Requests werden dem Besitzer des Tokens zugeordnet, und die Verbindung wird unterbrochen, wenn diese Person den Zugriff verliert.

GitLab#

GitLab befindet sich in der privaten Vorschau und ist nur auf Konten verfügbar, bei denen es aktiviert ist. Es verbindet sich mit einem persönlichen Zugriffstoken mit dem api Bereich. Wenn GitLab unter Quellcode-Verwaltung nicht angezeigt wird, weisen Sie den Nutzer an, sich an Coroid zu wenden – planen Sie nicht umgekehrt darauf.

Branch-Schutz#

Coroid erstellt gewöhnliche Pull Requests – daher gelten weiterhin Regeln zur Branch-Sicherung, zu erforderlichen Prüfungen und zur Rezension. Es wird empfohlen, die Sicherung aktiv zu belassen. Falls die Regeln signierte Commits oder einen Status-Check erfordern, den Coroid nicht generieren kann, werden die Pull Requests zwar geöffnet, bleiben aber unmergebar. Teilen Sie dies dem Nutzer mit und ändern Sie die Regeln nicht.

Prüfen: Der Anbieter wird unter Quellcode-Verwaltung als verbunden angezeigt. Der eigentliche Beweis erfolgt in Schritt 6, wenn die Repositorys in der Projektliste erscheinen.

Siehe Ihren Code verbinden, GitHub, GitLab und Repository- und Branch-Einstellungen.

Schritt 6: Die Projekte erstellen (vom Nutzer)#

Erstellen Sie pro Repository ein Projekt – niemals zwei für ein einziges Repository. Der Nutzer öffnet Projekte → Neu (https://client.coroid.ai/projects/new) und für jeweils ein Repository:

1. wählt es aus dem verbundenen Anbieter aus oder nutzt Mit URL verbinden für ein öffentliches Repository
2. wählt den Repository-Modus: Synchronisiert – dabei pusht Coroid Branches und öffnet Pull Requests – oder Nur lokal, wobei Coroid niemals in das Repository schreibt, bis jemand Synchronisierung starten
3. prüft den Standardbranch
4. erstellt das Projekt

Falls das Team in einen anderen Branch als den Standardbranch zusammenführt, etwa develop, muss der Basis-Branch in den Repository-Einstellungen des Projekts festgelegt werden. Ein falscher Basis-Branch führt dazu, dass Pull Requests an einen Branch gesendet werden, den niemand prüft.

Fehlt ein Repository in der Liste, liegt die Ursache fast immer in einem der folgenden Fälle:

• der GitHub-App wurde keine Berechtigung für dieses Repository gewährt
• der Umfang des Tokens ist zu eingeschränkt, um das Repository aufzulisten
• das Repository gehört zu einer anderen Organisation als die verbundene

Siehe Ihr erstes Projekt erstellen und Repository- und Branch-Einstellungen.

Schritt 7: Überprüfen, was Coroid gefunden hat#

Bitten Sie den Nutzer, die Übersicht jedes Projekts zu öffnen und die Repository Details sowie alle Einträge unter Einrichtung abschließen:

• Status und Branch: Das Repository wurde geklont und befindet sich im vereinbarten Basis-Branch. Zeigt die Übersicht an, dass das Repository noch nicht geklont wurde, wählt der Nutzer Repository klonen.
• Stack: Die von Coroid erkannten Programmiersprachen, Frameworks, Paketmanager und Testwerkzeuge. Vergleichen Sie diese mit Ihrer Bereitschaftsprüfung. Ist der Stack nach der ersten Synchronisierung leer oder falsch, kann der Nutzer ihn dort erneut scannen.
• Einrichtung abschließen: Meldungen wie „Abhängigkeiten wurden nicht sauber installiert“ weisen auf dieselben Lücken wie in Schritt 2 hin. Arbeiten Sie diese gemeinsam mit dem Nutzer ab.

Anschließend öffnet der Nutzer die Einstellungen → Wissen → Kontext. Die Speicherdatei aus Schritt 3 muss unter Repository-Quellen aufgeführt sein und aktiviert sein. Zeigt es stattdessen Erstellen , dann hat die Datei den verbundenen Branch noch nicht erreicht.

Siehe Projekt-Kontext-Einstellungen und Build- und Test-Konfiguration.

Schritt 8: Organisationseinstellungen (optional)#

Fragen Sie den Nutzer, ob er diese jetzt einrichten möchte. Für alle gelten brauchbare Standardwerte:

• Mitglieder, unter Einstellungen → Mitglieder: die Personen, die Pull Requests rezensieren – als Inhaber, Administrator, Mitglied oder Rezensent. Empfehlen Sie die Rolle Administrator nur für Personen, die Richtlinien und Anbieter-Schlüssel ändern dürfen. Voraussetzung: Professional-Lizenz.
• Anbieter-Schlüssel, unter Einstellungen → Anbieter-Schlüssel: nur zur Nutzung der Modell-Anbieter-Konten der Organisation. Der Nutzer gibt den Schlüssel im Portal ein. Es wird empfohlen, einen eingeschränkten Schlüssel mit Ausgabegrenze beim Anbieter zu verwenden.
• Einstellungen aus einer anderen Organisation: Einstellungspaket dort exportieren und unter Einstellungen → Daten → Einstellungen exportieren. Geheime Daten werden als Platzhalter übertragen; daher muss jedes needsRebind Element in der Vorschau überprüft werden.

Siehe Konto und Organisation erstellen, Anbieter-Schlüssel und Einstellungen exportieren und importieren.

Schritt 9: Sich selbst mit Coroid verbinden (optional)#

Falls Ihr Client Remote-MCP-Server unterstützt, können Sie Coroid über dessen MCP-Server unter https://api.coroid.ai/mcperreichen. Die Einrichtung hängt nicht davon ab, doch so können Sie die Projekte selbst überprüfen und dem Nutzer später bei der Arbeitsausführung helfen.

1. Der Nutzer öffnet Einstellungen → Automatisierung → Coroid MCP-Server (https://client.coroid.ai/settings/automation/coroid-mcp). Falls dieser für seine Organisation nicht verfügbar ist, diesen Schritt überspringen.
2. Client-Einrichtung zeigt die Befehle pro Client an. Bei OAuth genehmigt der Nutzer den Zugriff in seinem Browser. Bei einem persönlichen Zugriffstoken erstellt der Nutzer dieses unter Zugriffstoken und speichert es in einer Umgebungsvariablen seiner eigenen Shell. Sie müssen den Wert nie einsehen.
3. Empfehlen Sie den geringsten möglichen Zugriff: mcp.read zum Überprüfen der Einrichtung, sowie mcp.work.write nur, wenn Sie Aufgaben erstellen sollen. Beschränken Sie das Token auf diese Projekte, geben Sie ihm ein Ablaufdatum und konfigurieren Sie Automatisierungsrichtlinien bevor ein Client unbeaufsichtigt arbeitet.

Überprüfen: rufen Sie list_projects, anschließend get_project für jedes Projekt aus Schritt 6 auf und bestätigen Sie das Repository und den Branch.

Verwenden Sie nur api.coroid.ai für MCP. Der Hostname des Client-Portals eignet sich dafür nicht.

Siehe Coroid als MCP-Server.

Schritt 10: Erste Aufgabe entwerfen#

Abschließen Sie die Einrichtung, indem Sie mit dem Nutzer eine kleine erste Aufgabe in einem der neuen Projekte entwerfen. Eine gute erste Aufgabe ist realistisch, klein, passt zu vorhandenen Tests und hat eine klare Zielvorgabe. Vermeiden Sie Authentifizierung, Zahlungen, Datenmigrationen, offene Aufräumarbeiten sowie alles, was eine noch nicht getroffene Designentscheidung erfordert.

Beschreiben Sie das gewünschte Ergebnis, nicht die Implementierung: Was soll nach Abschluss der Arbeit gelten, welche Dateien sind relevant und was darf nicht verändert werden. Der Nutzer sendet die Aufgabe von Neue Aufgaben (https://client.coroid.ai/work/new), liest die Spezifikationen und genehmigt den Plan. Die Ausführung von Aufgaben verbraucht Agent-Stunden; der kostenlose Tarif umfasst 2 pro UTC-Tag. Lassen Sie den Nutzer daher entscheiden, wann die Aufgabe ausgeführt wird.

Siehe Ihre erste Aufgabe ausführen und Spezifikationen.

Schritt 11: Übergabe#

Übergeben Sie dem Nutzer das Einrichtungsprotokoll:

• Für jedes Repository: das zugehörige Projekt, der Repository-Modus und die Basis-Branch.
• Die Art der Verbindung zur Quellcode-Verwaltung sowie der Eigentümer dieser Verbindung: der Installer der App oder der Besitzer des Zugriffstokens samt dessen Ablaufdatum.
• Pro Repository: die behobenen Lücken, die noch offen sind (beispielsweise ein offener Pull Request mit AGENTS.md), sowie diejenigen, die der Nutzer bewusst ausgelassen hat.
• Die vorgenommenen und übersprungenen optionalen Einstellungen sowie die entworfene erste Aufgabe.

Anschließend weisen Sie den Nutzer auf folgendes hin: Ergebnis rezensieren und zusammenführen. – was mit dem ersten pull request übermittelt wird.

Weiter#

Ihr Konto und Ihre Organisation erstellen. – dieselbe Einrichtung, manuell durchgeführt.