17 dec. 2025·6 min
Prompt‑till‑PR‑arbetsflöde med Claude Code: Små diffar
Använd ett Prompt‑till‑PR‑arbetsflöde med Claude Code lokalt: skriv små prompts, leverera små diffar, kör kontroller, skicka om prompt vid fel och nå merge‑klara PR:er.
Använd ett Prompt‑till‑PR‑arbetsflöde med Claude Code lokalt: skriv små prompts, leverera små diffar, kör kontroller, skicka om prompt vid fel och nå merge‑klara PR:er.
Stora engångsprompter leder ofta till stora, stökiga förändringar: dussintals filer ändras, orelaterade refaktorer och kod du inte hunnit förstå. Även om resultatet är tekniskt korrekt känns granskningen riskfylld eftersom det är svårt att se vad som ändrats och varför.
Små diffar löser det. När varje ändring är begränsad och fokuserad kan du läsa den på några minuter, fånga misstag tidigt och undvika att bryta saker du inte tänkte röra. Granskare litar mer på små PR:er, så merges går snabbare och med färre fram‑och‑tillbaka‑kommentarer.
Prompt‑till‑PR är en enkel loop:
Denna rytm förvandlar fel till snabb feedback istället för en överraskning i slutet. Om du ber Claude Code justera en valideringsregel, håll det till just den regeln. Om ett test faller, klistra in den felande outputen och be om den minsta fixen som får testet att passera, inte en omskrivning av hela modulen.
En sak förändras inte: du är fortfarande ansvarig för slutkoden. Behandla modellen som en lokal parprogrammerare som skriver snabbt, inte en autopilot. Du bestämmer vad som går in, vad som lämnas ut och när det är säkert att öppna PR:en.
Börja från en ren baseline. Om din branch ligger efter eller tester redan misslyckas blir varje förslag gissningsarbete. Hämta senaste ändringarna, rebase eller merge enligt teamets preferenser och säkerställ att nuvarande tillstånd är hälsosamt innan du ber om något.
En "lokal parprogrammerare"‑setup betyder att Claude Code redigerar filer i ditt repo medan du behåller kontroll över mål, skyddsrutiner och varje diff. Modellen känner inte till din kodbas om du inte visar den, så var tydlig med filer, begränsningar och förväntat beteende.
Innan första prompten, bestäm var kontroller ska köras. Om du kan köra tester lokalt får du feedback på några minuter, vilket håller iterationerna små. Om vissa kontroller bara körs i CI (vissa lint‑regler, långa sviter, build‑steg) bestäm när du litar på CI så att du inte sitter och väntar efter varje liten ändring.
En enkel preflight:
Ha en liten scratchpad öppen medan du arbetar. Skriv ner begränsningar som "inga API‑ändringar", "behåll bakåtkompatibilitet", "rör endast X‑modulen" plus beslut du fattar. När ett test faller, klistra in det exakta felmeddelandet där också. Denna scratchpad blir det bästa underlaget för din nästa prompt och förhindrar att sessionen driver iväg.
Små diffar börjar med en prompt som medvetet är smal. Den snabbaste vägen till mergbar kod är en ändring du kan granska på en minut, inte en refaktor som tar en timme att förstå.
En bra prompt nämner ett mål, ett område i kodbasen och ett förväntat utfall. Om du inte kan peka på var ändringen ska landa (en fil, mapp eller modul) kommer modellen att gissa och diffen växer.
En prompt‑form som håller ändringarna täta:
Gränser är hemligheten. Istället för "fixa login‑buggen", säg vad som måste vara oförändrat: "Ändra inte API‑formen", "Byt inte namn på publika funktioner", "Inga formateringsändringar", "Undvik nya dependencies." Det talar om för din parprogrammerare var hen inte ska vara smart.
När ändringen känns otydlig, be om en plan innan kod. En kort plan tvingar arbetet i steg och ger dig en chans att godkänna ett litet första steg.
Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.
Om du arbetar i ett team, lägg till granskningsbegränsningar också: "Håll det under ~30 rader ändrade" eller "Endast en fil om inte absolut nödvändigt." Det gör diffen enklare att skumma igenom och skärper följande prompts när något fallerar.
Håll varje loop fokuserad på en liten, testbar ändring. Om du kan beskriva målet i en mening och förutsäga vilka filer som kommer att ändras är det rätt storlek.
Bra enheter av arbete inkluderar: fixa en bugg i en väg (med repro och guard), justera ett enhetstest för ett beteende, göra en beteendebevarande refaktor (byta namn, extrahera funktion, ta bort duplication), eller förbättra ett felmeddelande eller en valideringsregel.
Sätt tidsgräns för varje loop. 10–20 minuter är ofta tillräckligt för att skriva en tydlig prompt, applicera diffen och köra en snabb kontroll. Om du fortfarande utforskar efter 20 minuter, krymp enheten eller byt till undersökningsläge (anteckningar, loggning, felande test) och stoppa där.
Definiera "klart" innan du börjar:
När scope börjar växa, stoppa tidigt. Om du hittar dig själv säga "medan vi ändå är här" har du just hittat nästa iteration. Spara det som ett följdarbete, committa den nuvarande lilla diffen och gå vidare.
Innan du kör tester eller builds, läs diffen som en granskare skulle göra. Här håller workflowen sig ren eller glider tyst in i "varför rörde den den filen?"‑territoriet.
Be först Claude Code sammanfatta vad den ändrat i klartext: vilka filer, beteendeförändringen och vad den inte ändrade. Om den inte kan förklara förändringen tydligt gör diffen troligen för mycket.
Granska sedan själv. Skumma först för omfång, läs sedan för avsikt. Du letar efter drift: orelaterad formatering, extra refaktorer, omdöpta symboler eller ändringar du inte bad om.
En snabb pre‑check:
Om diffen är större än förväntat, försök inte testa dig ut ur det. Återställ och re‑prompta för ett mindre steg. Till exempel: "Lägg bara till ett felande test som reproducerar buggen. Inga refaktorer." Små diffar håller fel enklare att tolka och nästa prompt blir skarpare.
Små diffar lönar sig bara om du verifierar dem direkt. Målet är en tät loop: ändra lite, kontrollera lite, fånga misstag medan kontexten är färsk.
Börja med den snabbaste kontrollen som kan säga "det här är inte rätt." Om du ändrat formatering eller imports, kör lint eller formattering först. Om du rört affärslogik, kör de minsta enhetstesterna som täcker filen eller paketet. Om du ändrat typer eller build‑config, gör en snabb kompileringskontroll.
En praktisk ordning:
När något fallerar, fånga två saker innan du försöker fixa: kommandot du körde och hela felutdata (kopiera det som det är). Den dokumentationen gör nästa prompt specifik och förhindrar "det funkar fortfarande inte"‑loopar.
Håll scope tight. Om lint faller och tester faller, fixa lint först, kör om, och ta sedan testerna. Blanda inte "snabba städningar" med en krasfix i samma pass.
När kontrollerna fallerar, behandla felutdata som din nästa prompt. Den snabbaste loopen är: klistra in felet, få en diagnos, applicera en minimal fix, kör om.
Klistra in fel verbatim, inklusive kommando och full stacktrace. Be först om den mest troliga orsaken, inte en lista med alternativ. Claude Code fungerar bättre när den kan ankra mot exakta radnummer och meddelanden istället för att gissa.
Lägg till en mening om vad du redan försökt så att du inte skickas i cirklar. Upprepa begränsningar som spelar roll ("Rör inte publika API:er", "Behåll nuvarande beteende, fixa bara kraschen"). Be sedan om den minsta patch som får kontrollen att passera.
En bra felprompt innehåller:
Om den föreslagna fixen ändrar beteende, be om ett test som bevisar det nya beteendet. Om en handler nu returnerar 400 istället för 500, begär ett fokuserat test som misslyckas på gammal kod och passerar på fixen. Det håller arbetet ärligt och gör PR:en lättare att lita på.
Stoppa när kontrollerna är gröna och diffen fortfarande känns som en idé. Om modellen börjar förbättra orelaterad kod, re‑prompta med: "Rör bara det felande testet. Ingen städning."
En PR mergas snabbast när det är uppenbart vad som ändrats, varför och hur man bevisar att det fungerar. Med detta arbetsflöde bör PR:en läsa som en kort berättelse: små steg, tydliga skäl.
Håll commits i linje med dina iterationer. Om du bad om en beteendeförändring, gör det i ett commit. Om du sedan fixade ett felande test, gör det i nästa commit. Granskare kan följa vägen och lita på att du inte smugit in extra ändringar.
Skriv commit‑messages för avsikt, inte filnamn. "Fix login redirect when session expires" slår "Update auth middleware." När meddelandet namnger användar‑upplevda resultat lägger granskaren mindre tid på att gissa.
Undvik att blanda refaktorer med beteendeförändringar i samma commit. Om du vill byta namn på variabler eller flytta helpers, gör det separat (eller hoppa över det nu). Brus saktar ner granskningen.
I PR‑beskrivningen, håll det kort och konkret:
Exempel: en billing‑sida kraschar pga. en null kundpost. Commit 1 lägger till en guard och ett tydligt fel‑state. Commit 2 lägger till ett test för null‑fallet. PR‑beskrivningen säger: "Öppna Billing, ladda en kund utan profil, bekräfta att sidan visar det nya tomma tillståndet." Det är den typen av PR som godkänns snabbt.
Denna rytm bryts när scope tyst expanderar. En prompt som börjar som "fixa detta felande test" blir "förbättra felhantering över modulen" och plötsligt granskar du en stor diff med otydlig avsikt. Håll det tätt: ett mål, en ändringsmängd, en uppsättning kontroller.
En annan broms är att acceptera snyggare refaktorer bara för att de ser bra ut. Omdöpningar, filflyttar och stiländringar skapar brus i granskningen och gör det svårare att se verkliga beteendeförändringar.
Vanliga fallgropar:
Ett konkret exempel: ett test misslyckas med "expected 400, got 500." Om du klistrar in bara slutet av stacktracen får du ofta generiska try/catch‑förslag. Om du klistrar in hela testoutputen kan du se den verkliga orsaken: en saknad valideringsgren. Det leder till en liten, fokuserad diff.
Innan du committar, läs diffen som en granskare. Fråga: tjänar varje rad begäran, och kan jag förklara det i en mening? Om inte, återställ extra ändringar och re‑prompta med en smalare begäran.
En användare rapporterar: "Inställningssidan återställs ibland till standard efter att du sparat." Du pullar main, kör tester och ser ett fel. Eller det finns inga tester, bara ett tydligt repro.
Behandla det som en loop: en liten begäran, en liten diff, sedan kontroller.
Först, ge Claude Code minsta användbara kontext: felande testoutput (eller reproduktionssteg), filvägen du misstänker och målet ("behåll beteendet, fixa reseten"). Be om en diagnos och en minimal patch, inte en refaktor.
Sedan jobba i korta loopar:
Kör kontroller efter att du granskat diffen.
Om kontrollerna passerar men du oroar dig för regressioner, lägg till täckning.
Avsluta med en liten PR‑beskrivning: vad buggen var, varför den hände och vad som ändrades. Lägg till en granskningsnotis som "rör endast X‑fil" eller "lade till ett test för reset‑fallet" så att granskningen känns säker.
Precis innan du öppnar en pull request, gör en sista koll så att arbetet är lätt att granska och säkert att mergas.
Ett snabbt exempel: om du fixade en login‑bugg men också reformaterade 20 filer, ångra formateringscommitten. Din granskare ska fokusera på login‑fixen, inte undra vad som flyttats.
Om något misslyckas, gör en sista liten loop: en liten diff, kör kontroller, uppdatera PR‑anteckningar. Den sista loopen sparar ofta timmar av fram‑och‑tillbaka.
Konsekvens förvandlar en bra session till ett tillförlitligt arbetsflöde. Välj en standardloop och kör den samma sätt varje gång. Efter en vecka märker du att dina prompts blir kortare och dina diffar lättare att granska.
En enkel rutin:
En personlig prompt‑mall hjälper dig hålla disciplinen: "Ändra bara vad som behövs. Rör högst 2 filer. Behåll publikt beteende om jag inte säger annat. Säg vilket kommando jag ska köra och vad framgång ser ut som."
Om du bygger inom Koder.ai kan du använda samma loop i chattgränssnittet. Planning‑läge passar bra för att skala in den minsta mergbara skivan (inputs, outputs och acceptanskontroller), och snapshots och rollback hjälper dig återhämta dig snabbt när ett experiment spårar ur.
När ändringen är stabil, exportera källkoden för att köra dina vanliga lokala verktyg, CI och teamgranskning i ditt ordinarie repo. Deploya när du behöver verklig validering, till exempel för att kontrollera ett flöde end‑to‑end.
Gör loopen till standard. Små prompts, små diffar, frekventa kontroller och snabba korrigeringar ger PR:er som är tråkiga på bästa sätt.
Standard: sikta på en liten, granskbar ändring som du kan förklara med en mening.
En bra tumregel är: du ska kunna förutsäga vilka fil(er) som kommer att ändras, och du ska kunna validera det med en snabb kontroll (en riktad test, lint eller ett enkelt körsteg). Om du inte kan det är uppgiften fortfarande för stor—dela upp den i "lägg till repro‑test" och "fixa bugg" som separata loopar.
Ja—börja med en kort plan när målet är oklart.
Använd en enkel grind:
Det här förhindrar att modellen gissar och rör vid fler filer innan ni är överens om tillvägagångssättet.
Inkludera dessa grundläggande delar i din prompt:
Stoppa och minska omfånget om modellen rör fler filer än du bad om.
Praktiska åtgärder:
X‑fil. Inga refaktorer. Ingen irrelevant formatering.”Att försöka "testa sig ur" en spretig diff brukar kosta mer tid än att göra om det i mindre steg.
Läs diffen först, kör sedan kontroller.
En enkel ordning:
Klistra in felet exakt som det är och be om minsta möjliga fix.
Inkludera:
Undvik “det funkar fortfarande inte” utan detaljer—specifik output möjliggör ett precist patchförslag.
Behandla modellen som en snabb skrivande partner, inte en autopilot.
Du är ansvarig för:
En bra vana är att kräva en ren textsammanfattning: vad som ändrats, vad som inte ändrats och varför.
Håll dem separata som standard.
Att blanda refaktorer med beteendeförändringar skapar brus och gör det svårare för granskaren att förstå intenten.
Håll det kort och konkret:
Om din PR läser som “en idé, bevisad av en kontroll” tenderar den att mergas snabbt.
Koder.ai stödjer samma disciplin med några hjälpsamma funktioner:
Använd dessa för att hålla iterationerna små och återställbara, och merga sedan genom er vanliga granskningsprocess.
Denna struktur begränsar naturligt omfånget och gör granskningen snabbare.
Det håller loopen tät och gör fel enklare att tolka.