| name | team-kontekst |
| description | Team-esyfos autoritative oppsett for @doctor-who — tavlestruktur (navikt/157), arbeidsrytme, mål/drift, issue-hierarki, apper teamet eier, kode-oppslag på tvers av repoer, domeneordbok, AID-oppdraget og dokumentasjonskonvensjoner. Lastes ved oppstart av status-, prioriterings-, mål-, discovery- og dokumentasjonsarbeid. |
Team-kontekst — esyfo
Den autoritative inngangen til team-esyfos oppsett for @doctor-who. Agenten
leser denne ved oppstart, slik at den slipper å spørre om tavle, rytme, mål og apper.
Prinsipp: pek på teamets ekte kilder, ikke kopier dem. Wikien er kilden til
sannhet for fag/apper/ordbok; tavla er kilden til sannhet for oppgaver, mål
og status. Denne fila beskriver strukturen og semantikken så agenten vet hvor
den skal hente det den trenger — og leser alltid de volatile verdiene live.
Team eSyfo eier den eksterne sykefraværsoppfølgingen i Nav.
Wiki: https://navikt.github.io/team-esyfo/
Tavle (GitHub Projects navikt/157)
Teamets eneste tavle. Alle issues fra repoets maler legges automatisk på den
(projects: ["navikt/157"]). Tavla er kilden til sannhet for oppgaver, mål,
prioritering og status — ikke wikien.
Hvordan lese den: felter, opsjoner og ID-er er volatile og hentes alltid
dynamisk ved kjøring. Bruk team-status-skillen → references/projects-v2.md
hvis den er synket inn (kommer via product-collectionen), ellers direkte:
gh project view 157 --owner navikt --format json
gh project field-list 157 --owner navikt --format json
gh project item-list 157 --owner navikt --format json --limit 200
Aldri hardkod felt-/opsjon-ID-er. Strukturen under er kart, ikke fasit —
verifiser navn live, de endres når noen omdøper en kolonne.
Faner (views) — hva de er til
| Fane | Layout | Brukes til |
|---|
| Mine oppgaver | tabell | Personlig arbeidsliste (filtrert på assignee) |
| Alle oppgaver | tabell | Full backlog på tvers av repoer |
| Ukas prioriteringer | board | Ukentlig planlegging — det teamet jobber med denne uka |
| T1 - 2026 / T2 - 2026 | tabell | Tertialvisning — arbeid gruppert per tertial |
| Til vurdering | tabell | Ufordelte/uavklarte ting som må triages |
| Done | tabell | Ferdig arbeid |
| AID-oppgaver | roadmap | Tidslinje for AID-oppdraget |
Felter — hva de betyr
- Status:
Backlog, Monday epics 🎯, Plukk meg! 🙌, Jeg jobbes med! ⚒️,
Til diskusjon, AID-oppdraget, Done. Flyten er typisk Backlog →
Monday epics (ukentlig planlegging mandag) → Plukk meg! → Jeg jobbes med! → Done.
- Priority:
P0, P1, P2.
- Size:
XS, S, M, L, XL (grov estimering).
- Tertial:
T1 - 2026, T2 - 2026, T3 - 2026 — knytter arbeid til tertialet.
- Måleparameter: teamets tertialmål / key results ligger her som
single-select-opsjoner (ikke i et eget måldokument). Les opsjonene live for å
se gjeldende mål — de er tertial-spesifikke og endres. Drift/vedlikehold kan
være representert både som en Måleparameter og via
BAU-taggen.
- Tags:
Etterlevelse, BAU (= business as usual / drift), Bug,
Dataretting, AID, Sommerferie.
- Start date / End date / Estimate: planlegging.
- Parent issue / Sub-issues progress: epic → deloppgave-hierarkiet.
Arbeidsrytme
- Ukentlig innenfor tertial: teamet planlegger per uke (
Monday epics 🎯
- fanen
Ukas prioriteringer), og grupperer arbeid i tertialer via
Tertial-feltet (T1/T2/T3 - 2026).
- Mål formaliseres som
Måleparameter-opsjoner på tavla per tertial — bruk
disse som rammen for prioriterings- og statusarbeid.
- Drift/forvaltning skilles med
BAU-tag og er en uttalt målsetting (kapasitet
til vedlikehold). Når du gjør OKR-/målarbeid: behandle drift som legitim
prioritering her, ikke som noe som holdes utenfor.
Issue-typer og hierarki
Maler i .github/ISSUE_TEMPLATE/ (alle auto-knyttet til navikt/157):
- Epic — stor oppgave (Mål, Bakgrunn, Omfang, Deloppgaver) som brytes ned.
- Story — brukerrettet leveranse.
- Task — teknisk oppgave/vedlikehold/chore (Beskrivelse, Bakgrunn, Akseptansekriterier).
- Feature — ny funksjonalitet.
- Bug — feil.
Epics samler deloppgaver via Parent/Sub-issues. Bruk issue-management- og
pull-request-skills for selve opprettelsen og PR-kobling.
Apper teamet eier
Autoritativ liste gruppert etter type, med forretningsbeskrivelse per repo:
docs/utvikling/repositories.md
(https://navikt.github.io/team-esyfo/utvikling/repositories).
Les den fila for å finne riktig repo — aldri gjett på hvilke apper teamet eier.
Lese ekte kode fra app-repoer (read-only)
@doctor-who kjører i team-esyfo-arbeidskopien, men kan svare på spørsmål som
gjelder en konkret app (f.eks. «hva bør vi gjøre i oppfølgingsplan?») ved å hente
ekte kode read-only fra søsken-repoer via gh (bruker din innlogging).
Default — kun lesing (gh api GET / gh search code):
gh search code --repo navikt/syfo-oppfolgingsplan-backend "BehovForOppfolging"
gh api repos/navikt/syfo-oppfolgingsplan-backend/contents/README.md \
--jq '.content' | base64 -d
Bruk gh api kun til GET (lesing) og gh search code (alltid read-only).
gh api er en generell REST-klient — aldri -X POST/PUT/PATCH/DELETE eller
request-body mot en annen app; det ville endre remote og bryte sideeffekt-løftet.
Siste utvei — midlertidig klon (spør først): trengs det bred kode-kontekst
som gh api GET ikke dekker, spør brukeren, klon til en unik temp-mappe og rydd
opp uansett utfall (trap):
dir=$(mktemp -d); trap 'rm -rf "$dir"' EXIT
gh repo clone navikt/syfo-oppfolgingsplan-backend "$dir" -- --depth 1
Slå opp riktig repo-navn i repositories.md først (oppfølgingsplan finnes i flere
repoer: syfo-oppfolgingsplan-frontend/-backend er de nye, oppfolgingsplan-*
og syfooppfolgingsplanservice er eldre/under utfasing).
Grenser: kun lesing fra andre repoer — gh api GET / gh search code.
Klon kun som siste utvei, etter avklaring, til egen temp-mappe som ryddes opp.
Aldri skrive-verb (gh api -X POST/…), git push, PR eller commit mot en
annen app fra team-esyfo-kontekst — foreslå heller at arbeidet flyttes dit.
Dokumentasjon — hvor og hva
Repoet er en VitePress-wiki (docs/). Legg dokumentasjon der den hører hjemme:
| Hva | Hvor |
|---|
| Nytt fagområde i sykefraværsforløpet | docs/omrader/<id>/ — bruk /doc-new-area-skillen (scaffolder side + registrerer i areas.ts) |
| Teknisk praksis / backend / frontend | docs/utvikling/ |
| Verktøy og oppsett | docs/verktoy/ |
| Dataanalyse / design | docs/dataanalyse/, docs/design/ |
| Domenebegrep | docs/ordbok.md |
| App-/repo-oversikt | docs/utvikling/repositories.md |
For dokumentasjonsarbeid: bruk /doc-new-area (nytt område), /readme-update
(repo-dok), /klarsprak (språkvask) og /create-a-skill (ny skill). Endringer i
wikien skjer via PR — spør først før du oppretter PR.
Områdeinndeling
Sykefraværsforløpet er delt i flere områder (aktivitetskrav, oppfølgingsplan,
møtebehov, …) — se docs/omrader/index.md
(https://navikt.github.io/team-esyfo/omrader/) for gjeldende liste. Bruk
områdene som ramme når status og prioritering skal knyttes til forløpet.
Et område har typisk en index.md (brukerreisen — hvem utløser hva, fase,
formål) og ofte en teknisk.md (teknisk dybde — systemer, repoer,
Kafka-topics). Ikke alle har teknisk.md, og noen har mer (f.eks.
oppfolgingsplan/ har også dataanalyse.md og dataretting.md) — sjekk hva som
ligger i områdemappa. Les den relevante undersiden før du svarer på
områdespørsmål; det er ofte raskere og mer presist enn å lese kode.
AID-oppdraget (dulting)
AID (Arbeids- og inkluderingsdepartementet) har gitt team eSyfo i oppdrag å
utforske dulting (nudging) for å øke etterlevelsen av regelverket. Første
leveranse er Tiltakspakke 1 for oppfølgingsplan: flere endringer som
A/B-testes mot en kontrollgruppe, randomisert på underenhet, med pilot i Troms
og Finnmark. Alt shippes kontinuerlig, men er skrudd av i prod og på i
dev/lokal.
Kilde til sannhet: wikien under docs/aid/
(https://navikt.github.io/team-esyfo/aid/) — index (oppdrag, mål,
spilleregler, A/B-design), endringer (funksjonelle endringer med status og
spor til tavla), dulte-tiltak (nudgelab-registeret) og maaling. Les den før
du svarer på AID-spørsmål.
Begrepsmodell (viktig): tiltakspakke → dulte-tiltak (nudgelab) → funksjonelle endringer (våre) → issues. Reserver «tiltak» for nudgelab sine
dulte-tiltak — teamets eget nivå heter funksjonelle endringer.
På tavla: AID-arbeid tagges Tag = AID, og AID-fanen er
programoversikten (ingen topp-epic — wiki + fane er oversikten). Nye AID-issues
får Tag = AID, og endringer-siden lenker hver endring til sporet (epic/issue).
Sentrale apper: flaggskipet (A/B-motoren — avgjør tiltaks- vs
kontrollgruppe per underenhet), syfo-oppfolgingsplan-frontend/-backend,
dinesykmeldte(-backend) og esyfovarsel. Slå opp i
docs/utvikling/repositories.md for detaljer.
Wiki som kunnskapsbase
docs/-wikien er teamets samlede kunnskap, ikke bare filene som er lenket over.
Søk i den først (f.eks. grep -ri "<begrep>" docs/) når du svarer på
teamspesifikke spørsmål, og siter den relevante siden. I tillegg til kildene over
finnes blant annet docs/kom-i-gang.md (onboarding, tilganger, viktigste apper)
og docs/utvikling/ (backend/frontend bygg-kjør-linting-testing,
beste-praksis/pull-request.md). Oppdager du at wikien er utdatert eller mangler
noe: foreslå en oppdatering (PR — spør først).
Domeneordbok og akronymer
Domenebegreper (39-ukersvarsel, aktivitetskrav, dialogmøte, LPS, …) er forklart
i docs/ordbok.md (https://navikt.github.io/team-esyfo/ordbok). Slå opp
der før du bruker et begrep — gjett aldri på hva et akronym betyr.
Rapportkadens
Ikke fastsatt i denne fila ennå. Spør brukeren om teamets rapportrytme
(ukesoversikt / tertialstatus) én gang, og foreslå å legge svaret inn her.
Slik bruker agenten denne
- Ved oppstart av status-, prioriterings-, mål-, discovery- eller
dokumentasjonsarbeid: bruk denne som inngang, og les de lenkede kildene ved behov.
- Tavlas felter/opsjoner (inkl. Måleparameter = mål) hentes dynamisk fra
Projects v2 — aldri hardkodet.
- Teamspesifikke spørsmål (område, app, praksis): søk i
docs/-wikien først
(grep -ri / les relevant teknisk.md), deretter app-kode ved behov.
- App-kode hentes read-only via
gh api/gh search code når et spørsmål
gjelder en konkret app; klon kun som siste utvei etter avklaring.
- Mangler et felt her (tavle-guide, kadens): spør brukeren én gang, og
foreslå å legge svaret inn i riktig kilde (PR — spør først).
Grenser
✅ Alltid
- Behandle wikien som kilden for fag/apper/ordbok og tavla som kilden for
oppgaver/mål/status; denne fila er kart, ikke kopi
- Søk i
docs/-wikien (inkl. per-område teknisk.md) før du svarer på
teamspesifikke spørsmål — wikien er teamets samlede kunnskap
- Les tavlas felter/opsjoner dynamisk — aldri hardkod felt-/opsjon-ID-er
- Slå opp domenebegreper i ordboka
- Hent kode fra andre repoer read-only —
gh api/gh search code som default
⚠️ Spør først
- Oppdatere denne fila eller wiki-dokumenter (via PR)
- Opprette issues eller endre tavle-felter
- Klone et annet repo lokalt (siste utvei; bruk egen temp-mappe og rydd opp)
🚫 Aldri
- Duplisere app-lista, ordboka eller områdene hit — pek på kilden
- Hardkode tavlas feltstruktur (ID-er, opsjon-ID-er, verbose måleparameter-tekster)
- Skrive mot en annen app fra team-esyfo-kontekst —
gh api -X POST/…, push,
PR eller commit. Kun lesing (gh api GET / gh search code)
- Gjette på domeneakronymer som står i ordboka — slå opp i stedet
