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 Repositorys arbeiten kann. Der Leitfaden führt den Assistenten durch die Einrichtung von Coroid für ein oder mehrere Repositorys. An jeder Stelle, an der nur ein Mensch handeln kann – etwa beim Einloggen, Gewähren von Zugriff, Eingeben eines Geheimnisses oder Genehmigen einer Änderung –, hält der Leitfaden für Sie an.

Geben Sie den Leitfaden an Ihren Assistenten weiter.#

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

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 Repositorys öffnen Sie den Assistenten in einem Verzeichnis, das alle enthält, und nennen sie in der Anweisung. Der Assistent führt die Überprüfung durch und teilt Ihnen genau mit, was bei jeder Schritt­e, die Ihre Mitwirkung erfordert, zu tun ist.

Grundregeln für den Assistenten#

Sie legen die Rahmenbedingungen fest; der Assistent bereitet alles vor. Coroid ist eine gehostete AI-Softwarefabrik, die aus einer Arbeitsbeschreibung einen getesteten, überprüften pull request im Repository des Nutzers erstellt. Befolgen Sie diese Regeln durchgehend:

1. Der Nutzer handelt; Sie bereiten vor. Sie können sich nicht anmelden, einloggen, die Nutzungsbedingungen akzeptieren, Apps installieren oder Zugriffsrechte 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 Provider-Schlüssel oder einem MCP-Token. Der Nutzer gibt solche Geheimnisse im Coroid-Portal oder in seiner eigenen Shell ein. Falls doch eines in den Chat eingefügt wird, weisen Sie den Nutzer darauf hin, es zu widerrufen und ein neues zu erstellen.
3. Fragen Sie vor jeder Änderung nach.: Commits, Branches und Pull Requests im Repository des Nutzers, Coroid-Projekte sowie Einladungen.
4. Überprüfen Sie jeden Schritt, bevor Sie zum nächsten übergehen. Falls eine Überprüfung fehlschlägt, beachten Sie die Hinweise zu diesem Schritt und setzen Sie die Arbeit erst fort, wenn die Überprüfung erfolgreich war oder der Nutzer beschließt, den Schritt zu überspringen.
5. Befolgen Sie das Produkt, nicht Ihre Annahmen. Zeigt das Portal etwas, 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. Erstellen Sie eine Aufzeichnung der Einrichtung. Dabei werden jeder Schritt und sein Ergebnis bis zum Schluss festgehalten.

Jeder Schritt verlinkt zu den entsprechenden Detailseiten. https://coroid.ai/llms.txt Damit wird die gesamte Dokumentation indexiert.

Schritt 1: Den Plan abstimmen#

Stellen Sie dem Nutzer diese Fragen gemeinsam, nicht nacheinander:

Dann wiederholen Sie den Plan: die nachfolgenden Schritte, die die Zustimmung des Nutzers benötigen, sowie die betroffenen Repositorys.

Siehe Pläne und Preise, Grenzen und Kontingente und Synchronisiert oder nur lokal.

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

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

Falls Sie vor Ort im Repository arbeiten können, führen Sie dies für jedes Repository durch:

1. Identifizieren Sie die verwendeten Programmiersprachen, den Paketmanager und ob es sich um ein Monorepo handelt.
2. Suchen Sie in der README-Datei, der CI-Konfiguration und den Manifestdateien nach den Installations-, Build- und Testbefehlen.
3. Fragen Sie vor dem Ausführen nach. Klonen Sie anschließend das Repository in ein leeres temporäres Verzeichnis und führen Sie dort Installations-, Build- und Testbefehle aus – ohne weitere Voreinstellungen. Die lokale Arbeitskopie des Nutzers enthält Caches und .env Dateien, die Probleme verbergen.
4. Notieren Sie sich alles, was zur Ausführung nötig war, aber in einem frischen Klon fehlt:
   • Dienste, die die Tests benötigen – etwa Datenbanken, Caches oder Warteschlangen.
   • Schritte vor den Tests, wie Code-Generierung, Migrationen oder Fixtures.
   • Umgebungsvariablen oder ein .env Datei, die nicht commit-ted wurde.
   • Private Paketregistries.
   • Ein Laufzeitumgebung, die nicht im Agenten-Umgebung vorhanden ist.

Führen Sie niemals Befehle aus, die deployen, veröffentlichen oder gemeinsam genutzte Umgebungen beeinflussen. Falls der Test-Suite langsam ist oder bezahlte Dienste nutzt, fragen Sie den Nutzer vorher.

Erstellen Sie einen kurzen Bereitschaftsbericht pro Repository: die Befehle, wie lange der Testlauf gedauert hat, welche Tests erfolgreich waren und jede Lücke samt vorgeschlagenem Fix.

Ein fehlender Laufzeitumgebung 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 des sauberen Clones nicht durchgeführt wurde.

Siehe Konfiguration zum Erstellen und Testen und Sprachunterstützung und die Agenten-Umgebung.

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 einen AGENTS.md, oder eine Ergänzung zur bestehenden Datei, vor, die Folgendes enthält:

• Die Installations-, Erstellungs- und Testbefehle, überprüft nach einem sauberen Clone, sowie das Verzeichnis, in dem sie ausgeführt werden.
• Die Schritte und Dienste, die die Tests benötigen.
• Wie der kleinstmögliche nützliche Test-Satz ausgeführt wird – etwa ein einzelnes Paket oder eine einzelne Datei.
• Konventionen und Grenzen, die im Code nicht ersichtlich sind: gesperrte Module, Bereiche, die nicht verändert werden dürfen, sowie Abhängigkeiten, die nicht hinzugefügt werden sollen.

Verschweigen Sie das, was bereits im Code deutlich wird, und halten Sie die Datei kurz. Falls CLAUDE.md or .cursor/rules dieselben Anweisungen enthält, führen Sie sie einmal in AGENTS.md und importieren Sie sie aus der anderen Datei mit einer @AGENTS.md Zeile.

Zeigen Sie dem Nutzer die Diff-Ansicht an. Nach seiner Freigabe commiten Sie die Änderungen auf einem neuen Branch und öffnen Sie einen pull request, oder überlassen Sie das Committing dem Nutzer. Die Änderungen müssen vor der ersten Aufgabe den Basis-Branch erreichen, da jede Aufgabe die Speicherdateien aus ihrem eigenen Checkout dieses Branches liest. Behandeln Sie die in Schritt 2 vom Nutzer akzeptierten Fixes auf dieselbe Weise.

Siehe 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 um Folgendes:

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

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

Siehe 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 wegen der Zustimmung einer anderen Person vorzeitig abbricht, ist der übliche Grund, warum 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 Repositorys auswählen und wählt die im Schritt 1 vereinbarten aus. Die App funktioniert weiterhin, wenn die Person, die sie installiert hat, das System verlässt – sie empfängt Webhook-Events und ermöglicht es Coroid, seine Prüfungen zu Pull Requests zu veröffentlichen. Ein Token kann keine GitHub-Prüfungen 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 ratsam, ein feingranulares Token zu verwenden, das nur auf die vereinbarten Repositorys zugreifen kann. Pull Requests werden dem Besitzer des Tokens zugeordnet; die Verbindung wird unterbrochen, wenn diese Person keinen Zugriff mehr hat.

GitLab#

GitLab befindet sich in der privaten Vorschau und ist nur auf Konten verfügbar, bei denen es aktiviert ist. Es verbindet sich über ein persönliches Zugriffstoken mit dem api Bereich. Wenn GitLab nicht unter Quellcode-Verwaltung angezeigt wird, soll der Nutzer Coroid kontaktieren und nicht darauf basierend planen.

Branch-Schutz#

Coroid erstellt gewöhnliche Pull Requests – daher gelten weiterhin Branch-Schutz, erforderliche Prüfungen und Revisionsregeln. Es wird empfohlen, den Schutz beizubehalten. 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. Informieren Sie den Nutzer und ändern Sie seine Regeln nicht.

Prüfung: Der Anbieter wird unter Quellcode-Verwaltung als verbunden angezeigt. Der eigentliche Nachweis erfolgt im 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 (der Nutzer)#

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

1. wählt er 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 erst dann auf das Repository schreibt, wenn jemand Synchronisierung starten
3. prüft den Standardbranch
4. erstellt das Projekt

Falls das Team in einen anderen Branch als den Standardbranch merged – beispielsweise 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:

• Die GitHub-App wurde für dieses Repository nicht berechtigt.
• Der Bereich des Tokens ist zu eingeschränkt, um das Repository aufzulisten.
• Das Repository gehört einer anderen Organisation als der verbundenen an.

Siehe Erstellen Sie Ihr erstes Projekt und Einrichtungen für Repository und Branch.

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

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

• Status und Branch: Das Repository wird geklont und auf dem vereinbarten Basis-Branch platziert. Wenn in der Übersicht angezeigt wird, 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: Einträge wie „Abhängigkeiten wurden nicht sauber installiert“ weisen auf dieselben Lücken wie in Schritt 2 hin. Bearbeiten Sie diese gemeinsam mit dem Nutzer.

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

Siehe Projektkontext-Einstellungen und Konfiguration für Build und Test.

Schritt 8: Organisationseinstellungen (optional)#

Fragen Sie den Nutzer, ob er jetzt eine dieser Einstellungen vornehmen möchte. Für alle gilt: Es gibt funktionierende 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 Provider-Schlüssel ändern sollen. Erfordert Professional.
• Anbieter-Schlüssel, unter Einstellungen → Anbieter-Schlüssel: Nur zur Nutzung der eigenen Modell-Provider-Konten der Organisation. Der Nutzer gibt den Schlüssel im Portal ein. Empfehlen Sie einen eingeschränkten Schlüssel mit Ausgabegrenze beim Provider.
• Einstellungen aus einer anderen Organisation: Exportieren Sie dort ein Einstellungspaket und importieren Sie es unter Einstellungen → Daten → Einstellungen exportierenGeheime Daten werden als Platzhalter übertragen, weshalb jedes needsRebind Element in der Vorschau Aufmerksamkeit erfordert.

Siehe Erstellen Sie Ihr Konto und Ihre Organisation, Anbieter-Schlüssel und Einstellungen exportieren und importieren.

Schritt 9: Verbinden Sie sich mit Coroid (optional)#

Falls Ihr Client Remote-MCP-Server unterstützt, können Sie über dessen MCP-Server auf Coroid zugreifen – unter https://api.coroid.ai/mcp. Die Einrichtung hängt nicht davon ab, doch sie ermöglicht es Ihnen, die Projekte selbst zu überprüfen und dem Nutzer später bei der Ausführung zu helfen.

1. Der Nutzer öffnet Einstellungen → Verbindungen → Coroid MCP-Server (https://client.coroid.ai/settings/connections/coroid-mcp). Falls dieser für seine Organisation nicht verfügbar ist, überspringen Sie diesen Schritt.
2. Client-Einrichtung zeigt die Befehle pro Client an. Bei OAuth genehmigt der Nutzer Ihren Zugriff im Browser. Bei einem persönlichen Zugriffstoken erstellt er dieses unter Zugriffstoken und speichert es als Umgebungsvariable in seiner eigenen Shell. Sie müssen den Wert nie einsehen.
3. Empfehlen Sie den minimalen erforderlichen Zugriff: mcp.read zur Überprüfung der Einrichtung, plus mcp.work.write nur, wenn Sie Aufgaben erstellen sollen. Beschränken Sie das Token auf diese Projekte, geben Sie ihm ein Ablaufdatum und setzen Sie Automatisierungsrichtlinien vor der automatischen Ausführung durch einen beliebigen Client.

Überprüfen: rufen Sie list_projects, anschließend get_project für jedes Projekt aus Schritt 6 auf und bestätigen Sie das Repository sowie 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: Entwerfen Sie eine erste Aufgabe#

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

Beschreiben Sie das 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 Spezifikation und genehmigt den Plan. Die Ausführung von Aufgaben verbraucht Agentenstunden; der kostenlose Plan umfasst 2 pro UTC-Tag – lassen Sie den Nutzer entscheiden, wann diese ausgeführt werden.

Siehe Führen Sie Ihre erste Aufgabe aus und Spezifikationen.

Schritt 11: Übergabe#

Geben Sie dem Nutzer die Einrichtungsdokumentation:

• jeweiliges Repository, sein Projekt, der Repository-Modus und der Basis-Branch
• wie die Versionskontrolle verbunden ist und wer die Verbindung besitzt: der Installateur der App oder der Inhaber des Tokens samt Ablaufdatum
• pro Repository, die behobenen Lücken, die offenen Punkte (z. B. ein offener Pull Request mit AGENTS.md), sowie die vom Nutzer bewusst ausgelassenen Punkte
• die vorgenommenen und ausgelassenen optionalen Einstellungen sowie die entworfene erste Aufgabe

Weisen Sie den Nutzer anschließend auf Rezension und Zusammenführung des Ergebnisses hin, um zu sehen, was mit dem ersten pull request ankommt.

Weiter#

Erstellen Sie Ihr Konto und Ihre Organisation – dieselbe Einrichtung, manuell vorgenommen.