PR-feedback blir rörig snabbt. Kommentarer hamnar i fel ordning, prioriteringar är otydliga och ni fastnar i stilfrågor medan verkliga risker slinker igenom. Sedan upprepas samma granskningslärdomar nästa vecka eftersom inget förklarades tydligt nog för att sätta sig.
Den här AI-prompten för pull request reviews är byggd för engineering leads som försöker hålla kvaliteten hög i ett repo med högt tempo, seniora utvecklare som behöver leverera snabbt men fortfarande coacha via granskningar, samt plattform- eller QA-inriktade granskare som måste upptäcka dolda effekter i tester, driftsättningar och beroenden. Resultatet är en stegvis, riskbaserad granskningsplan plus prioriterade, konkreta PR-kommentarer (blockers, förslag och pedagogiska noteringar) förankrade i koden och kontexten du ger.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: interaktiv, riskbaserad pull request-granskning
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[VERSALER_MED_UNDERSCORE] |
Ange valfri variabel formaterad i versaler med understreck, som används för användarinmatade fält i prompten. Till exempel: "[MALGRUPP], [KONTEXT], [ANDRINGSTYP]"
|
|
[MALGRUPP] |
Ange vilken grupp personer eller intressenter som kodändringarna är avsedda för, eller som kommer att dra nytta av pull requesten. Till exempel: "Backendutvecklare som förvaltar API-lagret för en fintech-plattform."
|
|
[KONTEXT] |
Beskriv bakgrunden eller situationen kring pull requesten, inklusive relevanta beroenden, drivkrafter eller relaterat arbete. Till exempel: "Denna PR åtgärdar en bugg där API-svar ibland returnerar felaktiga tidsstämplar på grund av bristfällig hantering av tidszoner."
|
|
[ANDRINGSTYP] |
Ange vilken kategori kodändringen som granskas tillhör, till exempel buggfix, ny funktion, refaktorering eller arkitekturuppdatering. Till exempel: "Buggfix för felaktig hantering av tidsstämplar i API-svaret."
|
|
[HUVUDMAL] |
Beskriv det huvudsakliga målet eller det förväntade resultatet av pull requesten. Till exempel: "Säkerställa att API-svar returnerar korrekta tidsstämplar i alla tidszoner som stöds."
|
|
[PR_STORLEK] |
Ange pull requestens storlek, till exempel antal kodrader, antal ändrade filer eller övergripande komplexitet. Till exempel: "Medelstor: 6 filer ändrade, 150 kodrader tillagda, 40 kodrader borttagna."
|
|
[RISKNIVA] |
Bedöm de potentiella riskerna med pull requesten, till exempel sannolikheten att introducera buggar eller påverka kritiska system. Till exempel: "Måttlig risk: ändringarna påverkar central API-logik men har enhetstestats noggrant."
|
|
[KRITIKALITET] |
Ange hur kritisk pull requesten är för systemets funktionalitet eller verksamhetens prioriteringar. Till exempel: "Hög kritikalitet: åtgärdar en produktionsbugg som orsakar datainkonsekvenser i kundrapporter."
|
|
[TEAMSTANDARDER] |
Beskriv eventuella kodnings- eller processstandarder som teamet följer och som ska efterlevas i pull requesten. Till exempel: "Följ Googles kodformatering och säkerställ att alla nya metoder har enhetstester med 90 %+ täckning."
|
|
[TESTKONTEXT] |
Ange detaljer om testmiljön, testscenarier eller testtäckning som är relevanta för pull requesten. Till exempel: "Enhetstester täcker alla gränsfall för logiken för tidsstämpelkonvertering; integrationstester verifierar API-beteende mot externa system."
|
|
[PRESTANDAKANSLIGHET] |
Ange om prestandaoptimering är kritisk för ändringarna i pull requesten. Till exempel: "Låg känslighet: ändringarna påverkar en sällan använd admin-endpoint med minimal trafik."
|
|
[SAKERHETSKANSLIGHET] |
Ange om pull requesten berör säkerhetsaspekter eller kräver särskilt varsam hantering av känslig data. Till exempel: "Hög känslighet: ändringarna omfattar hantering av autentiseringstoken och kräver validering av kryptering."
|
|
[TIDSRAM] |
Ange deadline eller hur brådskande det är att slutföra granskningen av pull requesten och slå ihop ändringarna. Till exempel: "Brådskande: behöver mergas inom 24 timmar för att lösa ett produktionsproblem."
|
|
[KODUNDERLAG] |
Ange relevanta kodsnuttar, filer eller länkar som behövs för att granska pull requesten. Till exempel: "Fil: api/timestamp_utils.py; Funktion: convert_to_timezone; Tester: test_timestamp_conversion.py."
|
Proffstips för bättre resultat från AI-prompten
- Klistra in ett “granskningspaket”, inte bara diffen. Ta med PR-beskrivningen, fillistan och 2–3 nyckelsnuttar där logiken ändrats. Om det finns ett riskområde (betalningar, behörigheter, cache), säg det tydligt: “Det här rör auth token refresh och session invalidation; var extra strikt på korrekthet.”
- Tvinga assistenten att ställa frågor innan den kommenterar. Efter att du klistrat in PR-konteksten, lägg till: “Gör föranalys först och lista saknad info som frågor.” Det håller resultatet förankrat och brukar lyfta saker som “Vilka felutfall förväntas?” eller “Finns en utrullningsplan?” innan granskningen spårar ur.
- Ge en liten testinventering (även om den är ofullständig). Beskriv det som finns: “Enhetstester tillagda för X; inga integrationstester; manuella QA-steg: A, B.” Fråga sedan: “Vilka tester krävs vs är valfria för merge, och vilka specifika testfall saknas?” Du får mer handlingsbar feedback än ett generiskt “lägg till tester.”
- Iterera stegplanen när PR:en är stor. Efter första resultatet, prova att fråga: “Gör nu stegplanen striktare för korrekthet och datasäkerhet, men lättare kring stil.” Eller: “Kör triage igen och anta att detta släpps bakom en feature flag nästa vecka.” Prompten är gjord för att skala arbetsflödet utan att tappa struktur.
- Gör om kommentarer till en merge-checklista. När du har de prioriterade granskningskommentarerna, följ upp med: “Konvertera blockers och högprioriterade fixar till en checklista med kryssrutor, där varje punkt har ett verifieringssteg.” Till exempel: “Bekräfta att migreringen är bakåtkompatibel genom att köra {specific command} och validera {expected result}.” Ärligt talat är det här snabbaste sättet att slippa omgranska samma osäkerheter om och om igen.
Vanliga frågor
Engineering managers använder den för att standardisera granskningskvaliteten i ett team utan micromanagement, eftersom det stegvisa arbetsflödet gör förväntningar tydliga. Staff- och senioringenjörer får nytta av den eftersom den prioriterar korrekthet och systempåverkan först och sedan hjälper dem skriva pedagogiska kommentarer som faktiskt går fram. Tech leads lutar sig mot den när en PR rör flera moduler och de behöver en snabb men grundlig plan innan de går ner i detaljer. QA- eller releaseansvariga använder den för att säkerställa att testunderlag, utrullningssäkerhet och riskområden är hanterade innan merge.
SaaS-bolag får mycket värde eftersom täta releaser gör konsekventa granskningar svåra, och den här prompten tvingar fram en repeterbar process som skalar från små fixar till stora refaktorer. Fintech- och betalningsteam använder den för att hålla korrekthet och risk högst upp, särskilt för auth, huvudbokslogik, idempotens och bakåtkompatibilitet. Hälso- och compliance-tunga produkter gynnas eftersom prompten uppmuntrar evidensdriven granskning (tester, loggar, avgränsningar) och får granskare att be om saknad kontext i stället för att anta. Utvecklarverktyg och plattformar använder den när PR:er påverkar prestanda, build-pipelines eller API-stabilitet och de behöver pedagogiska noteringar för långsiktig underhållbarhet.
En typisk prompt som ’Granska den här PR:en och säg om den ser bra ut’ misslyckas eftersom den: saknar ett triage-steg för att klassificera omfattning och risk, saknar ett stegvis arbetsflöde så återkopplingen blir en platt blandpåse, ignorerar saknad kontext (krav, begränsningar, utrullningsplaner) och fyller luckor med gissningar, ger generiska stilråd i stället för prioriterade blockers och fixar, och missar de pedagogiska noteringar som hjälper teamet bli bättre över tid. Den här prompten är striktare med korrekthet först, sedan tydlighet och design, så granskningen matchar hur organisationer med hög genomströmning faktiskt jobbar.
Ja, du anpassar den genom att ge den kontext som prompten är byggd för att efterfråga: PR:ens mål, fillista, nyckeldiffar eller snuttar, förväntat beteende och testunderlag. Om ändringen är riskfylld, lägg till begränsningar som “behandla bakåtkompatibilitet som en blocker” eller “anta att vi driftsätter dagligen med canary + feature flags.” En bra följdfråga är: “Kör triage igen och anta att detta är en stor refaktor; öka antalet steg och be mig om eventuellt saknat underlag.” Eftersom prompten använder ett interaktivt arbetsflöde är den största “anpassningen” vilket underlag du ger i varje steg.
Det största misstaget är att bara ge en vag PR-beskrivning — i stället för “Refactor user service”, skriv “Refactor user service för att flytta validering till domänlagret; berör 14 filer; lägger till ett nytt interface; inga schemaändringar.” Ett annat vanligt fel är att hoppa över evidens: säg inte “tester går igenom”, säg “Unit: 128 godkända; Integration: inga; Manuell: körde signup + lösenordsåterställning; loggar visar inga nya varningar.” Folk klistrar också in enorma diffar utan fillista eller “hot spots”, vilket gör det svårare att prioritera; peka ut 2–3 områden du vill få granskade hårdast. Slutligen glömmer granskare att ange begränsningar som utrullningsstrategi eller prestandakänslighet, så prompten kan inte riskmärka korrekt.
Den här prompten är inte idealisk för “drive-by”-godkännanden där du vägrar ge kontext, kodsnuttar eller testunderlag, eftersom den stannar och ställer frågor i stället för att gissa. Den är heller ingen ersättning för att köra koden, exekvera tester eller validera runtime-beteende i staging. Och om ditt team bara vill ha en snabb checklista för stilpetigheter kan den stegvisa, riskbaserade metoden kännas tyngre än ni vill ha. I så fall, kör en lätt lint- och formateringspass först och återkom sedan till den här prompten för granskningen med högre påverkan.
En bra kodgranskning handlar inte om fler kommentarer. Den handlar om rätt kommentarer i rätt ordning, med underlag som stöd. Klistra in den här prompten i ditt AI-verktyg, mata in din PR-kontext och genomför en granskning du kan stå för.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.