القائمة
Testdrevet utvikling — test-first, red-green-refactor, bugfiks med reproduksjonstest og ny funksjonalitet med tester først. Brukes via /tdd ved testdrevet arbeidsflyt.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Utforsk designkonsepter visuelt med Aksel-tema i nettleser, og lever som Figma-skisse. Brukes via /prototype når et konsept skal visualiseres.
Klarsprak-skillen veileder klarspråk og språkvask av feilmeldinger, mikrotekst og AI-markører i norsk tekst. Brukes via /klarsprak når brukeren ber om klarspråk, språkvask, AI-markører, feilmeldinger eller mikrotekst.
Feilsøking av runtime-problemer i Nav-miljø — pod crash, OOMKilled, 401/403, auth-feil, Kafka lag, DB-timeout, Flyway-feil, logger og Nais-diagnostikk. Brukes via /nav-troubleshoot ved driftsfeil.
Sikkerhetsgjennomgang for Nav-applikasjoner — PII, FNR, helseopplysninger, secrets, logging, auditlogg, accessPolicy, eksterne integrasjoner, DPIA og sikkerhetschampion. Brukes via /security-review ved sikkerhetsreview.
UU/WCAG-review for Nav-frontend — tastaturflyt, skjermleser, axe, kontrast, fokus, feilmeldinger, skjema og Aksel-bruk. Brukes via /accessibility-review før PR eller release.
Dulting (nudging) i Nav-tjenester — utforsk muligheter, design intervensjoner og prototype med EAST, Fogg og FORGOOD-etikk. Brukes via /dulting ved utforsking av dulting-muligheter eller design av atferdsintervensjoner.
| name | tdd |
| description | Testdrevet utvikling — test-first, red-green-refactor, bugfiks med reproduksjonstest og ny funksjonalitet med tester først. Brukes via /tdd ved testdrevet arbeidsflyt. |
Kjerneprinsipp: Tester verifiserer atferd gjennom offentlige grensesnitt, ikke implementasjonsdetaljer. Koden kan endres totalt — testene skal overleve.
Gode tester tester gjennom offentlige API-er. De beskriver hva systemet gjør. "Bruker kan sende søknad med gyldig skjema" forteller nøyaktig hvilken funksjon som finnes. Disse testene overlever refaktoreringer fordi de ikke bryr seg om intern struktur.
Dårlige tester er koblet til implementasjon. De mocker interne samarbeidspartnere, tester private metoder, eller verifiserer gjennom eksterne mekanismer. Varseltegn: testen feiler ved refaktorering, men atferden er uendret.
IKKE skriv alle tester først, deretter all implementasjon. Det er å behandle RED som "skriv alle tester" og GREEN som "skriv all kode."
FEIL (horisontalt):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
RIKTIG (vertikalt):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
Spør: "Hvilket grensesnitt skal vi eksponere? Hvilke atferder er viktigst å teste?"
Skriv ÉN test som bekrefter ÉN ting om systemet:
RED: Skriv test → feiler
GREEN: Minimal kode for å bestå → bestått
For hver gjenværende atferd:
RED: Neste test → feiler
GREEN: Minimal kode → bestått
Regler:
Etter at alle tester består:
Aldri refaktorer mens RED. Kom til GREEN først.
[ ] Test beskriver atferd, ikke implementasjon
[ ] Test bruker kun offentlig grensesnitt
[ ] Test ville overlevd intern refaktorering
[ ] Kode er minimal for denne testen
[ ] Ingen spekulative funksjoner lagt til