Promptmönster för renare programvaruarkitektur och färre omskrivningar

Hur "renare arkitektur" ser ut i AI-stött arbete

"Renare arkitektur" i det här inlägget betyder inte ett särskilt ramverk eller en perfekt diagram. Det betyder att du kan förklara systemet enkelt, ändra det utan att bryta orelaterade delar och verifiera beteende utan hjältedåd i testerna.

En praktisk definition: tydlighet, modularitet, testbarhet

Tydlighet betyder att systemets syfte och form är uppenbar från en kort beskrivning: vad det gör, vem som använder det, vilken data det hanterar, och vad det absolut inte får göra. I AI-stött arbete betyder tydlighet också att modellen kan återge kraven tillbaka till dig på ett sätt du skulle skriva under.

Modularitet betyder att ansvarsområden har rena gränser. Varje modul har ett jobb, inputs/outputs och minimal kunskap om andra modulers internals. När AI genererar kod är modularitet det som hindrar att affärsregler kladdas ut över controllers, UI och dataåtkomst.

Testbarhet betyder att arkitekturen gör det billigt att "bevisa att det fungerar". Affärsregler kan testas utan ett helt körande system, och integrationstester fokuserar på några få kontrakt snarare än varje kodväg.

Varför omskrivningar händer (och varför AI kan förstärka dem)

Omskrivningar orsakas oftast inte av "dålig kod"—de orsakas av saknade begränsningar, vag scope och dolda antaganden. Exempel:

• En funktion byggs för en användartyp, och så upptäcker du att det finns tre roller med olika behörigheter.
• Prestanda-, revisions- eller lagringsregler dyker upp sent.
• Ett externt API beter sig annorlunda än väntat, vilket tvingar förändringar överallt.

AI kan accelerera detta felläge genom att snabbt producera övertygande output, vilket gör det enkelt att bygga vidare på osäkra grunder.

Vad du kan förvänta dig av mönstren i den här guiden

Mönstren som följer är mallar att anpassa, inte magiska prompts. Deras verkliga mål är att tvinga fram rätt konversationer tidigt: förtydliga begränsningar, jämföra alternativ, dokumentera antaganden och definiera kontrakt. Om du hoppar över det tänkandet kommer modellen glatt fylla i luckorna—och du får betala för det senare.

Var dessa mönster passar i ditt arbetsflöde

Du använder dem över hela leveranscykeln:

• Planering: skärp kraven och framgångskriterier
• Design: välj gränser, dataflöden och kontrakt
• Kodning: håll ansvar separerade när implementation växer
• Granskning: fånga risker och mismatch innan de blir omskrivningar

Om du använder ett vibe-coding-arbetsflöde (där systemet genereras och itereras via chat) är dessa checkpoints ännu viktigare. Till exempel i Koder.ai kan du köra en "planning mode"-loop för att låsa krav och kontrakt innan du genererar React/Go/PostgreSQL-kod, och sedan använda snapshots/rollback för att iterera säkert när antaganden ändras—utan att varje ändring blir en omskrivning.

Hur man använder prompting-mönster utan att skapa mer arbete

Promptmönster är mest värdefulla när de minskar beslutsfladdrande. Tricket är att använda dem som korta, upprepbara checkpoints—innan du kodar, medan du designar och under granskning—så att AI producerar artefakter du kan återanvända, inte extra text du måste sålla igenom.

När använda mönstren

Innan kodning: kör en "alignmentsloop" för att bekräfta mål, användare, begränsningar och acceptanskriterier.

Under design: använd mönster som tvingar explicita avvägningar (t.ex. alternativ, risker, datagränser) innan du börjar implementera.

Under granskning: använd en checklista-liknande prompt för att upptäcka luckor (edge cases, övervakning, säkerhet, prestanda) medan ändringar fortfarande är billiga.

Samla inputs först (håll det lätt)

Du får bättre output med ett litet, konsekvent inputpaket:

• Mål: vad "klart" betyder (latensmål, UX-utfall, kostnadsgränser)
• Användare: roller, nyckelworkflows och största smärtan
• Begränsningar: teknikstack, deadlines, compliance/säkerhetskrav
• Data & integrationer: källor, ägarskap, API:er, tredjepartsberoenden

Om du inte vet något, säg det uttryckligen och be AI:n lista antaganden.

Be om återanvändbara outputformat

Istället för "förklara designen", begär artefakter du kan klistra in i docs eller tickets:

• En beslutslogg (alternativ → för-/nackdelar → valt → varför)
• En tabell över komponenter med ansvar och gränser
• En checklista för tillförlitlighet och testning
• En enkel diagrambeskrivning (t.ex. Mermaid-text) som du kan rendera senare

Iterera i små loopar med acceptanskriterier

Gör 10–15 minutersloopar: prompt → skumma → skärpa. Inkludera alltid acceptanskriterier (vad som måste vara sant för att designen ska vara acceptabel), och be sedan AI:n att självkontrollera mot dem. Det hindrar processen från att utvecklas till ändlösa redesign och gör nästa sektioners mönster snabba att applicera.

Mönster 1: Förtydliga kraven innan design

De flesta "arkitektur-omskrivningar" orsakas inte av dåliga diagram—de orsakas av att man byggt rätt sak för fel (eller ofullständigt) problem. När du använder en LLM tidigt, be inte om arkitektur först. Be den exponera tvetydigheter.

Prompt-tricket: gör osäkerhet till en checklista

Använd modellen som kravintervjuare. Målet är en kort, prioriterad specifikation som du kan bekräfta innan någon designar komponenter, väljer databaser eller skriver API-kontrakt.

Här är en kopiera-klistra-mall du kan återanvända:

You are my requirements analyst. Before proposing any architecture, do this:

1) Ask 10–15 clarifying questions about missing requirements and assumptions.
   - Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.

2) Produce a prioritized scope list:
   - Must-have
   - Nice-to-have
   - Explicitly out-of-scope

3) List constraints I must confirm:
   - Performance (latency/throughput targets)
   - Cost limits
   - Security/privacy
   - Compliance (e.g., SOC2, HIPAA, GDPR)
   - Timeline and team size

4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”

Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):

Vad du ska leta efter i outputen

Du vill ha frågor som tvingar fram beslut (inte generiska "berätta mer"), plus en must-have-lista som faktiskt går att slutföra inom din tidslinje.

Behandla återgivningen i "10 punkter" som ett kontrakt: klistra in det i din ticket/PRD, få ett snabbt ja/nej från intressenter och först därefter gå vidare till arkitektur. Detta steg förhindrar den vanligaste orsaken till sena refaktorer: att bygga funktioner som aldrig var verkligt nödvändiga.

Mönster 2: Användarresor först, sedan tekniska val

När du börjar med verktyg ("Ska vi använda event sourcing?") hamnar du ofta i att designa för arkitekturen istället för användaren. En snabbare väg till ren struktur är att låta AI beskriva användarresor först, i enkelt språk, och först därefter översätta dessa resor till komponenter, data och API:er.

En enkel journey-first-promptmall

Använd detta som utgångspunkt:

• Roller: user / admin / system
• Nyckelåtgärder: vad varje roll försöker uppnå
• Edge cases: vad som kan gå fel (ogiltig input, saknade behörigheter, partiell slutföring)

Be sedan om:

1. “Beskriv steg-för-steg-flödet för varje åtgärd i enkelt språk.”

2. “Ge en enkel tillståndsdiagrambeskrivning eller tillståndslista (t.ex. Draft → Submitted → Approved → Archived).”

3. “Lista icke-happy-path-scenarier: timeouts, retries, duplicerade förfrågningar, avbokningar och ogiltiga inputs.”

Att omvandla resor till beslut (utan att hoppa för långt)

När flödena är tydliga kan du be AI:n mappa dem till tekniska val:

• Var behöver vi validering kontra affärsregler?
• Vilka steg kräver idempotens (säkra retries)?
• Vilken data måste lagras, vad kan härledas, och vad kräver revisionslogg?

Bara efter det bör du be om en arkitekturskiss (tjänster/moduler, gränser och ansvar) knuten direkt till flödesstegen.

Konvertera flöden till testbara acceptanskriterier

Avsluta med att låta AI:n konvertera varje resa till acceptanskriterier du faktiskt kan testa:

• “Given/When/Then för varje steg och felcase.”
• “Vad ska systemet returnera eller visa?”
• “Vad ska loggas, och vad ska trigga retry kontra ett användarvänligt fel?”

Detta mönster minskar omskrivningar eftersom arkitekturen växer ur användarbeteende—inte ur antaganden om teknik.

Mönster 3: Antagandelogg för att förhindra överraskande omskrivningar

De flesta arkitekturarbeten omarbetas inte på grund av "dålig design"—de beror på dolda antaganden som visar sig vara falska. När du ber en LLM om arkitektur kommer den ofta att fylla i luckor med plausibla gissningar. En antagandelogg gör dessa gissningar synliga tidigt, när förändringar är billiga.

Vad du ska be modellen göra

Målet är att tvinga fram en ren separation mellan fakta du gav och antaganden den uppfann.

Använd denna prompt:

Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”

Ett återanvändbart “antagandelogg”-format

Håll det kort så folk faktiskt använder det:

• Antagande: …
• Status: validated / unknown
• Varför det spelar roll: vilket beslut det påverkar
• Hur validera: fråga, kontroll eller spike
• Om fel, sannolik ändring: vad du skulle redesigna

"Vad skulle ändra ditt svar?"-triggers

Lägg till en rad som får modellen att ange sina brytpunkter:

• “Lista 5 triggers: vad skulle ändra ditt svar? (t.ex. användarvolym, latensmål, compliance-behov, datalagringskrav).”

Detta mönster förvandlar arkitektur till en uppsättning villkorade beslut. Du får inte bara ett diagram—du får en karta över vad som måste bekräftas innan du binder dig.

Mönster 4: Jämför flera arkitekturer innan du väljer

AI-verktyg är bra på att producera en enskild "bäst" design—men det är ofta bara det första rimliga alternativet. En renare arkitektur framträder ofta när du tvingar fram en jämförelse tidigt, medan förändringar fortfarande är billiga.

Kärnprompten

Använd en prompt som kräver flera arkitekturer och en strukturerad avvägningstabell:

Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.

Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:

Varför detta minskar omskrivningar

En jämförelse tvingar modellen (och dig) att yta upp dolda antaganden: var tillstånd bor, hur tjänster kommunicerar, vad som måste vara synkront och vad som kan fördröjas.

Kriterietabellen är viktig eftersom den stoppar debatter som "microservices vs monolith" från att bli åsiktsdrivna. Den förankrar beslutet i vad ni faktiskt bryr er om—att leverera snabbt, minska driftkostnad eller förbättra tillförlitlighet.

Kräv en rekommendation och en gräns

Acceptera inte "det beror på." Be om en tydlig rekommendation och specifika begränsningar den optimerar för.

Insistera också på "vad vi inte bygger." Exempel: "Ingen multi-region failover", "Ingen plugin-arkitektur", "Inga realtidsnotiser." Det håller arkitekturen från att tyst expandera till att stödja funktioner ni inte förbundit er till—och förhindrar överraskande omskrivningar senare.

Mönster 5: Modulara gränser och ansvars-prompter

De flesta omskrivningar sker för att gränser var vaga: allt "rör allt", och en liten ändring sprider sig i kodbasen. Detta mönster använder prompts som tvingar fram tydligt modulägande innan någon börjar debattera ramverk eller klassdiagram.

Kärnidén

Be AI:n definiera moduler och ansvar, plus vad uttryckligen inte hör hemma i varje modul. Begär sedan gränssnitt (inputs/outputs) och beroenderegler, inte en byggplan eller implementeringsdetaljer.

Kopiera-klistra-promptmall

Använd detta när du skissar en ny funktion eller refaktoriserar ett rörigt område:

• Context: <one paragraph about the product/feature>
• Goal: Propose a modular architecture with 4–8 modules.

1. Lista moduler med:

   • Purpose (1 sentence)
   • Responsibilities (3–5 bullets)
   • Non-responsibilities (“does NOT handle…”) (2–3 bullets)

2. För varje modul, definiera endast gränssnitt:

   • Inputs (events/requests/data)
   • Outputs (responses/events/side effects)
   • Public API surface (function names or endpoints ok; no internal classes)

3. Dependency rules:

   • Allowed dependencies (A → B)
   • Forbidden dependencies (A ↛ C) with reasoning
   • Where shared types live (and what must never be shared)

4. Future change test: Given these likely changes: <list 3>, show which single module should absorb each change and why.

Hur bra output ser ut

Målet är moduler du kan beskriva för en kollega på under en minut. Om AI:n föreslår en "Utils"-modul eller lägger affärsregler i controllers, tryck tillbaka: "Flytta beslutsfattande till en domänmodul och håll adapters tunna."

När du är klar har du gränser som överlever nya krav—eftersom förändringar har ett klart hem och beroenderegler hindrar oavsiktlig koppling.

Mönster 6: Data & API-kontrakt först (undvik integrationsomarbete)

Integrationsomarbete orsakas ofta inte av "dålig kod"—det orsakas av oklara kontrakt. Om datamodellen och API-formerna bestäms sent fyller varje team (eller modul) i luckor olika, och du spenderar nästa sprint på att försona mismatchande antaganden.

Börja med att prompta för kontrakt innan du pratar ramverk, databaser eller mikrotjänster. Ett tydligt kontrakt blir den gemensamma referensen som håller UI, backend och datapipelines synkade.

Kontrakt-först-prompten

Använd detta tidiga prompt med din AI-assistent:

• Template: “Describe the data model, ownership, and lifecycle for each entity”

Följ sedan direkt upp med:

• Be om API-kontrakt med exempel (requests, responses, error shapes)
• Lägg till versionering och backward-compatibility-förväntningar
• Begär valideringsregler och edge cases per fält

Hur bra output ser ut

Du vill ha konkreta artefakter, inte prosa. Till exempel:

• Entity: Subscription
  • Owner: Billing service
  • Lifecycle: created on checkout → active → past_due → canceled (soft-delete after 90 days)
  • Source of truth: billing DB; other services cache read-only copies

Och en API-skiss:

POST /v1/subscriptions
{
  "customer_id": "cus_123",
  "plan_id": "pro_monthly",
  "start_date": "2026-01-01"
}

201 Created
{
  "id": "sub_456",
  "status": "active",
  "current_period_end": "2026-02-01"
}

422 Unprocessable Entity
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "start_date must be today or later",
    "fields": {"start_date": "in_past"}
  }
}

Versions- och kompatibilitetsregler

Låt AI:n ange regler som: "Lägg till fält utan versionshöjning; byten av namn kräver /v2; klienter ska ignorera okända fält." Detta steg förhindrar tysta breaker-ändringar—och de omskrivningar som följer.

Mönster 7: Fel-lägen och tillförlitlighetschecklista

Arkitekturer skrivs om när "happy path" möter verklig trafik, ostadiga beroenden och oväntat användarbeteende. Detta mönster gör tillförlitlighet till ett explicit designresultat, inte en efterhandskonstruktion.

Kopiera-klistra-promptmall

Använd detta med din valda arkitekturbeskrivning:

List failure modes; propose mitigations; define observability signals.

För varje failure mode:

• What triggers it?
• User impact (vad användaren upplever)
• Mitigation (design + operational)
• Retries, idempotency, rate limits, timeouts-överväganden
• Observability: logs/metrics/traces + larmtrösklar

Vad modellen måste täcka (icke-förhandlingsbart)

Fokusera på de gränssnitt som kan misslyckas: externa API:er, databas, köer, auth-leverantör och bakgrundsjobb. Kräv sedan konkreta beslut:

• Retries: när man ska retrya, hur många gånger, backoff-strategi och vilka fel som är retrybara.
• Idempotens: idempotens-nycklar, dedupe-fönster och vad som är säkert att spela upp.
• Rate limits: per användare/IP/tjänst, klientmeddelanden och server-side-skydd.
• Timeouts: per beroende, övergripande request-budget och hur avbeställning sprids.

Tillförlitlighetschecklista

Avsluta prompten med: "Returnera en enkel checklista vi kan granska på 2 minuter." En bra checklista innehåller punkter som: beroendetidouter satta, begränsade retries, idempotens för skapa/charge-aktioner, backpressure/rate limiting på plats, definierad graceful degradation-path.

Observability knutet till användarögonblick

Begär events kring användarmoment (inte bara systeminternals): "user_signed_up", "checkout_submitted", "payment_confirmed", "report_generated". För varje event, be om:

• Loggfält (user_id, request_id, idempotency_key)
• Metriker (sannolikhet, latens p95/p99, retry-count)
• Traces (spans per beroendeanrop)

Detta gör tillförlitlighet till ett designartefakt du kan validera innan kod finns.

Mönster 8: MVP-slice-planering för att undvika överbyggande

Ett vanligt sätt som AI-stött design skapar omskrivningar är genom att uppmuntra till "kompletta" arkitekturer för tidigt. Åtgärden är enkel: tvinga planen att börja med den minsta användbara skivan—en som levererar värde, provar designen och håller framtida alternativ öppna.

Promptmallen

Använd detta när lösningen växer snabbare än kraven:

Template: “Propose the smallest usable slice; define success metrics; list follow-ups.”

Be modellen svara med:

• MVP-slice: vad som ingår för att leverera något verkligt
• Success metrics: hur du vet att det fungerade (användar- och tekniska mått)
• Follow-ups: vad som kan vänta utan att blockera lärandet

Kräv en fasad roadmap (MVP → v1 → v2)

Lägg till: "Ge en fasad roadmap: MVP → v1 → v2, och förklara vilken risk varje fas reducerar." Detta håller senare idéer synliga utan att tvinga in dem i första releasen.

Exempelutfall du vill ha:

• MVP validerar kärnworkflow och en tunn end-to-end-bana.
• v1 hårdnar tillförlitlighet, lägger till saknad "måste-ha"-användbarhet.
• v2 utökar bredd (fler integrationer, avancerade roller, optimeringar).

Kräv uttryckliga undantag för att förhindra scope creep

Den mest kraftfulla raden i detta mönster är: "Lista vad som uttryckligen är out-of-scope för MVP." Exklusioner skyddar arkitekturval från för tidig komplexitet.

Bra exklusioner ser ut som:

• "Ingen multi-region failover i MVP (logga incidenter; planera för v2)."
• "Ingen plugin-arkitektur än (håll gränser rena, men skicka fasta moduler)."
• "Endast en betalningsleverantör; abstraktion senare om det behövs."

Gör planen till tickets med beroenden

Avsluta med: "Konvertera MVP till tickets, var och en med acceptanskriterier och beroenden." Det tvingar klarhet och avslöjar dold koppling.

En solid ticketuppdelning brukar inkludera:

1. En tunn end-to-end "happy path"
2. Minimal datamodell + API-kontrakt
3. Grundläggande felhantering och logging
4. En integrationspunkt (om behövs) med stubbad fallback

Om du vill, låt modellen outputa i ditt teams format (t.ex. Jira-fält) och håll senare faser i en separat backlog.

Mönster 9: Test-först-prompter som formar bättre designer

Ett enkelt sätt att stoppa arkitektur från att driva iväg är att tvinga klarhet genom tester före du ber om en design. När du promptar en LLM att börja med acceptanstester måste den namnge beteenden, inputs, outputs och edge cases. Det blottlägger saknade krav och pressar implementeringen mot rena modulgränser.

Kopiera-klistra-promptmall

Använd detta som en "port"-prompt när du ska designa en komponent:

• Template: “Write acceptance tests first; then propose implementation. You must: (1) list assumptions, (2) name unit vs integration tests, (3) define test data and mocks vs real dependencies, (4) include a definition of done.”

Be om testgränser som matchar moduler

Följ upp med: "Gruppera testerna efter modulansvar (API-lagret, domänlogik, persistens, externa integrationer). För varje grupp, specificera vad som mockas och vad som är verkligt."

Detta förflyttar LLM:n bort från intrasslade designer där allt rör allt. Om den inte kan förklara var integrationstester börjar, är din arkitektur förmodligen inte tillräckligt klar än.

Testdatastrategi: undvik sköra sviter

Begär: "Föreslå en testdatastrategi: fixtures vs factories, hur man genererar edge cases, och hur man håller tester deterministiska. Lista vilka beroenden som kan använda in-memory-fakes och vilka som behöver en riktig tjänst i CI."

Du kommer ofta upptäcka att en "enkel" funktion faktiskt behöver ett kontrakt, en seed-dataset eller stabila ID:n—bättre att hitta det nu än under en omskrivning.

Definition of done (så designen levereras)

Avsluta med en lättviktig checklista:

• Tester passerande (unit + integration) och meningsfull täckning av felcase
• Minimal docs: användning, konfiguration och en kort felsökningsnot
• Övervakning/larm för nyckelfel
• Utrullningsplan (feature flag, migrationssteg, rollback)

Mönster 10: Designgranskningsprompter för att hitta problem tidigt

Designgranskningar ska inte bara ske efter att kod finns. Med AI kan du köra en "pre-mortem review" på din arkitekturskiss (även om det bara är några stycken och ett diagram-i-ord) och få en konkret lista med svagheter innan de blir omskrivningar.

Kärnreview-mallen

Börja med en ärlig granskar-roll och tvinga fram konkretion:

Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can’t evaluate something, say what information is missing.”

Klistra in din designsammanfattning, begränsningar (budget, tidslinje, teamets kompetens) och icke-funktionella krav (latens, tillgänglighet, compliance).

Gör feedback till en åtgärdbar punch-list

Granskningar misslyckas när feedback är vag. Be om en rankad uppsättning fixes:

Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”

Detta ger en beslutsfärdig uppsättning uppgifter istället för en debatt.

Kvantifiera omskrivningsrisk

En användbar forcing-funktion är en enkel poäng:

Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”

Du jagar inte precision; du yttar fram de mest omskrivningsbenägna antagandena.

Avsluta med en “diff-plan”

Slutligen, förhindra att granskningen expanderar scope:

Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”

När du upprepar detta mönster i varje iteration utvecklas arkitekturen genom små, reversibla steg—medan stora problem fångas tidigt.

Ett kopiera-klistra promptpack och ett enkelt arbetsflöde

Använd detta pack som ett lättviktigt arbetsflöde du kan upprepa för varje feature. Idén är att kedja prompts så att varje steg producerar ett artefakt nästa steg kan återanvända—vilket minskar "borttappad kontext" och överraskande omskrivningar.

6-stegs arbetsflöde (kedja dessa mönster)

1. Krav (förtydliga + begränsningar)
2. Arkitekturalternativ (jämför 2–3 angreppssätt)
3. Gränser (moduler + ansvar)
4. Kontrakt (data + API:er)
5. Tester (test-först-acceptans + nyckelunittester)
6. Granskning (fel-lägen + designgranskningschecklista)

I praktiken implementerar team ofta denna kedja som en upprepbar "feature recipe". Om du bygger med Koder.ai mappar samma struktur rent till ett chattdrivet bygge: fånga artefakterna på ett ställe, generera första fungerande skivan och iterera med snapshots så experiment är reversibla. När MVP är klar kan du exportera källkod eller distribuera/hosta med en egen domän—användbart när du vill ha snabbhet i AI-assisterad leverans utan att låsa dig till en miljö.

Kopiera-klistra promptpack (med guardrails)

SYSTEM (optional)
You are a software architecture assistant. Be practical and concise. 
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.

1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>

Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.

2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.

3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”

4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”

5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”

6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”

Om du vill ha en djupare följeslagare, se prompting-for-code-reviews. Om du utvärderar verktyg eller teamrullout är pricing ett praktiskt nästa steg.