Claude Code för CI-fel: prompts för små fixar + tester

Vad går fel när CI misslyckas och AI gissar

Ett CI-fel är vanligtvis inte mystiskt. Loggen talar om var det slutade, vilket kommando som misslyckades och felmeddelandet. En bra körning innehåller en stack-trace, ett kompilatorfel med fil och radnummer, eller en testrapport som visar vilken assertion som misslyckades. Ibland får du till och med en diff-liknande ledtråd som "expected X, got Y" eller ett tydligt misslyckat steg som "lint", "build" eller "migrate database".

Det verkliga problemet är att människor (och AI) ofta behandlar loggen som bakgrundsbrus. Om du klistrar in en lång logg och ber om "en fix", hoppar många modeller till en bekant förklaring istället för att läsa de sista meningsfulla raderna. Gissningarna blir värre när felet ser vanligt ut ("module not found", "timeout", "permission denied"). Du sitter kvar med en stor omskrivning, ett nytt beroende, eller ett svar som "försök uppdatera allt" som inte matchar det faktiska felet.

Målet är inte "få det att passera på något sätt". Det är enklare:

• Läs den felande utdata.
• Identifiera den minsta ändringen som gör att det misslyckade steget lyckas.
• Behåll allt annat oförändrat.

I praktiken är den "minsta fixen" vanligtvis en av dessa: en kodändring på några rader på ett ställe, en saknad import eller fel sökväg, ett konfigvärde som uppenbart är fel för CI-miljön, eller att återställa en oavsiktlig brytande ändring istället för att redesigna koden.

Ett uppföljande test spelar också roll. Att passera CI en gång är inte samma sak som att förhindra upprepningar. Om felet kom från ett kantfall (null-input, tidszon, avrundning, behörigheter), lägg till ett regressions-test som misslyckas före fixen och passerar efter. Det förvandlar en engångsinsats till ett skydd.

Vad du ska samla innan du ber om hjälp

De flesta dåliga fixar börjar med saknad kontext. Om du bara klistrar in den sista röda raden måste modellen gissa vad som hände tidigare, och gissningar blir ofta omskrivningar.

Sikta på att ge tillräcklig detalj så att någon kan följa felet från det första verkliga felet till slutet, och sedan ändra så lite som möjligt.

Kopiera detta i ditt meddelande (ordagrant när du kan):

• Den fullständiga felande loggen från första felraden till slutet (inte bara den sista stack-tracen).
• Det exakta kommando som CI körde (till exempel go test ./..., npm test, flutter test, golangci-lint run).
• Filvägar som nämns i felet, plus relevant config (testconfig, linter-config, build-skript).
• Vad som ändrats nyligen: PR-diff-sammanfattning, dependency-bumps, CI-config-edits.
• Om det är flakigt: två eller tre misslyckade körningar och en grön om du har dem.

Lägg till begränsningar med vanliga ord. Om du vill ha en liten fix, säg det: inga refaktorer, inga beteendeförändringar om det inte är nödvändigt, håll patchen begränsad till det felande området.

Ett enkelt exempel: CI misslyckas på ett lint-steg efter en dependency-bump. Klistra in lint-utdata från första varningen, inkludera kommandot CI använde, och nämn den enda paketversionsändringen. Det räcker för att föreslå en en-radig konfigjustering eller en liten kodändring, istället för att omformatera halva repot.

Om du vill ha något copy-pastebart är den här strukturen vanligtvis tillräcklig:

CI command:

Failing output (full):

Recent changes:

Constraints (smallest fix, no refactor):

Flaky? (runs attached):

Promptregler som tvingar modellen att läsa felutgången

När en modell missar ett CI-avbrott är det ofta för att din prompt tillåter den att gissa. Din uppgift är att få den att visa sitt arbete med den exakta felutgången, och sedan hålla sig till den minsta ändringen som kan få jobbet att passera.

Regler som håller modellen ärlig

Kräv bevis och en liten plan. En bra prompt tvingar fram fem saker:

• Citera de exakta felraderna från CI-loggen (fel, stacktrace, fil:rad) och säg uttryckligen "Jag använder dessa rader."
• Ge en en-satsig diagnos, utan att skjuta ifrån dig ansvar.
• Föreslå en minimal patch-plan med 1–3 ändringar, och namnge de exakta filer som berörs.
• Undvik orelaterade ändringar (ingen formatering, inga namnbyten, inga refaktorer, inga dependency-bumps) om du inte godkänner det.
• Lista vad modellen är osäker på och den enda detalj som skulle bekräfta den.

Osäkerhet är okej. Dold osäkerhet är det som slösar tid.

Klart-och-kopiera promptfragment

Klistra in detta högst upp i din CI-fråga:

Use ONLY the evidence in the CI output below.
1) Quote the exact failing lines you are using.
2) Give ONE sentence: the most likely cause.
3) Propose the smallest fix: 1-3 edits, with file paths.
4) Do NOT do formatting/renames/refactors or "cleanup".
5) List uncertainties + the one extra detail that would confirm the diagnosis.

Om loggen säger "expected 200, got 500" plus en stacktrace till user_service.go:142, driver den här strukturen svaret mot den funktionen och en liten guard eller felhantering, inte en redesign av endpointen.

En copy-paste-promptmall för CI-fel

De snabbaste vinsterna kommer från en prompt som tvingar fram citat av loggar, håller sig inom begränsningar och slutar när något saknas.

You are helping me fix a CI failure.

Repo context (short):
- Language/framework:
- Test/build command that failed: <PASTE THE EXACT COMMAND>
- CI environment (OS, Node/Go/Python versions, etc.):

Failing output (verbatim, include the first error and 20 lines above it):
<PASTE LOG>

Constraints:
- Propose the smallest possible code change that makes CI pass.
- Do NOT rewrite/refactor unrelated code.
- Do NOT touch files you do not need for the fix.
- If behavior changes, make it explicit and justify why it is correct.

Stop rule (no guessing):
- If the log is incomplete or you need more info (missing stack trace, config, versions, failing test name), STOP and ask only the minimum questions needed.

Your response format (follow exactly):
1) Evidence: Quote the exact log lines that matter.
2) Hypothesis: Explain the most likely cause in 2-4 sentences.
3) Smallest fix: Describe the minimal change and why it addresses the evidence.
4) Patch: Provide a unified diff.
5) Follow-up: Tell me the exact command(s) to rerun locally to confirm.

Then, write ONE regression test (or tweak an existing one) that would fail before this fix and pass after it, to prevent the same failure class.
- Keep the test focused. No broad test suites.
- If a test is not feasible, explain why and propose the next-best guardrail (lint rule, type check, assertion).

Två detaljer som minskar fram-och-tillbaka:

• Inkludera det exakta felande kommandot och det första felet (inte bara den sista sammanfattningen).
• Om det finns flera fel, säg vilket som ska fixas först (vanligtvis det tidigaste verkliga felet i loggen).

Hur du pressar på för den minsta fixen, inte en omskrivning

Det snabbaste sättet att förlora tid är att acceptera en "röjning" som ändrar fem saker samtidigt. Definiera "minimal" i förväg: den minsta diffen som gör att det misslyckade jobbet passerar, med lägst risk och snabbaste verifiering.

En enkel regel fungerar bra: åtgärda symptomet först, avgör senare om en större refaktor är värd det. Om loggen pekar på en fil, en funktion, en saknad import eller ett kantfall, sikta där. Undvik "medan vi är här"-ändringar.

Om du verkligen behöver alternativ, be om två och bara två: "säkraste minsta fix" vs "snabbaste minsta fix." Du vill ha tradeoffs, inte en meny.

Kräv också lokal verifiering som matchar CI. Be om samma kommando som pipelinen kör (eller närmaste motsvarighet), så du kan bekräfta på minuter:

# run the same unit test target CI runs
make test
# or the exact script used in CI
npm test

Om svaret föreslår en stor ändring, ställ tillbaka med: "Visa den minsta patchen som fixar den misslyckade assertionen, utan orelaterad formatering eller namnbyten."

Prompt för ett uppföljande test som förhindrar upprepningar

En fix utan test är ett vad om att du inte träffar samma problem igen. Be alltid om ett uppföljande test som misslyckas före patchen och passerar efter.

Var specifik om vad "bra" är:

• Om felet var ett unit-test-krasch, vill du troligen ett nytt test eller en starkare assertion.
• Om felet var en build-, lint- eller formateringsregel, vill du en check som upprätthåller regeln så samma fel inte smyger tillbaka in.

Ett användbart mönster är att kräva fyra saker: var testet ska ligga, vad det ska heta, vilket beteende det täcker, och en kort notis om varför det förhindrar framtida regressioner.

Kopiera-tillägg:

• Skriv ett regressions-test som misslyckas på aktuellt main-branch och passerar efter din fix.
• Gör det riktat mot samma felklass, inte bara exakt den rad som bröts.
• Lägg testet i: <path or folder>. Följ namngivningskonventionen: <your convention>.
• Om det är en lint/build-regel, lägg till eller justera en check som upprätthåller regeln.
• Lägg till 2–3 meningar: varför detta test skulle fånga ett liknande fel senare.

Exempel: CI visar en panic när en API-handler får ett tomt sträng-ID. Begär inte "ett test för den här raden". Be istället om ett test som täcker ogiltiga ID:n (tomma, bara whitespaces, fel format). Den minsta fixen kan vara en guard clause som returnerar 400. Uppföljningstestet bör assertera beteende för flera ogiltiga inputs, så nästa gång någon refaktorar parsing bryter CI direkt.

Om ditt projekt redan har testkonventioner, skriv dem. Om inte, be modellen spegla närliggande tester i samma paket eller mapp och håll det nytt testet kort och läsbart.

Ett steg-för-steg workflow du kan återanvända

1) Ge det felet som det är

Klistra in CI-loggsektionen som innehåller felet och 20–40 rader ovanför. Klistra även in det exakta felande kommandot CI körde och viktiga miljödetaljer (OS, runtime-versioner, viktiga flaggor).

Be den sedan att återge vad som gick fel på klar svenska och peka på de(ta) rad(er) i utdata som bevisar det. Om den inte kan citera loggen har den inte verkligen läst den.

2) Kräva minsta patchen först

Be om den minsta möjliga kodändringen som får det felande kommandot att passera. Tryck tillbaka mot refaktorer. Innan du applicerar något, låt den lista:

• De filer den tänker röra
• Exakt vilket beteende som kommer att ändras
• Vad den inte ändrar

3) Kör om samma kommando, håll loopen kort

Applicera patchen och kör det exakta felande kommandot lokalt (eller i samma CI-jobb om det är enda alternativet). Om det fortfarande misslyckas, klistra in bara den nya felande utdata och upprepa. Mindre kontext håller svaret fokuserat.

4) Lägg till ett regressions-test för felklassen

När det är grönt, lägg till ett uppföljande test som skulle misslyckas före patchen och nu passerar. Håll det riktat: ett test, ett syfte.

Kör kommandot igen med det nya testet inkluderat för att bekräfta att du inte bara tystade felet.

5) Avsluta med en ren PR-paket

Be om ett kort commit-meddelande och en PR-beskrivning som innehåller vad som felade, vad som ändrades, hur du verifierade det och vilket test som förhindrar återfall. Granskare går snabbare när resonemanget är tydligt.

Ett realistiskt exempel: från felutdata till fix och test

Ett vanligt fel: allt fungerade lokalt, men en liten ändring gör att testerna misslyckas i CI. Här är ett enkelt exempel från en Go-API där en handler började acceptera ett datum utan tid (2026-01-09) men koden fortfarande parser bara fulla RFC3339-tidsstämplar.

Det här är typen av snippet att klistra in (håll det kort, men inkludera felraden):

--- FAIL: TestCreateInvoice_DueDate (0.01s)
    invoice_test.go:48: expected 201, got 400
    invoice_test.go:49: response: {"error":"invalid due_date: parsing time \"2026-01-09\" as \"2006-01-02T15:04:05Z07:00\": cannot parse \"\" as \"T\""}
FAIL
exit status 1
FAIL	app/api	0.243s

Använd sedan en prompt som tvingar fram bevis, en minimal fix och ett test:

You are fixing a CI failure. You MUST use the log to justify every claim.

Context:
- Language: Go
- Failing test: TestCreateInvoice_DueDate
- Log snippet:
<PASTE LOG>

Task:
1) Quote the exact failing line(s) from the log and explain the root cause in 1-2 sentences.
2) Propose the smallest possible code change (one function, one file) to accept both RFC3339 and YYYY-MM-DD.
3) Show the exact patch.
4) Add one regression test that fails before the fix and passes after.
Return your answer with headings: Evidence, Minimal Fix, Patch, Regression Test.

Ett bra svar pekar på mismatch i parsing-layout, och gör en liten ändring i en funktion (t.ex. parseDueDate i invoice.go) för att försöka RFC3339 först och falla tillbaka till 2006-01-02. Ingen refaktor, inga nya paket.

Regressions-testet är skyddet: skicka due_date: "2026-01-09" och förvänta 201. Om någon senare tar bort fallbacken bryter CI direkt med samma felklass.

Vanliga misstag som slösar tid (och hur man undviker dem)

Det snabbaste sättet att förlora en timme är att ge en beskuren bild av problemet. CI-loggar är bullriga, men den användbara delen är ofta 20 rader ovanför slutfelet.

En fälla är att klistra in bara sista röda raden (t.ex. "exit 1") medan den verkliga orsaken tidigare (saknad env-variabel, misslyckat snapshot eller första crashande test) göms. Fix: inkludera det felande kommandot plus loggintervallet där första verkliga felet visas.

En annan tidstjuv är att låta modellen "städa upp" i processen. Extra formatering, dependency-bumps eller refaktorer gör det svårare att granska och lättare att introducera nya fel. Fix: lås scope till minsta möjliga kodändring och avvisa allt orelaterat.

Några mönster att se upp för:

• Klistra in bara sista felraden: inkludera felande kommando och första fel.
• Låt den ändra dependencies eller orelaterade filer: kräva en minimal diff och en motivering för varje fil som berörs.
• Acceptera en fix som inte verifierats mot CI-kommandot: kör samma kommando och bekräfta.
• Skriva ett test som fortfarande passerar när buggen återkommer: kräva ett test som misslyckas på gammal kod och passerar på fixen.
• Blanda flakiga tester med verkliga regressioner: avgör om det är icke-deterministiskt (timing, nätverk, ordning) eller stabil logik, och hantera därefter.

Om du misstänker flakighet, linda inte över det med retries. Ta bort slumpen (fixerad tid, seedad RNG, isolerade temp-kataloger) så signalen blir tydlig.

Snabba kontroller innan du pushar fixen

Innan du pushar, gör en kort sanity-check. Målet är att säkerställa att ändringen är riktig, minimal och repeterbar, inte ett lyckokast.

• Bevis: citerar förklaringen de exakta felraderna?
• Omfattning: är ändringarna begränsade till vad som behövs?
• Orsakssamband: förklarar den varför ändringen vänder ett misslyckande till en passering?
• Repro: körde du samma CI-kommando (samma flaggor, samma arbetskatalog)?
• Regression: misslyckades det nya testet före fixen och passerar efter?

Slutligen, kör en något bredare uppsättning än det enda felande jobbet (t.ex. lint plus unit-tests). En vanlig fälla är en fix som passerar ursprungsjobbet men bryter ett annat mål.

Nästa steg: gör detta till en vana

Om du vill att detta sparar tid vecka efter vecka, behandla din prompt och svarstruktur som teamprocess. Målet är repeterbara inputs, repeterbara outputs och färre "mystery fixes" som bryter något annat.

Gör din bästa prompt till ett delat snippet i teamet. När alla använder samma format går recensioner snabbare eftersom granskare vet var de ska titta.

En lättvikts-loop som funkar i de flesta team:

• Spara prompten som ett rep-snippet och fäst den i teamchatten.
• Märk CI-fel efter typ (lint, unit, integration, packaging, deploy).
• När en label upprepas, lägg till ett test eller en check som skulle ha fångat det tidigare.
• Håll riskfyllda experiment reversibla så du snabbt kan backa ut.

Om du föredrar en chat-först-workflow för att bygga och iterera på appar, kan du köra samma fix-och-test-loop i Koder.ai, använda snapshots medan du experimenterar, och exportera koden när du är redo att slå ihop tillbaka till ditt vanliga repo.