Hoppa till innehåll
September 3, 2026

Från GitHub-issue till pull request: planens livscykel i Ivy Tendril

I Ivy Tendril omvandlas ett GitHub-issue till en pull request genom en fast sekvens av faser: ärendet anländer till Inbox via webhook, en agent tar fram ett planutkast, en utvecklare granskar och godkänner planen, en agent exekverar den i ett isolerat git worktree, automatisk verifiering körs, utvecklaren granskar den resulterande diffen och en agent öppnar en pull request. Människor agerar vid exakt två tillfällen: vid planen och vid diffen. Allt annat hanteras av agenter, och många ärenden rör sig genom sekvensen samtidigt. Denna artikel följer ett ärende genom varje steg.

Livscykeln i korthet

Ivy kallar detta arbetsflöde för en mjukvarufabrik: en förutbestämd sekvens av steg där agenter utför arbetet och människor inspekterar resultatet vid definierade kontrollpunkter. Faserna, vem som agerar och villkoret som avslutar respektive steg listas nedan. Den fullständiga referensen finns i livscykeldokumentationen.

Fas Vem agerar Slutvillkor
Inbox Agent (webhook) Ärendet sparas med titel, brödtext, etiketter och länk
Draft plan Agent (CreatePlan) Ett utkast med mål, omfattning, berörda filer och verifieringssteg har skapats
Plan review, kontrollpunkt 1 Människa Utvecklaren godkänner planen, efter eventuella kommentarer och omskrivningar
Execute Agent (ExecutePlan) Agenten rapporterar planen som slutförd i sitt worktree
Verify Agent Tester och lint har körts och diffen är redo för granskning (verifieringsgrindar)
Diff review, kontrollpunkt 2 Människa Utvecklaren godkänner diffen
Pull request Agent (CreatePr) En pull request finns på GitHub för planens gren, öppnad via REST-API:et för pull requests
Merge och rensning Människa mergar, agent rensar Worktreet tas bort och lärdomar sparas i minnet

Från issue till godkänd plan

Ärendet anländer

En användare registrerar issue #418 i kodförrådet: "Export to CSV drops rows with commas in the description field." GitHub-integrationen skickar det till Tendrils Inbox via webhook. Ingenting körs än. Inbox är en lista över inkommande ärenden, och en utvecklare avgör vilka som ska bli planer. Felrapporter från jam.dev tas emot på samma sätt.

CreatePlan skapar ett planutkast

Utvecklaren markerar ärendet och väljer Create plan. Promptwaren CreatePlan läser ärendet, sitt eget minne av kodförrådet samt relevant källkod och skriver ett utkast. Ett typiskt utkast anger målet, filerna som förväntas ändras (src/export/csv.ts och dess testfil), angreppssättet (citera fält som innehåller avgränsaren enligt RFC 4180) samt verifieringsstegen (lägg till ett test med kommatecken i beskrivningen, kör befintliga exporttester). Utkastet visas i Drafts.

Kontrollpunkt 1: Utvecklaren granskar planen

Detta är den första av två mänskliga kontrollpunkter. Utvecklaren läser utkastet och upptäcker ett problem: planen föreslår att endast beskrivningsfältet ska citeras, men samma bugg påverkar alla fritextkolumner. Istället för att skriva om planen manuellt markerar utvecklaren stycket och lägger till en anteckning: "Apply the quoting to all string columns, not just description." Promptwaren UpdatePlan skriver om planen med anteckningen tillämpad, och det reviderade utkastet är redo för en ny genomgång.

Om utkastet saknar detaljer kan utvecklaren köra ExpandPlan. Om anteckningarna visar att ärendet i själva verket består av två separata uppgifter – exempelvis en buggfix och en separat migrering av exportmodulen till ett gemensamt CSV-bibliotek – delar SplitPlan upp det i två planer som fortsätter oberoende av varandra. När utvecklaren är nöjd godkänns planen. Den utgör nu den bindande specifikationen för körningen, och agenten behöver inte tolka det ursprungliga ärendet på nytt.

Exekvering och verifiering

ExecutePlan körs i ett isolerat worktree

Vid godkännande skapar Tendril ett git worktree för planen på en egen gren och startar den valda agenten i det. Utvecklaren väljer agent per plan: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode eller någon annan CLI-agent. Arbetsflödet är detsamma oavsett vilken agent som väljs.

Worktreet är avgörande eftersom andra planer körs samtidigt. Varje plan har sin egen arbetskatalog och gren, vilket innebär att en halvfärdig ändring i en plan inte kan påverka en annan, och huvudgrenen (main) förblir orörd fram till granskningen. Skälen till denna design förklaras i git worktrees för parallella AI-agenter.

Medan agenten arbetar strömmar Jobs-vyn dess utdata och verktygsanrop i realtid: lästa filer, körda kommandon, exekverade tester samt förbrukade tokens och kostnad hittills. Utvecklaren kan titta på, eller granska en annan plan under tiden. Med en Cloudflare Quick Tunnel aktiverad är samma ström tillgänglig direkt i mobilen.

Verifiering körs

När agenten rapporterar att planen är klar körs automatisk verifiering i dess worktree: testsviten och lintern exekveras, och den resulterande diffen samlas in för granskning. Resultaten presenteras i Review-vyn under tre flikar: tests, lint och diff. Ett misslyckat test eller ett linterfel syns innan någon människa lägger tid på att läsa koden. Pro- och Enterprise-abonnemang kan även importera verifieringsresultat från CI. Argumenten för att behandla verifiering som en strikt grind snarare än en rekommendation finns i verifieringsgrindar för AI-genererad kod.

Granskning, pull request och rensning

Kontrollpunkt 2: Utvecklaren granskar diffen

Detta är den andra mänskliga kontrollpunkten. I Review granskar utvecklaren diffen sida vid sida med planen och verifieringsresultaten. För ärende #418 berör diffen src/export/csv.ts, lägger till en hjälpfunktion för citering och utökar testfilen med tre testfall: ett kommatecken, ett citattecken och en radbrytning inuti ett fält. Testerna passerar och lintern är grön. Utvecklaren godkänner diffen.

Om diffen inte godtas håller utvecklaren inne godkännandet, uppdaterar planen med vad som saknades och kör igen. Ingenting når GitHub utan detta godkännande.

CreatePr öppnar en pull request

Promptwaren CreatePr öppnar pull requesten från planens gren. Härifrån tar teamets normala gransknings- och mergeprocess på GitHub vid. Tendrils Pull Requests-vy spårar statusen för varje öppen PR som skapats på detta sätt.

Efter merge

När pull requesten mergas tar Tendril automatiskt bort det tillhörande worktreet. Promptwaren ExecutePlan skriver sedan ned vad den lärt sig i minnet. För detta ärende sparas en post i stil med "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export", och nästa plan som berör exportmodulen läser informationen innan arbetet påbörjas.

Hela kedjan, för ett ärende av denna storlek, tar några minuters agenttid och två korta manuella granskningar. Ivy rapporterar att det egna teamet gick från cirka 10 till fler än 100 pull requests per dag efter att ha infört detta arbetsflöde, med de två kontrollpunkterna intakta.

Så kommer du igång

Installera Tendril, koppla på GitHub-integrationen så att ärenden kommer in i Inbox och kör ett första ärende genom flödet med en enskild agent innan du kör planer parallellt.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

På Windows kör du irm https://cdn.ivy.app/install-tendril.ps1 | iex. Den kostnadsfria versionen, tillgänglig med öppen källkod under Functional Source License, inkluderar hela livscykeln. Pro och Enterprise tillför teamfunktioner, import av verifiering från CI och lokal on-premise-drift.

Vanliga frågor

Kan agenten hoppa över en kontrollpunkt om ändringen är liten?

Nej. De två kontrollpunkterna gäller för varje plan. En enradig fix genomgår plangodkännande och diffgodkännande precis som alla andra planer. Mindre planer tar helt enkelt kortare tid att granska.

Vad händer när två parallella planer ändrar i samma fil?

Varje plan arbetar i sitt eget worktree och på en egen gren, så konflikten uppstår inte under själva körningen. Den uppdagas när den andra pull requesten rebasas eller mergas, och löses på sedvanligt git-manér. Genom att dela upp planer modulärt minimeras risken för konflikter.

Måste ärendet komma från GitHub?

Nej. Planer kan skapas utifrån en inskriven idé, en felrapport från jam.dev, CLI, REST-API:et eller MCP-servern. Webhooken från GitHub är bara en av flera ingångar till Inbox.

Kom igång med Ivy Tendril

Är du redo för parallell agentorkestrering på utvecklarnivå?

Written by

Ivy Team