Kom igång med din AI-assistent

Den här sidan är en körhandbok för en AI-assistent: Claude Code, Codex, Cursor eller någon annan assistent som kan läsa en webbsida och helst arbeta med en lokal kopia av ditt repository. Den guidar assistenten genom att konfigurera Coroid för ett eller flera repositoryn. Vid varje steg som bara en människa kan utföra stannar assistenten och väntar på dig: logga in, bevilja åtkomst, ange en hemlighet eller godkänna en ändring.

Ge instruktionerna till din assistent#

Öppna assistenten i det repository där du vill att Coroid ska arbeta och ge den den här prompten:

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.

Om du har flera repositoryn öppnar du assistenten i en katalog som innehåller dem alla och nämner dem i prompten. Assistenten inspekterar och kontrollerar, och talar om exakt vad du behöver göra vid varje steg som kräver din insats.

Grundregler för assistenten#

Du konfigurerar Coroid, en driftad AI-mjukvarufabrik som omvandlar en arbetsbeskrivning till en testad och granskad pull request i användarens källkod. Följ de här reglerna hela tiden:

1. Användaren agerar, du förbereder. Du kan inte skapa ett konto, logga in, godkänna villkor, installera appar eller bevilja åtkomst åt användaren. Tala om exakt vad användaren ska göra och var, och vänta sedan tills användaren bekräftar att det är klart.
2. Håll hemligheter utanför konversationen. Be aldrig om ett lösenord, en personlig åtkomsttoken, en leverantörsnyckel eller en MCP-token. Användaren skriver in hemligheter i portalen för Coroid eller i sitt eget skal. Om en hemlighet ändå klistras in i chatten ber du användaren att återkalla den och skapa en ny.
3. Fråga innan varje ändring: commits, brancher och pull requests i användarens repository, Coroid-projekt och inbjudningar.
4. Kontrollera varje steg innan du går vidare. Om en kontroll misslyckas följer du anvisningarna i det steget och fortsätter först när kontrollen har godkänts eller användaren väljer att hoppa över den.
5. Följ produkten, inte dina antaganden. Om portalen visar något som inte beskrivs i den här körhandboken berättar du för användaren vad du ser och följer portalen. Hitta inte på några inställningar.
6. Dokumentera konfigurationen för varje steg och resultatet av det, i slutet.

Varje steg länkar till sidor med mer information. https://coroid.ai/llms.txt indexerar hela dokumentationen.

Steg 1: Kom överens om planen#

Ställ de här frågorna till användaren tillsammans, inte en i taget:

Upprepa sedan planen: stegen nedan, vad användaren behöver göra och vilka repositories som ingår.

Se Planer och priser, Gränser och kvoter och Synkroniserat eller endast lokalt.

Steg 2: Kontrollera att varje repository kan byggas och testas från en ren klon#

Det här är det mest värdefulla arbetet du kan göra. Varje Coroid-uppgift körs i en ren, förgänglig Linux-arbetsyta: en ny klon utan cache och utan installerade verktyg utöver verktygskedjan i avbildningen. En agent som inte kan bygga och testa projektet kan inte verifiera sitt eget arbete, och uppgifterna misslyckas i verifieringen av skäl som inte har med ändringen att göra.

Om du kan arbeta lokalt i repositoryt gör du så här för varje repository:

1. Ta reda på vilka språk och vilken pakethanterare som används, och om det är ett monorepo.
2. Hitta kommandona för installation, bygge och test i README, CI- konfigurationen och manifestfilerna.
3. Fråga innan du kör något. Klona sedan repositoryt till en tom, tillfällig katalog och kör installation, bygge och tester där utan att något annat är konfigurerat. Användarens arbetskopia har cache och .env -filer som döljer problem.
4. Anteckna allt som körningen behövde men som saknas i en ny klon:
   • tjänster som testerna förutsätter, till exempel en databas, cache eller kö
   • steg före testerna, till exempel kodgenerering, migreringar eller testdata
   • miljövariabler eller en .env -fil som inte har checkats in
   • privata paketregister
   • en runtime-miljö som inte finns i agentmiljön

Kör aldrig kommandon som driftsätter, publicerar eller påverkar delade miljöer. Om testsviten tar lång tid eller anropar betaltjänster ska du fråga användaren först.

Rapportera en kort beredskapskontroll för varje repository: kommandona, hur lång tid testsviten tog, vad som klarade sig och varje brist med ett föreslaget sätt att åtgärda den.

En runtime som saknas är inte heller ett hinder: en container som innehåller verktygskedjan löser det. Om du inte kan komma åt repot lokalt samlar du in det du kan från användaren och antecknar att kontrollen med en ren klon inte genomfördes.

Se Konfiguration av bygge och tester och Språkstöd och agentmiljön.

Steg 3: Skriv instruktionerna som Coroids agenter läser#

Inför varje uppgift läser Coroids agenter minnesfilerna i repot: AGENTS.md, CLAUDE.md eller GEMINI.md i roten, och .cursor/rules. Kommandona du verifierade i steg 2 hör hemma där.

Föreslå en AGENTS.md, eller ett tillägg till den befintliga, som anger:

• installations-, bygg- och testkommandon, verifierade från en ren klon, samt katalogen där de ska köras
• stegen och tjänsterna som testerna behöver
• hur man kör den minsta användbara uppsättningen tester, till exempel för ett paket eller en fil
• konventioner och begränsningar som inte framgår av koden: frysta moduler, områden som inte får ändras och beroenden som inte ska läggas till

Ta inte med sådant som redan framgår av koden, och håll filen kort. Om CLAUDE.md eller .cursor/rules innehåller samma instruktioner, ha dem bara på ett ställe i AGENTS.md och importera den från den andra filen med en rad @AGENTS.md .

Visa användaren diffen. När användaren har godkänt den committar du ändringen på en ny branch och öppnar en pull request, eller låter användaren committa den. Den måste nå basbranchen innan den första uppgiften, eftersom varje uppgift läser minnesfilerna från sin egen checkout av den branchen. Hantera korrigeringarna från steg 2 som användaren godkände på samma sätt.

Se Inställningar för projektkontext och Projektkontext.

Steg 4: Konto och organisation (användaren)#

Hoppa över det här steget om användaren redan tillhör en Coroid-organisation som Ägare eller Administratör.

Be användaren att:

1. registrera sig på https://client.coroid.ai/auth/signup med jobbmejladressen och verifiera adressen
2. godkänna användarvillkoren
3. skapa organisationen

Kontrollera: att användaren kan öppna https://client.coroid.ai/projects. Personen som slutför den här konfigurationen behöver rollen Ägare eller Administratör, eftersom endast dessa roller kan ansluta versionshantering och lägga till leverantörsnycklar.

Se Skapa konto och organisation.

Steg 5: Anslut versionshantering (användaren)#

Gå igenom åtkomstkraven med användaren innan hen börjar. Att installationen stannar halvvägs i väntan på någon annans godkännande är den vanligaste orsaken till att det här steget tar en dag i stället för en minut.

GitHub#

Användaren öppnar Inställningar → Anslutningar → Versionshantering (https://client.coroid.ai/settings/connections/source-control).

GitHub-appen: på GitHubs installationssida väljer användaren Endast utvalda reporepositorier och väljer de som bestämdes i steg 1. Appen fortsätter att fungera även om personen som installerade den slutar, tar emot webhook-händelser och gör att Coroid kan publicera sina kontroller på pull requests. En token kan inte publicera GitHubs kontroller.

Personlig åtkomsttoken: användaren skapar den på GitHub med ett utgångsdatum och klistrar in den i Coroid-portalen. Föredra en finkornig token som begränsas till de överenskomna reporna. Pull requests tillskrivs tokenägaren, och anslutningen slutar fungera om personen förlorar åtkomsten.

GitLab#

GitLab är i privat förhandsversion och visas bara på konton där funktionen är aktiverad. Den ansluter med en personlig åtkomsttoken med scopet api . Om GitLab inte visas under Versionshantering ber du användaren kontakta Coroid och planerar inte utifrån den.

Branchskydd#

Coroid öppnar vanliga pull requests, så branchskydd, obligatoriska kontroller och granskningsregler gäller fortfarande. Rekommendera att skyddet behålls. Om reglerna kräver signerade commits eller en statuskontroll som Coroid inte kan skapa, öppnas dess pull requests men går inte att merga. Informera användaren och ändra inte reglerna.

Kontrollera: leverantören visas som ansluten under Versionshantering. Det verkliga beviset kommer i steg 6, när reporna visas i projektlistan.

Se Anslut din källkod, GitHub, GitLab och Inställningar för repo och branch.

Steg 6: Skapa projekten (användaren)#

Skapa ett projekt per repo, aldrig två för samma repo. Användaren öppnar Projekt → Nytt (https://client.coroid.ai/projects/new) och gör följande för varje repo:

1. väljer det från den anslutna leverantören eller använder Anslut med URL för ett publikt repo
2. väljer Repo-läge: Synkat, där Coroid pushar brancher och öppnar pull requests, eller Endast lokalt, där Coroid aldrig skriver till repot förrän någon väljer Börja synka
3. kontrollerar standardbranchen
4. skapar projektet

Om teamet mergar till något annat än standardbranchen, till exempel develop, anger du basbranchen i projektets repo-inställningar. Fel basbranch gör att pull requests skickas till en branch som ingen granskar.

Om ett repo saknas i listan beror det nästan alltid på något av följande:

• GitHub-appen har inte fått åtkomst till repot
• tokenens behörighet är för begränsad för att visa det
• repot tillhör en annan organisation än den som är ansluten

Se Skapa ditt första projekt och Inställningar för repo och branch.

Steg 7: Kontrollera vad Coroid hittade#

Be användaren öppna översikten för varje projekt och läsa upp Repo detaljerna och allt som listas under Slutför konfigurationen:

• Status och Branch: repot är klonat på den överenskomna basbranchen. Om översikten visar att repot inte har klonats än väljer användaren Klona repo.
• Teknikstack: språken, ramverket, pakethanteraren och testverktygen som Coroid har identifierat. Jämför dem med din beredskapskontroll. Om teknikstacken är tom eller fel efter den första synkningen kan användaren söka igen därifrån.
• Slutför konfigurationen: meddelanden som ”Det gick inte att installera beroenden korrekt” pekar på samma brister som i steg 2. Gå igenom dem tillsammans med användaren.

Sedan öppnar användaren projektets Inställningar → Kunskap → Kontext. Minnesfilen från steg 3 måste finnas under Källor från repo och vara aktiverad. Om det i stället står Skapa har filen ännu inte nått den anslutna branchen.

Se Inställningar för projektkontext och Konfiguration av build och test.

Steg 8: Organisationsinställningar (valfritt)#

Fråga om användaren vill konfigurera något av följande nu. Standardinställningarna fungerar bra:

• Medlemmar, under Inställningar → Medlemmar: personerna som ska granska pull requests, med rollen Ägare, Administratör, Medlem eller Granskare. Rekommendera Administratör endast för personer som ska ändra policyer och leverantörsnycklar. Kräver Professional.
• Leverantörsnycklar, under Inställningar → Leverantörsnycklar: behövs endast om organisationen ska använda sina egna konton hos modellleverantörer. Användaren anger nyckeln i portalen. Rekommendera en begränsad nyckel med en utgiftsgräns hos leverantören.
• Inställningar från en annan organisation: exportera ett inställningspaket där och importera det under Inställningar → Data → Exportera inställningar. Hemligheter följer med som platshållare, så varje needsRebind objekt i förhandsvisningen behöver granskas.

Se Skapa ditt konto och din organisation, Leverantörsnycklar och Exportera och importera inställningar.

Steg 9: Anslut dig till Coroid (valfritt)#

Om klienten stöder fjärranslutna MCP-servrar kan du nå Coroid via dess MCP-server på https://api.coroid.ai/mcp. Konfigurationen är inte beroende av detta, men det låter dig själv kontrollera projekten och senare hjälpa användaren att köra arbete.

1. Användaren öppnar Inställningar → Automatisering → Coroid MCP-server (https://client.coroid.ai/settings/automation/coroid-mcp). Hoppa över det här steget om det inte är tillgängligt för organisationen.
2. Klientkonfiguration visar kommandona för varje klient. Med OAuth godkänner användaren din åtkomst i webbläsaren. Med en personlig åtkomsttoken skapar användaren den under Åtkomsttoken och sparar den som en miljövariabel i sitt eget skal. Du behöver aldrig se värdet.
3. Rekommendera minsta möjliga behörighet: mcp.read för att kontrollera konfigurationen, plus mcp.work.write endast om du ska skapa uppgifter. Begränsa token till de här projekten, ge den ett utgångsdatum och ställ in Automatiseringspolicyer innan någon klient körs utan tillsyn.

Kontrollera: anropet list_projects, sedan get_project för varje projekt från steg 6, och bekräfta repot och branchen.

Använd endast api.coroid.ai för MCP. Klientportalens värdnamn tillhandahåller inte detta.

Se Coroid som MCP-server.

Steg 10: Skapa ett första utkast till uppgift#

Avsluta med att tillsammans med användaren skapa ett utkast till en liten första uppgift i ett av de nya projekten. En bra första uppgift är konkret, liten, nära befintliga tester och har en tydlig slutpunkt. Undvik autentisering, betalningar, datamigreringar, öppna städningar och sådant som kräver ett designbeslut som ännu inte har fattats.

Beskriv resultatet, inte implementationen: vad som ska vara sant när arbetet är klart, vilka filer som är viktiga och vad som inte ska ändras. Användaren skickar in uppgiften via Nytt arbete (https://client.coroid.ai/work/new), läser specifikationen och godkänner planen. Pågående arbete förbrukar agenttimmar, och Free-planen omfattar 2 per UTC-dag, så låt användaren bestämma när det ska köras.

Se Kör din första uppgift och Specifikationer.

Steg 11: Lämna över#

Ge användaren dokumentationen över konfigurationen:

• varje repo, dess projekt, repoläge och basbranch
• hur versionshanteringen är ansluten och vem som äger anslutningen: appens installatör eller tokenens ägare och dess utgångsdatum
• för varje repo, vilka brister som åtgärdats, vilka som återstår (till exempel en öppen pull request med AGENTS.md) och vilka användaren valt att lämna utan åtgärd
• vilka valfria inställningar som gjorts eller hoppats över samt utkastet till den första uppgiften

Hänvisa sedan användaren till Granska och sammanfoga resultatet för att se vad som kommer med den första pull request.

Nästa#

Skapa ditt konto och din organisation — samma konfiguration, utförd manuellt.