Menu
Run a self-review loop on the current PR — iterates review/fix/commit cycles until clean
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
NAV-spesifikk PR med Jira-nummer krav og norsk format. Triggers: "/nav-pr", "/nav-create-pr", "lag pr", "opprett pr" Use when: Creating PRs with NAV conventions (Jira prefix required, Norwegian, Jira links).
Build and push multi-platform Docker images to Google Artifact Registry. Use when user asks to build, push, or deploy a Docker image with a tag. Triggers: "build and push", "push docker image", "build with tag", "deploy image".
Add new SED types, BUC types, and XSD validation to the melosys-mock RINA/EUX implementation. Use this skill whenever working with the RINA mock — adding SED support (A001-A012, X001-X008), updating BUC-to-SED mappings, adding XSD schemas, debugging mock endpoint issues, or understanding the mock architecture for EESSI integration. Also use when working in melosys-e2e-tests and you need to extend what the mock supports for a new test scenario. Triggers: "legg til SED", "ny SED-type", "mock SED", "eux-rina-mock", "RINA mock", "add SED to mock", "BUC type", "XSD for SED", "mock endepunkt", "mock støtter ikke", "trenger mock for", "utvide mock"
Expert knowledge of NAV SED to RINA SED mapping in eux-rina-api (CDM 4.4). Use when: (1) Creating or modifying SED mappers in melosys-eessi, (2) Mocking eux-rina-api responses for e2e or local testing, (3) Understanding the RINA template JSON structure and $nav/$medlemskap prefixes, (4) Debugging SED mapping issues between NAV format and EESSI format, (5) Understanding which fields map to which RINA paths for specific SED types (A001-A012, X001-X008), (6) Adding new fields during CDM version upgrades (e.g., CDM 4.3 → 4.4), (7) Understanding kodeverk/code mappings for enums and radio buttons, (8) Troubleshooting PDF generation for SEDs.
Generate OAuth tokens and call local Melosys services (melosys-api, melosys-eessi, eux-rina-api, melosys-mock). Use when debugging API calls, testing endpoints, or needing authentication tokens for local development.
Debug SED flows across melosys-eessi → eux-rina-api → RINA mock. Use when: (1) XSD validation errors from RINA or melosys-mock, (2) Tracing missing/wrong NAV SED fields to RINA format, (3) Figuring out what NAV SED JSON is needed for CDM 4.4 (A008), (4) Improving mock XSD validator to show actionable errors, (5) Debugging send-SED flow end-to-end, (6) JSON-to-XML conversion and element ordering in mock, (7) Understanding eux-rina-api template mappings. Triggers: "XSD validation", "SED feil", "mapping error", "missing field", "element order", "RINA validation", "NAV SED", "CDM 4.4", "A008", "trace SED"
| name | review-loop |
| description | Run a self-review loop on the current PR — iterates review/fix/commit cycles until clean |
| disable-model-invocation | true |
Start en selvreview-loop for den åpne PR-en på nåværende branch.
gh pr list --head $(git branch --show-current) --json number,title,url,body --jq '.[0]'
Hvis ingen PR finnes, si ifra og stopp.
Kjør denne syklusen:
runde = 1
LOOP:
1. Kjør /review og sjekk for feil og mangler og at dokumentasjon er oppdatert, følg så Steg 2 derfra
(spawn subagent med prompten definert der).
VIKTIG: ALDRI inkluder kontekst om hvilken runde det er,
hva som ble fikset forrige gang, eller andre hint.
Subagenten skal ha helt ren kontekst hver gang.
2. Subagent returnerer funn (eller "GODKJENT")
3. Hvis GODKJENT → gå til Steg 3
4. For HVERT funn — VURDER KRITISK:
a. Høy: Bugs, sikkerhetshull, manglende auth, feil logikk → FIKS
b. Middels: Manglende error handling, dårlig navngiving, ubrukt kode → FIKS som regel
c. Lav: Stilpreferanser, "nice to have", kosmetiske ting → IGNORER som regel
d. Ting du IKKE skal fikse:
- Forslag om å legge til kommentarer/docstrings du ikke endret
- Forslag om å refaktorere kode utenfor PR-ens scope
- Rene smakssaker uten faktisk forbedring
- Ting som krever arkitekturendringer
5. Hvis du fikset noe:
a. Kjør relevant build/test (npm run build, pytest, etc.)
b. Commit + push
c. runde += 1
d. GÅ TIL 1 — ny review er PÅKREVD etter endringer
6. Hvis du vurderte alle funn og ingen var verdt å fikse → gå til Steg 3
7. Hvis runde > 5: STOPP og informer brukeren
Si ifra til brukeren:
Review-loop ferdig for PR #{NR}.
- Runder: {runde}
- Funn fikset: {antall}
- Status: Godkjent / Stoppet etter 5 runder
- Link: {PR-URL}