PR:er saktar inte ner team för att koden är svår. De saktar ner team för att triage är rörigt: inga konsekventa etiketter, ingen snabb första granskning, och en Slack-tråd som börjar först efter att någon pingat “kan någon titta?” tre gånger.
Engineering Managers märker det när cykeltiden drar iväg och ingen kan förklara varför. En DevOps Engineer ser det när PR:er med “liten ändring” levereras sent för att de begravs. Och ärligt talat tröttnar seniora utvecklare på att upprepa samma feedback i första rundan. Den här automatiseringen för GitHub Slack triage ger varje PR en omedelbar, konsekvent grundgranskning.
Du sätter upp ett workflow som läser PR-diffen, applicerar användbara etiketter, postar en strukturerad granskningskommentar, larmar Slack och loggar detaljerna i Google Sheets så att du kan se vad som faktiskt händer över tid.
Så fungerar automatiseringen
Här är hela workflowet du kommer att sätta upp:
n8n Workflow Template: GitHub + Slack: snabbare PR-triage och tydliga larm
flowchart LR
subgraph sg0["AI Code Reviewer Flow"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>GitHub PR Webhook"]
n1@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Filter PR Events", pos: "b", h: 48 }
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Extract PR Data"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Get PR Files"]
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch PR Diff"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge PR Info"]
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Analyze File Changes"]
n7@{ icon: "mdi:brain", form: "rounded", label: "OpenAI Chat Model", pos: "b", h: 48 }
n8@{ icon: "mdi:robot", form: "rounded", label: "AI Code Reviewer", pos: "b", h: 48 }
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Parse AI Review"]
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Add PR Labels"]
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Post Review Comment"]
n12["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/slack.svg' width='40' height='40' /></div><br/>Notify Slack"]
n13@{ icon: "mdi:cog", form: "rounded", label: "Aggregate Results", pos: "b", h: 48 }
n14@{ icon: "mdi:database", form: "rounded", label: "Log to Sheets", pos: "b", h: 48 }
n15["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Respond to Webhook"]
n3 --> n5
n12 --> n13
n10 --> n13
n4 --> n5
n14 --> n15
n5 --> n6
n2 --> n3
n2 --> n4
n9 --> n10
n9 --> n11
n9 --> n12
n8 --> n9
n1 --> n2
n13 --> n14
n0 --> n1
n7 -.-> n8
n11 --> n13
n6 --> n8
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n8 ai
class n7 aiModel
class n1 decision
class n14 database
class n0,n4,n15 api
class n2,n6,n9 code
classDef customIcon fill:none,stroke:none
class n0,n2,n3,n4,n5,n6,n9,n10,n11,n12,n15 customIcon
Varför det här spelar roll: PR:er fastnar i “granskningslimbo”
De flesta team har inte ett “granskningsproblem”. De har ett triage-problem. En ny pull request kommer in, och ingen vet om det är en liten refaktorering, en riskabel konfigurationsändring eller en stor feature som behöver ett extra par ögon. Så den blir liggande. Eller så får den ett snabbt “LGTM” utan kontext, vilket inte hjälper någon. Under tiden blir Slack stökigt, utvecklare byter kontext, och samma grundläggande kontroller (omfattning, risk, ledtrådar om testtäckning) upprepas av människor varje gång. Det är utmattande och ett dåligt användande av senior uppmärksamhet.
Var för sig känns problemen små. Tillsammans drar de ner både genomströmning och kvalitet.
- PR-etiketter blir inkonsekventa, så du kan inte sortera arbete efter risk eller storlek med någon säkerhet.
- Granskare slösar tid på att öppna en PR bara för att förstå vad som ändrades och var.
- Slack-notiser är antingen för vaga (“ny PR”) eller för pratiga, så folk stänger av mentalt.
- Det finns ingen strukturerad rapporteringskedja, vilket gör det svårt att förbättra granskningsstandarden vecka för vecka.
Det du bygger: automatiserad PR-triage + AI-granskning i första passet
Det här workflowet startar i samma ögonblick som en pull request öppnas (eller uppdateras) i GitHub. Det hämtar PR-metadata, tar fram listan över ändrade filer och laddar ner rå diff så att det kan bedöma vad som faktiskt ändrades. Därefter kategoriserar det uppdateringen med enkel logik (till exempel etiketter för ändringsstorlek som size/S eller size/L) och skickar diffen till en AI-granskare byggd på OpenAI. AI:n producerar en strukturerad sammanfattning, en kvalitetspoäng och konkreta styrkor och risker som läses som en riktig första-rundan-granskning. Till sist uppdaterar workflowet PR:n med rätt etiketter, postar en granskningskommentar i GitHub, skickar en tydlig Slack-notis till er teamkanal och loggar hela händelsen i Google Sheets för uppföljning.
Workflowet börjar med en GitHub webhook-trigger och samlar sedan in PR-detaljer och diff. Efter det genererar AI en åtgärdsbar granskning som du faktiskt kan använda, och workflowet publicerar resultatet till GitHub, Slack och Google Sheets så att samma information syns överallt.
Det du bygger
| Vad som automatiseras | Vad du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att ditt team hanterar cirka 15 PR:er per dag. En mänsklig “första titt” är ofta 10 minuter: kolla filer, skumma diff, gissa risk, skriva en snabb sammanfattning för Slack. Det är ungefär 2,5 timmar per dag bara för att komma till punkten där riktig granskning kan börja. Med det här workflowet är triggern omedelbar, AI-granskningen kör i bakgrunden, och den enda “manuella” tiden är att läsa sammanfattningen i Slack eller GitHub. För många team betyder det att ni får tillbaka ett par timmar varje dag samtidigt som granskningarna blir mer konsekventa.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- GitHub för webhook, repo-åtkomst, etiketter och kommentarer
- Slack för att notifiera er #code-reviews-kanal
- Google Sheets för att logga PR-metadata och utfall
- OpenAI API-nyckel (hämta den i OpenAI API-dashboarden)
Kunskapsnivå: Medel. Du klistrar in en webhook-URL i GitHub, kopplar in credentials i n8n och justerar en prompt utan att förstöra strukturen.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
En pull request triggar workflowet. GitHub skickar en händelse av typen “pull request opened” eller “synchronize” till n8n:s webhook, och workflowet kontrollerar direkt att det är en PR-åtgärd du bryr dig om.
PR-detaljer och diffar samlas in. n8n hämtar metadata (titel, författare, branch, URL:er), tar fram listan över ändrade filer via GitHub-noden och laddar ner rå diff via en HTTP-request så att granskningen baseras på de faktiska ändringarna.
AI skapar en praktisk granskning i första passet. Workflowet bedömer ändringens påverkan (som “liten vs stor”) och skickar diffen till en AI Agent med en OpenAI chat-modell. Du får tillbaka en sammanfattning, en kvalitetspoäng och konkreta styrkor och risker, som sedan tolkas till strukturerade fält som n8n kan agera på.
GitHub, Slack och Sheets uppdateras. Etiketter appliceras i GitHub, en granskningskommentar postas i PR-diskussionen, Slack får en kortfattad notis med nyckelpunkterna och Google Sheets sparar resultatet för senare rapportering.
Du kan enkelt ändra etiketteringsreglerna och prompten till AI-granskaren så att de matchar teamets standarder. Se hela implementationsguiden nedan för alternativ kring anpassning.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera webhook-triggern
Ställ in den inkommande GitHub-webhooken så att workflowet kan ta emot pull request-händelser.
- Lägg till noden PR Webhook Intake och ställ in Path till
github-pr-review. - Ställ in HTTP Method till
POSToch Response Mode tillresponseNode. - I GitHub skapar ni en webhook för pull request-händelser som pekar mot n8n-webhook-URL:en som genereras av PR Webhook Intake.
Tips: Använd GitHub-händelserna “Pull request” (opened och synchronize) så att nästa filtersteg släpper igenom rätt payload-struktur.
Steg 2: Anslut GitHub och validera PR-åtgärder
Filtrera webhooken så att endast relevanta PR-händelser hanteras, och förbered GitHub-åtkomst för att hämta filer och göra uppdateringar.
- I Validate PR Actions ställer ni in första villkoret för att jämföra Left Value
={{ $json.body.action }}med Right Valueopened. - Lägg till ett andra villkor i Validate PR Actions med Left Value
={{ $json.body.action }}och Right Valuesynchronize, och använd kombinatorn OR. - Öppna Retrieve PR Files och ställ in Owner till
={{ $json.repoOwner }}, Repository till={{ $json.repoName }}, Resource tillfileoch Operation tilllist. - Öppna Apply PR Labels och Publish Review Comment för att förbereda GitHub-credentials för uppdatering av etiketter och kommentarer.
Credentials krävs: Anslut era GitHub-credentials i Retrieve PR Files, Apply PR Labels och Publish Review Comment.
Steg 3: Ställ in PR-databearbetning och parallell hämtning
Parsa inkommande webhook-payload och hämta filer och diff-data parallellt för efterföljande analys.
- I Parse Pull Request Info klistrar ni in den tillhandahållna JavaScript-koden för att extrahera fält som
prNumber,repoOwner,repoNameochdiffUrl. - Ställ in Download PR Diff URL till
={{ $('Parse Pull Request Info').first().json.diffUrl }}. - Konfigurera Combine PR Details med Mode
combineoch Combine BycombineAll. - Bekräfta exekveringsflödet: Parse Pull Request Info skickar utdata till både Retrieve PR Files och Download PR Diff parallellt, och därefter matar båda in i Combine PR Details.
⚠️ Vanlig fallgrop: Om GitHub skickar ett annat payload-format kan Parse Pull Request Info missa body.pull_request. Validera med en testhändelse via webhook.
Steg 4: Ställ in AI-granskning och tolkning
Skapa en AI-granskning utifrån diff-sammanfattningen och tolka sedan svaret till etiketter och kommentarer.
- I Assess Change Impact behåller ni den tillhandahållna JavaScript-koden för att beräkna
diffPreviewochsuggestedLabelsbaserat på storlek. - Konfigurera OpenAI Chat Engine med Model satt till
gpt-4o-mini. - I AI Review Agent ställer ni in Text till
=PR Review for: {{ $json.prTitle }}. Diff: {{ $json.diffPreview }}och behåller System Message som beskriver JSON-formatet. - I Interpret AI Review använder ni befintlig JavaScript-kod för att mappa AI-utdata till
finalLabelsochreviewComment.
Credentials krävs: Anslut era OpenAI-credentials i OpenAI Chat Engine. AI Review Agent använder OpenAI Chat Engine som språkmodell, så credentials måste läggas till i den överordnade modellnoden.
Steg 5: Konfigurera utdataåtgärder och loggning
Applicera etiketter, publicera kommentarer, avisera i Slack och logga resultatet innan ni svarar webhooken.
- I Apply PR Labels ställer ni in Owner till
={{ $json.repoOwner }}, Repository till={{ $json.repoName }}, Issue Number till={{ $json.prNumber }}och Labels till={{ $json.finalLabels }}. - I Publish Review Comment ställer ni in Body till
={{ $json.reviewComment }}och behåller Operation somcreateComment, med Owner, Repository och Issue Number mappade från PR-fälten. - I Send Slack Alert ställer ni in Text till
New PR Review for #{{ $json.prNumber }}, Select tillchanneloch uppdaterar värdet för Channel ID[YOUR_ID]. - Bekräfta parallell exekvering: Interpret AI Review skickar utdata till Apply PR Labels, Publish Review Comment och Send Slack Alert parallellt.
- I Aggregate Outcomes ställer ni in Aggregate till
aggregateAllItemDataoch konfigurerar sedan Append to Sheets med Operationappend. - Slutför svaret med Return Webhook Reply satt till Respond With
jsonoch Response Body={{ {success: true} }}.
Credentials krävs: Anslut era Slack-credentials i Send Slack Alert och era Google Sheets-credentials i Append to Sheets.
Steg 6: Testa och aktivera ert workflow
Verifiera hela flödet end-to-end med en riktig PR-händelse och aktivera sedan workflowet för produktionsanvändning.
- Klicka på Execute Workflow och skicka en testhändelse för pull request från GitHub till PR Webhook Intake-URL:en.
- Verifiera att både Retrieve PR Files och Download PR Diff körs, och kontrollera sedan att Combine PR Details och Assess Change Impact ger sammanslagen data.
- Bekräfta utdata: etiketter applicerade i GitHub, en kommentar publicerad av Publish Review Comment, ett Slack-meddelande från Send Slack Alert och en ny rad tillagd av Append to Sheets.
- När ni är nöjda växlar ni workflowet till Active för att aktivera körning i produktion.
Tips för felsökning
- GitHub-credentials kan löpa ut eller sakna repo-scope. Om etiketter eller kommentarer misslyckas, kontrollera credentials i GitHub-noden och bekräfta att tokenen har rätt att skriva till issues och pull requests.
- Om du använder HTTP-requests för att hämta diffar kan GitHub returnera trunkerade svar för väldigt stora PR:er. När AI-utdata ser “tunn” ut, verifiera steget som laddar ner diff och överväg att begränsa vilka filer du inkluderar.
- Slack bot-tokens fungerar ofta, men boten är inte inbjuden till kanalen. Om notiser inte syns, öppna kanaldetaljerna i Slack och lägg till appen i kanalen först.
Snabba svar
Cirka 30 minuter om GitHub, Slack och Sheets redan är redo.
Nej. Du kopplar konton, klistrar in en webhook-URL i GitHub och justerar ett par fält och prompts.
Ja. n8n har ett gratis alternativ för egen drift och en gratis testperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in OpenAI API-kostnader, som vanligtvis är några cent per PR beroende på diffens storlek.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och klarar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det bör du. De flesta team börjar med att redigera systemmeddelandet i “AI Code Reviewer” så att det matchar era kodstandarder och önskad ton, och justerar sedan logiken i “Assess Change Impact” och “Analyze File Changes” för att lägga till etiketter som frontend, documentation eller infra baserat på filsökvägar. Du kan också lägga till en If-nod efter AI-analysen för att hantera edge cases, som att bara posta Slack-notiser när kvalitetspoängen ligger under er tröskel.
Oftast handlar det om utgångna OAuth-credentials eller saknade repo-behörigheter. Anslut GitHub-credential på nytt i n8n och bekräfta att den kan skriva etiketter och kommentarer till det repositoriet. Om det bara faller på vissa PR:er, kontrollera om PR:n kommer från en fork, eftersom behörigheter kan vara begränsade där.
Tillräckligt för de flesta team. På n8n Cloud Starter får du en månatlig körningskvot, och varje PR-händelse räknas vanligtvis som en körning. Om du kör egen drift finns ingen plattformsgräns för antal körningar; du begränsas av din server och tiden det tar att hämta diffar och köra AI-granskningen.
Ofta, ja. Det här workflowet behöver grenlogik, några transformationssteg och en AI-granskning som baseras på hela diffen, inte ett litet sammanfattningsfält. n8n hanterar den typen av “riktiga workflows” utan att ta extra betalt för varje väg. Egen drift är också viktigt om du har många PR:er och vill slippa oro för pris per uppgift. Zapier eller Make kan fortfarande vara bra för enkla “PR öppnad → skicka meddelande”-notiser, men när du lägger till etikettering, analys och loggning är n8n oftast det lugnare valet. Vill du ha hjälp att välja, prata med en automationsexpert.
När detta är live kommer PR:er in med kontext, etiketter och en grundgranskning redan bifogad. Du lägger granskningstiden på faktisk ingenjörsbedömning, inte på att lista ut vad som ändrades.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.