Kom igång med din AI-assistent

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

Ge den till din assistent#

Öppna assistenten i det repository som du vill att Coroid ska arbeta med 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 repositories öppnar du assistenten i en katalog som innehåller dem alla och anger vilka det gäller i prompten. Assistenten granskar och kontrollerar, och berättar exakt vad du ska göra vid varje steg som kräver din medverkan.

Grundregler för assistenten#

Du konfigurerar Coroid, en värdbaserad AI-mjukvarufabrik som omvandlar en beskrivning av arbetet till en testad och granskad pull request i användarens repository. Följ de här reglerna hela tiden:

1. Användaren agerar, du förbereder. Du kan inte registrera användaren, logga in, godkänna villkor, installera appar eller bevilja åtkomst åt användaren. Beskriv exakt vad som ska göras 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 anger hemligheter i Coroid-portalen eller i sitt eget skal. Om någon ändå klistrar in en hemlighet i chatten, säg åt användaren att återkalla den och skapa en ny.
3. Be om godkännande före varje ändring: commits, branches 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 steget och fortsätter först när den 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örmanualen berättar du vad du ser och följer portalen. Hitta inte på inställningar.
6. Dokumentera konfigurationen för varje steg och dess resultat, så att du kan sammanfatta allt i slutet.

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

Steg 1: Kom överens om planen#

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

Upprepa sedan planen: stegen nedan, vilka som kräver användarens medverkan och vilka repositories som ingår.

Se Planer och priser, Begränsningar 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, tillfällig Linux-arbetsyta: en ny klon, ingen cachad data och inget installerat 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 vart och ett:

1. Identifiera språken, pakethanteraren och om det är ett monorepo.
2. Leta reda på installations-, bygg- och testkommandona i README-filen, CI- konfigurationen och manifestfilerna.
3. Be om lov 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 innehåller cachad data och .env filer som döljer problem.
4. Anteckna allt som behövdes för körningen men saknas i en ny klon:
   • tjänster som testerna förutsätter, till exempel en databas, en cache eller en 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 körtidsmiljö som inte finns i agentmiljön

Kör aldrig kommandon som distribuerar, publicerar eller påverkar delade miljöer. Om testsviten är långsam eller anropar avgiftsbelagda tjänster frågar du användaren först.

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

En saknad körtidsmiljö är inte heller ett hinder: en container som innehåller verktygskedjan löser problemet. Om du inte kan nå repositoryt lokalt samlar du in det du kan från användaren och antecknar att kontrollen med en ren klon inte genomfördes.

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

Steg 3: Skriv instruktionerna som Coroid-agenterna läser#

Inför varje uppgift läser Coroid-agenterna minnesfilerna i repositoryt: AGENTS.md, CLAUDE.md eller GEMINI.md i rotkatalogen, samt .cursor/rules. Kommandona som 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 testkommandona, verifierade från en ren klon, och 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 får läggas till

Utelämna sådant som redan framgår av koden och håll filen kort. Om CLAUDE.md eller .cursor/rules innehåller samma instruktioner ska de bara finnas en gång i AGENTS.md och importeras från den andra filen med en rad @AGENTS.md .

Visa användaren diffen. Med användarens godkännande checkar du in den på en ny branch och öppnar en pull request, eller låter användaren checka in 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 organisation på Coroid som Ägare eller Administratör.

Be användaren att:

1. registrera sig på https://client.coroid.ai/auth/signup med sin jobbmejladress 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 måste ha rollen Ägare eller Administratör, eftersom endast dessa roller kan ansluta versionshantering och lägga till leverantörsnycklar.

Se Skapa ditt konto och din organisation.

Steg 5: Anslut versionshantering (användaren)#

Gå igenom åtkomstkraven med användaren innan hen börjar. En installation som 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 App: på installationssidan för GitHub väljer användaren Välj endast repoin och väljer de som ni kom överens om i steg 1. Appen fortsätter att fungera även när 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 GitHub kontroller.

Personlig åtkomsttoken: användaren skapar den på GitHub med ett utgångsdatum och klistrar in den i Coroid-portalen. Välj helst en detaljerad token som är begränsad till de repoin ni kom överens om. 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 den är aktiverad. Den ansluter med en personlig åtkomsttoken med omfånget api . Om GitLab inte visas under Versionshantering ska du be användaren kontakta Coroid och inte planera med det som ett alternativ.

Branchskydd#

Coroid öppnar vanliga pull requests, så branchskydd, obligatoriska kontroller och granskningsregler gäller fortfarande. Rekommendera att skyddet är aktiverat. Om reglerna kräver signerade commits eller en statuskontroll som Coroid inte kan skapa kommer dess pull requests att öppnas men inte gå 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 repoin visas i projektlistan.

Se Anslut din kod, 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 Repoläge: Synkat, där Coroid pushar brancher och öppnar pull requests, eller Endast lokalt, där Coroid inte 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 repoinställningar. Med fel basbranch skickas pull requests till en branch som ingen granskar.

Om ett repo saknas i listan är orsaken nästan alltid någon av följande:

• GitHub App fick inte åtkomst till repot
• tokenens omfång är för begränsat för att visa det
• repot tillhör en annan organisation än den anslutna

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 detaljer och allt som visas under Slutför konfigurationen:

• Status och Branch: repot är klonat på den basbranch ni kom överens om. Om översikten visar att repot inte har klonats än väljer användaren Klona repo.
• Teknikstack: språken, ramverket, pakethanteraren och testverktygen som Coroid hittade. Jämför dem med din kontroll av att allt är klart. 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 utan problem” 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 visas under Repokällor och aktiveras. Om det i stället står Skapa i stället har filen ännu inte nått den anslutna branchen.

Se Inställningar för projektkontext och Konfiguration för bygge och tester.

Steg 8: Organisationsinställningar (valfritt)#

Fråga om användaren vill ställa in något av följande nu. Alla har fungerande standardvärden:

• Medlemmar, under Inställningar → Medlemmar: personerna som ska granska pull requests, som Ägare, Administratör, Medlem eller Granskare. Rekommendera Administratör endast för personer som ska kunna ändra policyer och leverantörsnycklar. Kräver Professional.
• Leverantörsnycklar, under Inställningar → Leverantörsnycklar: 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ärifrån och importera det under Inställningar → Data → Exportera inställningar. Hemligheter överförs som platshållare, så varje needsRebind objekt i förhandsvisningen behöver ses över.

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

Steg 9: Anslut dig själv till Coroid (valfritt)#

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

1. Användaren öppnar Inställningar → Anslutningar → Coroid MCP-server (https://client.coroid.ai/settings/connections/coroid-mcp). Om den inte är tillgänglig för organisationen hoppar du över det här steget.
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 i en miljövariabel i sitt eget skal. Du behöver aldrig se värdet.
3. Rekommendera minsta möjliga åtkomst som fungerar: mcp.read för att kontrollera konfigurationen, plus mcp.work.write endast om du ska skapa uppgifter. Begränsa token till dessa projekt, ange ett utgångsdatum och ställ in Automatiseringspolicyer innan någon klient körs utan tillsyn.

Kontrollera: anropa list_projects, sedan get_project för varje projekt från steg 6, och bekräfta repository och branch.

Använd endast api.coroid.ai för MCP. Värdnamnet för klientportalen hanterar inte detta.

Se Coroid som MCP-server.

Steg 10: Skapa ett första utkast till en 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 ett tydligt slutmål. Undvik autentisering, betalningar, datamigreringar, öppna städjobb och allt som kräver ett designbeslut som ännu inte har fattats.

Beskriv resultatet, inte hur det ska genomföras: 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 från Nytt arbete (https://client.coroid.ai/work/new), läser specifikationen och godkänner planen. Pågående arbete använder agenttimmar, och Free-abonnemanget inkluderar 2 per UTC-dygn, 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 repository, dess projekt, repository-läge och basbranch
• hur källkodshanteringen är ansluten och vem som äger anslutningen: den som installerade appen eller tokenägaren och tokenens utgångsdatum
• för varje repository, vilka brister som åtgärdats, vilka som återstår (till exempel en öppen pull request med AGENTS.md) och vilka användaren valde 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.