Slik fikk vi et CMS på en time — med de ekte promptene

Vi trengte et redigeringsverktøy for artiklene, ikke WordPress. Her er samtalen som endte i Sveltia CMS, de to filene det ble, og skjermbildeverktøyet vi lagde for å dokumentere det.

Artiklene på denne sida er markdown-filer i en mappe. Det er bra for oss som skriver i terminalen. Det er ubrukelig for den som skal rette en skrivefeil fra en telefon, eller for den neste som skal skrive her uten å ha lært Git.

Så vi trengte et CMS. Spørsmålet ble stilt akkurat slik det står under, midt i en annen jobb.

Prompten

«utlimately we need a CMS of some kind. can we look into that, what is the best system?» — Eivind, til boten, 2026-09-02

Legg merke til hva som ikke står der. Ingen kravliste. Ingen kandidater. Skrivefeil. Det er sånn de fleste ekte prompter ser ut, og det er greit — hvis den som svarer vet hvor den skal lete først.

Hva boten gjorde før den svarte

Den søkte ikke på nettet. Den så i mappene våre.

• Fire av søstersidene våre kjører Decap CMS. Én kjører Sveltia CMS.
• Det ligger allerede en liten Cloudflare Worker i et av prosjektene som gir Sveltia innlogging via GitHub.
• Denne sida har et fast skjema for hver artikkel: tittel, beskrivelse, slug, status, kategori, bilde, dom og sutra. Det står i én fil.

Med de tre funnene var svaret gitt. Det beste systemet var det vi allerede vedlikeholdt. Mappene er beskrevet i Claude Code-oppsettet vårt, så den visste hvor den skulle se.

Hvorfor Sveltia, kort

Sveltia leser samme konfigurasjonsfil som Decap. Det er én skriptfil som lastes i nettleseren, ingen server, ingen database. Den skriver rett til Git-repoet, så hver endring blir en commit med navn på, og sida bygges på nytt av seg selv.

To ting avgjorde: den har en «lokal»-modus der du redigerer filene på din egen maskin uten innlogging, og innloggingen for andre går gjennom Workeren vi allerede har. Ingen ny konto, ingen ny regning.

Det vi ikke valgte, og hvorfor:

• WordPress. Vi har skrevet hvorfor. Database, plugins og et innloggingsskjema roboter hamrer på.
• Payload, Strapi og andre med egen server. Da har vi to systemer å holde i live. Innholdet skal bo i Git, ikke i en database ved siden av.
• Keystatic, Tina og andre som bygges inn i rammeverket. Gode, men de ville lagt React inn i en side som med vilje ikke har noe rammeverk.

Bygget: to filer

Hele CMS-et er to filer i mappa public/admin. Den ene laster Sveltia. Den andre beskriver innholdet.

Konfigurasjonen er en speiling av skjemaet artiklene allerede har. Hvert felt fikk en norsk etikett og et hint som sier hva vi mener med det: at tittelen skal ha søkeordet først, at dommen skal være i første person, at sitater skal stå ordrett med dato. Reglene fra stemme-kontrakten flyttet inn i skjemaet, der den som skriver faktisk ser dem.

Boten satte roboten vår som logo uten å bli bedt om det. Det var det ene pyntegrepet vi lot stå.

Det som gjensto

Per 2. september 2026 gjensto tre ting, og ingen av dem kan gjøres fra terminalen:

• Workeren som gir innlogging må få botbedring.no på lista over tillatte adresser. Det gjøres i Cloudflare, ikke i koden.
• Den lokale modusen krever Chrome eller Edge, fordi den bruker nettleserens tilgang til filsystemet. Safari kan ikke.
• Første ekte test: å publisere denne artikkelen gjennom CMS-et, ikke gjennom terminalen.

Det samme til kundene

Vi lager nettsider for andre også, og de skal kunne rette sin egen åpningstid uten å ringe oss — så dette er malen, ikke et oppsett for én side.

Skjermbildene: et verktøy til

Mens vi bygde, kom neste prompt:

«and then make this CMS project into an article as well, to show how we are prompting to get the perfect custom system, along screen shots of the progress. can you help make this kind of automatic screenshot generation tool?» — Eivind, 2026-09-02

Og et kvarter senere:

«actually that could be an app, a small button in the menu bar, that just captures screenshots of your development.» — Eivind, 2026-09-02

Det ble to verktøy, fordi det er to jobber.

Ett skript for sider. Et lite Node-skript som tar en liste med adresser og lagrer et skjermbilde av hver, i full høyde, med to gangers tetthet. Skjermbildet av innloggingen over er tatt slik. Skriptet er 24 linjer og ligger i repoet.

Én knapp for alt annet. En liten app i menylinja på Macen. Ett trykk tar skjermbilde av hele skjermen og legger det i dagens mappe under prosjektet du har valgt. Et trykk til lar deg skrive et notat, og notatet havner i filnavnet og i en logg. Slår du på auto, tar den ett bilde hvert femte minutt så lenge du jobber. Den heter Skjermdump, er skrevet i Swift på en ettermiddag, og har ingen andre funksjoner.

Poenget med begge er det samme som med bygg-loggen: når vi skal skrive om hvordan noe ble laget, skal bildene finnes allerede. Ingen rekonstruksjon etterpå.

Slik bruker du dette i praksis

1. Skriv ned hvilke felt hver tekst har før du velger system. Har du ikke et skjema, har du ikke innhold ennå, bare filer.
2. Sjekk hva du allerede kjører andre steder. Ett system å vedlikeholde slår to.
3. Velg noe som skriver til Git. Da har du historikk, angre og backup uten å tenke på det.
4. Legg hintene fra stilguiden inn i feltene. Den som skriver leser skjemaet, ikke guiden.
5. Test med én ekte rettelse før du sier at det virker.
6. Ta skjermbilder mens du bygger, ikke etterpå. Sett dem på timer om du må.

Det beste systemet er sjelden det beste systemet. Det er det du allerede vedlikeholder.