42 prompts att kopiera

Skapa en enkel, snygg webbsida om mig och mitt arbete. Jag heter [NAMN] och jobbar som [ROLL] med [OMRÅDE]. Sidan ska ha en rubrik, en kort presentation och en sektion med tre saker jag är bra på. Använd bara HTML och CSS i en enda fil så att det blir så enkelt som möjligt. Förklara kort vad du gjort när du är klar.

Starta det här projektet så att jag kan se det i min webbläsare. Säg exakt vilken adress jag ska öppna. Om något behöver installeras först, förklara vad och varför innan du gör det.

Jag vill bygga en webbapp men har inte formulerat kraven än. Intervjua mig, en fråga i taget, som en erfaren produktägare skulle göra: vilket problem det löser, vem som använder den, det viktigaste flödet, vad som inte ska ingå i första versionen och hur jag vet att den är klar. Ställ max 8 frågor. Bygg ingenting än.

Läs CLAUDE.md och gör en plan för första versionen. Dela upp arbetet i små steg där varje steg ger något jag kan testa i webbläsaren. Föreslå teknikval (helst Next.js, och Supabase om vi behöver databas) och motivera kort. Skriv planen som en numrerad lista. Bygg ingenting förrän jag godkänt planen.

Sammanfatta det vi pratat om i en fil som heter CLAUDE.md i projektets rot. Den ska innehålla: Syfte (2–3 meningar), Användare, Kärnflöde (steg för steg), Avgränsningar (vad som inte ingår), Teknikval, Arbetsregler (svara på svenska, små steg, fråga innan nya bibliotek installeras, lägg aldrig hemligheter i koden) och Status. Håll den kort och skriv så att en ny kollega förstår.

Uppdatera CLAUDE.md så att den speglar läget nu: vad som är klart, vad som är nästa steg och eventuella beslut vi tagit längs vägen (och varför). Ta bort sådant som inte längre stämmer.

Sätt upp ett nytt Next.js-projekt i den här mappen enligt planen i CLAUDE.md. Använd App Router och JavaScript (inte TypeScript) om inget annat sagts. Håll strukturen så enkel som möjligt, starta utvecklingsservern och berätta vilken adress jag ska öppna.

Ge appen ett lugnt och professionellt utseende som passar en arbetsplats: mycket luft, en tydlig typografisk hierarki, en accentfärg plus gråskala och diskreta skuggor. Den ska fungera lika bra på mobil som på dator. Ändra inte funktionaliteten, bara utseendet.

Jag vill att [VY/SIDA] ska kännas ungefär som [REFERENS, t.ex. Trellos tavla / Notions listor / Linears ärenden]. Beskriv först kort vilka 3–4 egenskaper du tar med dig från referensen, och gör sedan ändringen.

Här är en skärmdump/skiss av hur jag vill att sidan ska se ut ungefär. Bygg om [SIDA] så att den följer layouten, men använd appens befintliga färger och komponenter. Säg till om något i bilden är oklart.

Gå igenom alla sidor och se till att de fungerar bra på en mobilskärm (ca 375 px bred): inget ska hamna utanför skärmen, knappar ska vara lätta att träffa med tummen och tabeller ska gå att läsa. Lista vad du ändrat.

Lägg till tydliga lägen för: tom lista (med en uppmaning om vad användaren kan göra), laddning, lyckad sparning och fel. Texterna ska vara på enkel svenska och säga vad användaren kan göra härnäst.

Granska appen för grundläggande tillgänglighet: färgkontrast, att allt går att använda med tangentbord, att formulärfält har etiketter och att bilder har alternativtext. Rätta det som är enkelt och lista resten.

Läs CLAUDE.md och föreslå vilka tabeller och fält appen behöver i en Supabase-databas. Visa förslaget som en enkel tabell per databastabell (fältnamn, typ, beskrivning) och förklara relationerna med vanliga ord. Håll det så enkelt som möjligt för första versionen. Bygg ingenting än.

Koppla appen till Supabase enligt datamodellen vi kom överens om. 1) Ge mig SQL-koden att klistra in i Supabase SQL Editor för att skapa tabellerna, med Row Level Security påslaget. 2) Installera Supabase-klienten och läs adress och publik nyckel från miljövariabler i .env.local. 3) Skapa en .env.example utan riktiga värden. 4) Kontrollera att .env.local finns i .gitignore. 5) Byt ut nuvarande lagring mot databasen. Använd aldrig den hemliga service_role-nyckeln. Berätta exakt var i Supabase jag hittar värdena jag behöver.

Skapa 10 realistiska men påhittade exempelposter för appen, som SQL jag kan köra i Supabase SQL Editor. Använd inga riktiga namn på personer eller företag.

Lägg till sökning och filtrering i listan över [OBJEKT]: fritextsök på [FÄLT] och filter på [FÄLT, t.ex. status/ansvarig]. Filtren ska synas i adressfältet så att man kan dela en filtrerad vy som länk.

Lägg till en knapp som exporterar den aktuella (filtrerade) listan till en CSV-fil som öppnas korrekt i Excel med svenska tecken (å, ä, ö).

Jag vill lägga till [FÄLT/TABELL]. Ge mig SQL för ändringen som inte förstör befintlig data, uppdatera koden som använder tabellen och påminn mig om eventuella RLS-regler som behöver uppdateras.

Det här fungerar inte: [BESKRIV VAD DU GJORDE, VAD DU FÖRVÄNTADE DIG OCH VAD SOM HÄNDE]. Här är felmeddelandet: [KLISTRA IN]. Ta reda på grundorsaken innan du ändrar något. Förklara orsaken med vanliga ord, föreslå en lösning och genomför den sedan.

Förklara hur [DEL AV APPEN] fungerar, som om jag saknade programmeringsbakgrund. Vilka filer är inblandade, och vad händer steg för steg när en användare [HANDLING]?

Stanna. Vi har försökt lösa det här flera gånger utan att lyckas. Sammanfatta: vad är problemet, vad har vi provat, vad hände varje gång och vilka antaganden har vi gjort som kan vara fel? Föreslå sedan ett helt annat angreppssätt.

Gå igenom appens formulär och flöden och lista vad som kan gå fel om en användare gör oväntade saker: tomma fält, jättelånga texter, specialtecken, dubbelklick, fel ordning. Åtgärda de viktigaste och berätta vad du gjort.

Granska koden i projektet som en erfaren utvecklare skulle göra inför en överlämning. Leta efter buggar, upprepningar, saker som är onödigt krångliga och sådant som blir svårt att underhålla. Sortera fynden efter allvarlighet och förklara dem med vanliga ord. Ändra inget förrän jag sagt vilka jag vill åtgärda.

Städa projektet utan att ändra hur appen fungerar: ta bort kod och filer som inte används, ge saker tydliga namn och uppdatera README.md så att någon annan kan förstå och köra projektet.

Hjälp mig att koppla git på den här datorn till mitt GitHub-konto. Kontrollera först om git är installerat och om jag redan är inloggad. Om inte: guida mig steg för steg (gärna med GitHub CLI och inloggning via webbläsaren). Jag vill aldrig behöva klistra in lösenord eller nycklar i chatten.

Gör det här projektet till ett git-repo om det inte redan är det, kontrollera att .gitignore utesluter node_modules, .env-filer och andra saker som inte ska upp. Gör en första commit med en tydlig beskrivning, skapa ett PRIVAT repo på GitHub med samma namn som mappen och pusha. Ge mig länken till repot.

Det fungerar nu. Gör en commit med en kort, tydlig beskrivning på svenska av vad som ändrats, och pusha till GitHub.

Något gick sönder i de senaste ändringarna. Visa mig de senaste commitarna med beskrivningar, och hjälp mig gå tillbaka till hur det såg ut vid [COMMIT/TIDPUNKT] på ett sätt som går att ångra. Förklara vad du gör innan du gör det.

Jag vill prova [IDÉ] utan att riskera det som fungerar. Skapa en ny branch med ett beskrivande namn, gör ändringen där, committa och pusha. Förklara sedan hur jag skapar en pull request på github.com för att granska och slå ihop den.

Sammanfatta vad som har ändrats i projektet sedan [IGÅR/SENASTE PUSH], med vanliga ord. Finns det ändringar som inte är committade?

Förbered appen för publicering på Vercel: kör en produktionsbyggnad lokalt (npm run build) och rätta eventuella fel, kontrollera att inga hemligheter finns i koden och lista vilka miljövariabler jag behöver lägga in i Vercel.

Hjälp mig publicera projektet på Vercel med Vercel CLI. Installera den om det behövs, låt mig logga in via webbläsaren, koppla projektet till mitt GitHub-repo så att varje push publiceras automatiskt och ge mig den publika adressen.

Publiceringen på Vercel misslyckades. Här är byggloggen: [KLISTRA IN DE RÖDA RADERNA]. Ta reda på varför det fungerar lokalt men inte på Vercel, rätta felet, verifiera med npm run build lokalt och committa + pusha.

Lista exakt vilka miljövariabler den publicerade appen behöver (namn och var jag hittar värdet, men skriv inte ut hemliga värden). Förklara steg för steg hur jag lägger in dem i Vercel och hur jag publicerar om efteråt.

Lägg till en titel, beskrivning och delningsbild (Open Graph) så att appen ser bra ut när länken delas i Teams, Slack eller LinkedIn. Lägg också till en favicon.

Gör en säkerhetsgranskning av projektet inför att jag delar det med andra. Kontrollera särskilt: hemligheter i koden eller git-historiken, att RLS är påslaget och korrekt på alla tabeller, att användare inte kan se eller ändra andras data, att indata valideras och att den hemliga Supabase-nyckeln inte används i webbläsaren. Sortera fynden efter allvarlighet och förklara dem med vanliga ord.

Lägg till inloggning med Supabase Auth (e-post och lösenord, eller magisk länk om det är enklare). Användare som inte är inloggade ska bara se en inloggningssida. Visa vem som är inloggad och lägg till en logga ut-knapp. Berätta vilka inställningar jag behöver göra i Supabase, t.ex. vilka adresser som ska vara tillåtna för omdirigering (både localhost och min vercel.app-adress).

Se till att varje användare bara kan se, skapa, ändra och ta bort sina egna poster. Lägg till en koppling till användaren i tabellerna om den saknas, och ge mig SQL för Row Level Security-regler att köra i Supabase. Förklara reglerna med vanliga ord och berätta hur jag testar att de fungerar med två konton.

Jag vill att användare som tillhör samma team ska se varandras poster, men inte andra teams. Föreslå den enklaste datamodellen och RLS-reglerna för det, förklara dem med vanliga ord och genomför ändringen när jag godkänt.

Gå igenom vilka uppgifter appen samlar in och lagrar. Vilka av dem är personuppgifter? Var lagras de (region/tjänst)? Föreslå hur vi kan samla in så lite som möjligt, och skriv en kort, enkel text om hur datan hanteras som jag kan visa för användarna.

Jag tror att jag råkat lägga en hemlig nyckel eller ett lösenord i koden eller på GitHub. Hjälp mig ta reda på om det stämmer, och i så fall: förklara att nyckeln måste bytas hos tjänsten (och hur), flytta den till en miljövariabel och se till att det inte händer igen.