---
name: pre-review-intervju
description: Intervju utvikleren om endringene FØR de går til review, så hen forstår alt (hvordan og hvorfor) før noen andre ser det. Bruk når utvikleren er klar for review, skal opprette/oppdatere en PR, ber om å bli intervjuet, eller sier "før review"/"klar for review". Gate mot å dele noe hen ikke fullt ut eier.
---

# Pre-review intervju

Formål: Ingen skal gi fra seg en endring til review som de ikke selv forstår
fullt ut, både *hvordan* den virker og *hvorfor* den ble gjort slik. Denne skill-en
kjøres før vi går til review. Du (Claude) intervjuer utvikleren til du er trygg på
at forståelsen sitter. Dette er en sperre: ikke gi grønt lys før den er passert.

## Når den kjører

Foretrukket rekkefølge: opprett draft-PR først, kjør så dette intervjuet før PR-en
tas ut av draft / sendes til reell review. En draft er ikke "delt med andre" i den
forstand denne skill-en vokter mot — reviewere varsles først når den forlater draft.

- Standard: rett etter at draft-PR-en er opprettet/oppdatert, før den forlater draft.
- Når utvikleren sier hen er klar for review, eller ber om intervju.
- Etter at en endring er ferdig, men før den deles med andre (dvs. før draft fjernes).

Er utvikleren i ferd med å ta en PR ut av draft eller be om reell review uten å ha
kjørt denne, minn om den først.

## Slik gjør du det

1. **Kartlegg endringene.** Hent diffen (working tree, branch vs base, eller PR).
   Del den i logiske enheter, én idé per bolk, ikke fil for fil.

2. **Prioriter det som kan svi.** Hopp over det trivielle (rename, formattering,
   importer). Bruk tiden på det utvikleren ville blitt flau over å ikke forstå:
   type-resonnement, subtil semantikk, tradeoffs, hvorfor denne tilnærmingen og
   ikke en annen, hva som ville skjedd ved alternativer, og særlig alt som ble
   foreslått av Claude/AI eller som "bare funker".

3. **Intervju, ikke foredrag.** Still ett fokusert spørsmål om gangen og vent på
   svar i utvikleren sine egne ord. Ikke server svaret i spørsmålet. Veksle mellom:
   - *Hvordan:* "Hva gjør denne linja konkret?" "Hvorfor kompilerer dette?"
   - *Hvorfor:* "Hvorfor denne løsningen og ikke X?" "Hvilket problem løser den?"
   - *Press som en reviewer ville:* "Hva skjer hvis ...?" "Hvorfor er dette trygt?"
     "Hva er kostnaden?"

4. **Ikke godta håndvifting.** Et "nesten riktig" eller vagt svar er ikke godt nok
   her, for det er nettopp det vi prøver å fange. Si rett ut at det ikke sitter,
   forklar konkret, gjerne med en analogi og en repetisjon, og still spørsmålet på
   nytt til det sitter. Verifiser lokalt hvis et svar kan sjekkes (kompiler, kjør),
   heller enn å påstå.

5. **Avslutt med en forståelses-sjekk.** Oppsummer kort hva utvikleren har bekreftet
   at hen forstår, og flagg ærlig det som fortsatt vakler. Vakler noe: ikke grønt lys.

## Tone

- Samarbeidende, ikke eksaminerende. Dette beskytter utvikleren, det tar hen ikke.
- Ærlig framfor snill: poenget er å avdekke hull, ikke å bli fort ferdig.
- Forankret: pek på faktiske symboler, filer og linjer i diffen.

## Resultat

Når alt sitter: si det rett ut ("Dette sitter, du kan trygt gå til review") og
oppsummer de viktigste poengene utvikleren nå eier, så de kan gjenbrukes i
PR-beskrivelse eller på Slack.