@haus-tech/haus-workflow 5.6.1 → 5.7.0

package/library/global/skills/request-write-spec/SKILL.md

@@ -1,126 +1,128 @@
 ---
 name: request-write-spec
-description: Skriv en spec enligt Haus specformat utifrån ett rått kundönskemål — utan att ställa frågor tillbaka. Använd alltid när användaren vill "speca", "skriv en spec", "gör en spec av det här", klistrar in ett kundönskemål/en ticket som ska bli en spec, eller kör önskemål genom förvaltningsmodellens flöde. Även för omskrivning av en befintlig spec till formatet. Output är färdiga specar plus ett granskarblock för mänsklig validering — aldrig följdfrågor.
+description: Write a spec in the Haus spec format from a raw customer request, without asking questions back. Always use when the user wants to "speca", "skriv en spec", "gör en spec av det här", pastes a customer request or ticket that should become a spec, or runs requests through the maintenance model's flow. Also for rewriting an existing spec into the format. Output is finished specs plus a reviewer block for human validation, never follow-up questions.
 ---
 
 # request-write-spec
 
-Du förvandlar ett rått kundönskemål till en eller flera specar enligt Haus specformat. Specen är beslutspunkten mot kund: kunden läser den, ser priset (som sätts senare, av poängsättningen — aldrig av dig) och svarar ja, nej eller reviderar. En människa hos Haus validerar din spec innan den når kunden.
+You turn a raw customer request into one or more specs in the Haus spec format. The spec is the decision point with the customer: the customer reads it, sees the price (set later, by the scoring, never by you) and answers yes, no, or revises. A human at Haus validates your spec before it reaches the customer.
 
-Det viktigaste att förstå: **du ställer aldrig frågor tillbaka.** Flödet är byggt för snabb iteration — kunden lägger ett önskemål, du specar direkt, människan validerar. En fråga från dig stoppar bandet. När underlaget inte räcker gör du det bästa rimliga antagandet, skriver specen som om antagandet stämmer, och redovisar antagandet öppet i granskarblocket. Granskaren rättar dig på sekunder; en obesvarad fråga kostar dagar. Fel antagande synligt redovisat är alltså ett _bra_ utfall — det är så systemet är tänkt att fungera.
+The most important thing to understand: **you never ask questions back.** The flow is built for fast iteration: the customer files a request, you spec it directly, the human validates. A question from you stops the line. When the source material is not enough, you make the best reasonable assumption, write the spec as if the assumption holds, and state the assumption openly in the reviewer block. The reviewer corrects you in seconds; an unanswered question costs days. A wrong assumption, visibly stated, is therefore a _good_ outcome. That is how the system is meant to work.
 
-Läs `references/specformat.md` innan du skriver din första spec i en session — den innehåller det fullständiga formatet med exempel. Kärnan följer här.
+Read `references/specformat.md` before you write your first spec in a session. It contains the complete format with examples. The core follows here.
 
-**Går filen inte att läsa: skriv ingen spec.** Säg att `references/specformat.md` saknas och att skillen inte kan köras utan den. Rubrikerna framgår nedan och frestelsen att köra ändå är stor — men exemplen och gränsfallen finns bara i referensfilen, och en spec som ser rätt ut men missar dem går inte att upptäcka i granskningen.
+**If the file cannot be read: write no spec.** Say that `references/specformat.md` is missing and that the skill cannot run without it. The headings are listed below and the temptation to run anyway is strong, but the examples and edge cases exist only in the reference file, and a spec that looks right but misses them cannot be caught in review.
 
-## Formatet
+## The format
 
-Varje spec har exakt de här rubrikerna i den här ordningen. De tre sista bara när de behövs.
+Every spec has exactly these headings, in this order. The last three only when needed. Each heading is shown as its Swedish / English literal (see The customer's language below).
 
-**Rubrik** — det förändrade tillståndet, inte uppgiften. "Verksamheter sätter upp sin egen teamstruktur", inte "Bygg adminvy för team". Kunden prioriterar på rubriken; en uppgiftsrubrik får den att prioritera arbete i stället för utfall.
+**Title**: the changed state, not the task. "Verksamheter sätter upp sin egen teamstruktur", not "Bygg adminvy för team". The customer prioritises on the title; a task title makes them prioritise work instead of outcomes.
 
-**Problem** — en eller två meningar: hur det är idag och vad det kostar i vardagen. Bara problemet. Skriv inte "det här löser vi genom att…" — det är nästa rubriks jobb.
+**Problem**: one or two sentences: how things are today and what it costs in everyday work. Only the problem. Do not write "det här löser vi genom att…": that is the next heading's job.
 
-**Lösning** — 2–4 meningar som låter läsaren se förändringen framför sig: vad som dyker upp, var, hur det används. Lösningen som den _upplevs_, aldrig som den byggs — teknik, datamodell och arbetssteg hör hemma i påverkansanalysen, inte här. Skriv i påståendeform. Ord som "förslagsvis", "alternativt", "beroende på" hör inte hemma i en spec — de betyder att ett beslut saknas.
+**Lösning** / **Solution**: 2–4 sentences that let the reader picture the change: what appears, where, how it is used. The solution as it is _experienced_, never as it is built; technology, data model and work steps belong in the impact analysis, not here. Write in declarative form. Words like "förslagsvis", "alternativt", "beroende på" do not belong in a spec: they mean a decision is missing.
 
-**När det är klart** — numrerad lista, 2–5 punkter. Varje punkt är något kunden själv kan konstatera efteråt. Är en konsekvens permanent eller oåterkallelig ("raderat går inte att återskapa") står den här som en egen punkt — det är sådant kunden behöver veta innan den godkänner.
+**När det är klart** / **Done when**: numbered list, 2–5 points. Each point is something the customer can verify for themselves afterwards. If a consequence is permanent or irreversible ("deleted data cannot be restored", point 3 in the example at the end), it goes here as its own point: that is what the customer needs to know before approving.
 
-**Ingår inte** — bara det som rimligen kan misstas för inkluderat. Oftast en rad.
+**Ingår inte** / **Not included**: only what could reasonably be mistaken for included. Usually one line.
 
-**Utseende** _(vid behov)_ — när posten har en synlig yta: vilket befintligt mönster den följer, eller att den får ett nytt.
+**Utseende** / **Appearance** _(when needed)_: when the item has a visible surface: which existing pattern it follows, or that it gets a new one.
 
-**Kräver** _(vid behov)_ — vad som måste vara klart först.
+**Kräver** / **Requires** _(when needed)_: what must be done first.
 
-**Villkor** _(vid behov)_ — när posten vilar på något som inte kan verifieras i förväg: "Bygger på att X. Faller det avbryter vi utan kostnad."
+**Villkor** / **Conditions** _(when needed)_: when the item rests on something that cannot be verified in advance: "Bygger på att X. Faller det avbryter vi utan kostnad."
 
-## Reglerna
+## The rules
 
-**Ett beslut per spec.** Kan kunden vilja säga ja till hälften är det två specar — skriv då två. Ett önskemål som innehåller flera user stories eller flera fristående förändringar (en medarbetarvy _och_ en statistikvy _och_ ett tv-läge) blir flera specar, och du noterar i granskarblocket att de hör ihop som bunt.
+**One decision per spec.** If the customer might want to say yes to half of it, it is two specs: then write two. A request that contains several user stories or several independent changes (a staff view _and_ a statistics view _and_ a TV mode) becomes several specs, and you note in the reviewer block that they belong together as a bundle.
 
-Det uppenbara fallet är flera saker som knappt hör ihop. Det svåra är en sammanhållen funktion där en del ändå bär eget värde — "notisen ska gå att stänga och markeras som läst" ser ut som en sak men är två. Testfrågan: **kan del ett driftsättas och användas utan del två?** Ja, och den har eget värde för användaren → två specar, där del två får `Kräver: del ett`. Nej, delen är meningslös ensam → en spec.
+The obvious case is several things that barely belong together. The hard case is a cohesive feature where one part still carries value of its own: "the notification can be dismissed and is marked as read" looks like one thing but is two. The test question: **can part one be deployed and used without part two?** Yes, and it has value of its own for the user → two specs, where part two gets `Kräver: del ett`. No, the part is meaningless alone → one spec.
 
-Frågan är inte estetisk. Poängen sätts per post, så en odelad post ackumulerar kriterier och kan prissättas ett steg högre än samma arbete delat. Delar du för aggressivt sänker du priset under vad arbetet kostar; delar du inte alls höjer du det. Ställ frågan på varje önskemål som har mer än ett krav, och redovisa i granskarblocket när du delat — eller när du övervägt att dela och lät bli.
+The question is not aesthetic. The score is set per item, so an unsplit item accumulates criteria and can be priced one step higher than the same work split. Split too aggressively and you lower the price below what the work costs; do not split at all and you raise it. Ask the question on every request that has more than one requirement, and state in the reviewer block when you split, or when you considered splitting and chose not to.
 
-**Inget "eller" i listan.** Ett "eller" i en utfallspunkt är ett obeslutat vägval i förklädnad. Avgör det (se nedan) — skriv aldrig in det.
+**No "or" in the list.** An "or" (`eller`) in an outcome point is an undecided choice in disguise. Settle it (see below); never write it in.
 
-**Leta efter dolda utfallsval.** En del frågor ser ut som tekniska detaljer men avgör vad användaren faktiskt får — "ska den komma tillbaka på nästa enhet?", "gäller det bara den här användaren eller alla?", "syns ändringen direkt eller vid nästa inloggning?". Sådana frågor är specfrågor, inte byggbeslut, och de ska besvaras här: som acceptanskriterium om svaret är givet, under _Ingår inte_ om avgränsningen är svaret, och som öppen fråga i granskarblocket om det inte går att avgöra ur underlaget.
+**Look for hidden outcome choices.** Some questions look like technical details but decide what the user actually gets: "should it come back on the next device?", "does it apply only to this user or to everyone?", "is the change visible immediately or at the next login?". Such questions are spec questions, not build decisions, and they must be answered here: as an acceptance criterion if the answer is given, under _Not included_ if the boundary is the answer, and as an open question in the reviewer block if it cannot be decided from the source material.
 
-Testfrågan: **skulle användaren märka skillnad mellan alternativen?** Ja → specfråga, besvara den. Nej → byggbeslut, det tas i påverkansanalysen och du ska inte röra det.
+The test question: **would the user notice a difference between the alternatives?** Yes → spec question, answer it. No → build decision, it is taken in the impact analysis and you must not touch it.
 
-Missar du en sådan fråga blir den ett tyst val längre fram i kedjan, fattat av någon som bedömer teknik och inte behov — och då prissätts något ingen beslutat.
+If you miss such a question, it becomes a silent choice further down the chain, made by someone who judges technology and not needs, and then something gets priced that nobody decided.
 
-**Lösningen pekar på listan.** Varje mening under Lösning ska motsvara en punkt under När det är klart. En lösningsmening utan punkt är antingen ett saknat utfall eller en egen post som smugit sig in — i det senare fallet: bryt ut den till en egen spec.
+**The solution points to the list.** Every sentence under Solution must correspond to a point under Done when. A solution sentence without a point is either a missing outcome or a separate item that has crept in; in the latter case, break it out into its own spec.
 
-**Ingen tid, inget pris.** Timmar, estimat och kronor finns inte i specen. Priset sätts av poängsättningen och möter kunden i förslaget. Innehåller kundens önskemål tidsord eller belopp: släng dem, de påverkar ingenting.
+**No time, no price.** Hours, estimates and kronor do not exist in the spec. The price is set by the scoring and meets the customer in the proposal. If the customer's request contains time words or amounts: discard them, they affect nothing.
 
-**En skärm.** Behöver specen skrollas innehåller den nästan alltid två beslut.
+**One screen.** If the spec needs scrolling, it almost always contains two decisions.
 
-**Kundens språk.** Specen läses av kunden. Inga interna termer (protokolltermer, repo-namn, "backlog-post"), ingen story-mall ("Som X vill jag Y"). Specen skrivs på önskemålets språk, svenska eller engelska, och rubrikerna tas ur specformatets rubriktabell på samma språk som brödtexten, aldrig blandat. Granskarblocket är internt och alltid på svenska. Anger prompten `SPRÅK:` är det avgjort där.
+**The customer's language.** The spec is read by the customer. No internal terms (protocol terms, repo names, "backlog-post"), no story template ("Som X vill jag Y"). The spec is written in the request's language, Swedish or English, and the headings are taken from the spec format's heading table in the same language as the body text, never mixed. The reviewer block is internal and always written in English. Its heading is `## For the reviewer` and its row labels are the English ones in the template under Output. If the prompt gives `SPRÅK:`, the spec's language is settled there.
 
-## Normalfallet: en rubrik och en mening
+## The normal case: a title and one sentence
 
-Räkna inte med ett berett underlag. Kundens önskemål ser oftast ut så här:
+Do not count on prepared source material. The customer's request usually looks like this:
 
 > _Administratörsvy för verksamheter_
 > Administratör i projektet (t.ex. Ann-Sofie) kan själv lägga till nya verksamheter
 
-Det är hela inputen. Ditt jobb är beredningen — att växa en spec ur den. En människa som specar gör det med kunskap om projektet, kunden och kodbasen, och det är den kunskapen som gör gissningarna kvalificerade. Gör likadant:
+That is the whole input. Your job is the preparation: growing a spec out of it. A human writing a spec does it with knowledge of the project, the customer and the codebase, and it is that knowledge that makes the guesses qualified. Do the same:
 
-**Leta innan du antar.** Inventera vad sessionen ger dig tillgång till och använd det. Vilka källor som finns beror på uppdraget: i ett befintligt system är kodbasen bäst (finns vyn redan? vilket mönster används för liknande listor? vad heter begreppen i koden?), följt av tidigare specar och tickets för samma kund (hur har liknande poster lösts? vilka termer använder kunden — "skattning", "skift", "verksamhet"?). I ett nytt projekt finns ingen kodbas — då är briefen, offertunderlaget eller annat projektmaterial källan, och lösningen förankras i vad det materialet säger om målgrupp, flöden och befintliga system hos kunden. Det du hittar i källorna är inte antaganden — det är fakta, och de gör specen träffsäker på riktigt. Först när en fråga inte går att besvara ur det som finns blir den ett antagande i granskarblocket. Skriv gärna i granskarblocket _var_ du hämtat de viktigaste faktana ("mönstret finns i användarhanteringsvyn", "enligt briefen sid 2") — det låter granskaren skilja verifierat från gissat på en sekund.
+**Search before you assume.** Take stock of what the session gives you access to and use it. Which sources exist depends on the assignment: in an existing system the codebase is best (does the view already exist? which pattern is used for similar lists? what are the concepts called in the code?), followed by earlier specs and tickets for the same customer (how were similar items solved? which terms does the customer use, "skattning", "skift", "verksamhet"?). In a new project there is no codebase; then the brief, the quote material or other project material is the source, and the solution is anchored in what that material says about the audience, flows and the customer's existing systems. What you find in the sources is not assumptions, it is facts, and they make the spec genuinely accurate. Only when a question cannot be answered from what exists does it become an assumption in the reviewer block. Preferably write in the reviewer block _where_ you got the most important facts ("the pattern exists in the user management view", "per the brief, page 2"); it lets the reviewer tell verified from guessed in a second.
 
-**Leta efter det som redan finns innan du skriver Lösning.** Sök i källmanifestet (`KÄLLOR:`) och med Grep i repot efter en inbyggd funktion i plattformen eller ett redan installerat paket som gör det önskemålet ber om: en väljare, en meny, en export, en behörighetsmodell som redan finns. Redovisa fyndet i granskarblocket under _Vägval jag gjort_ eller _Prisavgörande öppet val_, även när du inte hittade något ("ingen inbyggd yta för X funnen i KÄLLOR eller repot"). Det du inte letat efter kan du inte välja bort medvetet, och ett omedvetet egenbygge är det dyraste valet specen kan göra åt kunden (se regeln under Output).
+**Look for what already exists before you write the Solution.** Search the source manifest (`KÄLLOR:`) and, with Grep, the repo for a built-in feature of the platform or an already installed package that does what the request asks for: a picker, a menu, an export, a permission model that already exists. Report the finding in the reviewer block under _Decisions I made_ or _Price-decisive open choice_, even when you found nothing ("no built-in surface for X found in KÄLLOR or the repo"). What you have not looked for you cannot deliberately rule out, and an unwitting custom build is the most expensive choice the spec can make for the customer (see the rule under Output).
 
-Sedan gäller för själva skrivandet:
+Then, for the writing itself:
 
-**Härled problemet ur önskemålet.** "Kan själv lägga till" betyder att någon idag inte kan själv — det görs via Haus eller inte alls. Det är problemraden. Du behöver inte veta detaljerna; skriv den mest sannolika vardagen och redovisa den som antagande om du är osäker.
+**Derive the problem from the request.** "Kan själv lägga till" means that someone today cannot do it themselves: it is done via Haus or not at all. That is the problem line. You do not need to know the details; write the most likely everyday situation and state it as an assumption if you are unsure.
 
-**Förankra lösningen i det som finns.** Finns ett känt mönster i systemet (en befintlig administratörsvy, en lista, en väljare) — häng den nya förmågan på det. I ett nytt projekt: förankra i briefens beskrivning av flöden och användare. Vet du inget alls: välj det enklaste konventionella mönstret och redovisa valet. Skriv aldrig "en lämplig vy" — det är att skjuta beslutet till läsaren.
+**Anchor the solution in what exists.** If there is a known pattern in the system (an existing admin view, a list, a picker), hang the new capability on it. In a new project: anchor in the brief's description of flows and users. If you know nothing at all: choose the simplest conventional pattern and state the choice. Never write "en lämplig vy": that pushes the decision onto the reader.
 
-Samma format fungerar för övrigt som offertunderlag: en bunt specar ur en brief är i praktiken ett scope, och reglerna (inga "eller", konsekvenser synliga, avgränsningar under Ingår inte) gör samma jobb där. Ändra ingenting i arbetssättet — skriv specar som vanligt, en per beslut.
+The same format also works as quote material: a bundle of specs from a brief is in practice a scope, and the rules (no "or", consequences visible, boundaries under Not included) do the same job there. Change nothing in the way you work: write specs as usual, one per decision.
 
-**Blås inte upp listan.** Tunt underlag är inte ett mandat att uppfinna. "Kan lägga till verksamheter" ger en utfallslista om att lägga till och att det tillagda blir användbart — inte redigering, inte borttagning, inte behörighetsadministration. Grannfunktionerna hör hemma under **Ingår inte**, där de gör dubbelt jobb: de skyddar scopet och de visar kunden vad den kanske också vill beställa. En spec ur en enrading har typiskt 2–3 utfallspunkter och ett fylligt granskarblock — inte tvärtom.
+**Do not inflate the list.** Thin source material is not a mandate to invent. "Kan lägga till verksamheter" gives an outcome list about adding and about what is added becoming usable; not editing, not deletion, not permission administration. The neighbouring features belong under **Ingår inte** / **Not included**, where they do double duty: they protect the scope and they show the customer what it might also want to order. A spec from a one-liner typically has 2–3 outcome points and a full reviewer block, not the other way round.
 
-**Osäkerheten bor i granskarblocket, inte i specen.** Specen läses av kunden och ska vara lika säker i tonen oavsett hur tunt underlaget var. Skillnaden mellan ett rikt och ett tunt underlag ska synas i granskarblockets längd, inte i specens.
+**Uncertainty lives in the reviewer block, not in the spec.** The spec is read by the customer and must be equally confident in tone however thin the source material was. The difference between rich and thin source material must show in the reviewer block's length, not in the spec's.
 
-## När underlaget inte räcker
+## When the source material is not enough
 
-Tre situationer, tre olika hanteringar — och ingen av dem är att fråga:
+Three situations, three different ways of handling them, and none of them is to ask:
 
-**Ett vägval du rimligen kan avgöra** (t.ex. "numrerade team eller fritt namngivna?"): välj det som är mest sannolikt rätt för kunden, skriv specen därefter, redovisa valet under _Vägval jag gjort_ i granskarblocket med en rads motivering. Granskaren ändrar om du valde fel.
+**A choice you can reasonably decide** (e.g. "numbered teams or freely named?"): choose what is most likely right for the customer, write the spec accordingly, and state the choice under _Decisions I made_ in the reviewer block with a one-line rationale. The reviewer changes it if you chose wrong.
 
-**Ett värde någon annan ska bestämma** (t.ex. "gräns vid 12, 18 eller 24 månader?"): gör värdet konfigurerbart i lösningen så att frågan upphör att vara en fråga. "Gränsen ändras utan nytt bygge" är en utfallspunkt; det exakta värdet är en inställning, inte ett spec-beslut.
+**A value someone else should decide** (e.g. "a limit at 12, 18 or 24 months?"): make the value configurable in the solution so that the question stops being a question. "Gränsen ändras utan nytt bygge" is an outcome point; the exact value is a setting, not a spec decision.
 
-**Ett vägval som inte går att avgöra utan kunden** — designfrågor, UX-riktning, okänd felorsak, eller ett val som påverkar andra poster: skriv INTE en låtsasspec. Skriv posten i **kandidatformen** (se `references/specformat.md`, avsnittet Kandidatform): rubriken, direkt under den markörraden `**Koncept-kandidat**` (formen okänd) eller `**Diagnos-kandidat**` (orsaken okänd), på engelska `**Concept candidate**` / `**Diagnosis candidate**`, sedan **Problem** och det som är känt under Ingår inte, Kräver eller Villkor. Ingen Lösning och ingen När det är klart: en kandidat har inget utfall att lova, och med en Lösning är det ingen kandidat längre. Formen är entydig med flit, formkontrollen läser markören och flödet stoppar posten som KONCEPT eller DIAGNOS utan analys eller poäng. Nämn kandidaten även under _Flaggor_ i granskarblocket, med vad som behöver avgöras.
+**A choice that cannot be decided without the customer** (design questions, UX direction, an unknown cause of a fault, or a choice that affects other items): do NOT write a pretend spec. Write the item in the **candidate form** (see `references/specformat.md`, section Candidate form): the title, directly under it the marker line `**Koncept-kandidat**` (form unknown) or `**Diagnos-kandidat**` (cause unknown), in English `**Concept candidate**` / `**Diagnosis candidate**`, then **Problem** and what is known under Not included, Requires or Conditions. No Solution and no Done when: a candidate has no outcome to promise, and with a Solution it is no longer a candidate. The form is unambiguous on purpose: the form check reads the marker and the flow stops the item as KONCEPT or DIAGNOS without analysis or score. Also name the candidate under _Flags_ in the reviewer block, with what needs to be decided.
 
 ## Output
 
-Skriv varje spec som ett eget block, exakt enligt formatet. Efter VARJE spec: ett eget **granskarblock** (`## Till granskaren`) för just den specen, internt, följer aldrig med till kund. I en bunt bär varje block bara det som gäller sin egen spec; det som gäller bunten som helhet (att delarna hör ihop, ordningen dem emellan) står under Flaggor i första specens block. Ett block delat över flera specar fälls av formkontrollen (ADR-0118):
+Write each spec as its own block, exactly per the format. After EVERY spec: its own **reviewer block** (`## For the reviewer`) for that spec alone, internal, never sent to the customer. In a bundle each block carries only what concerns its own spec; what concerns the bundle as a whole (that the parts belong together, their order) goes under Flags in the first spec's block. A block shared across several specs is rejected by the form check (ADR-0118):
 
 ```
 ---
-## Till granskaren
-
-**Antaganden:** [tolkningar av otydligt underlag, en rad var — "tom" om inga]
-**Vägval jag gjort:** [beslut du fattat på eget bevåg + en rads motivering — märk ut de som rör vad användaren får, de är specbeslut och det är dem granskaren måste titta på]
-**Öppna utfallsval:** [frågor om vad användaren får som inte gick att avgöra ur underlaget — "inga" om inga. Rena byggbeslut hör inte hit]
-**Prisavgörande öppet val:** [nej · eller "ja: <valet i en mening, i kundens språk>" när alternativen skiljer sig i vad som måste byggas och du inte kan välja ett utan att gissa kundens avsikt. Inbyggd funktion kontra egenbygge är ALLTID ett ja med båda alternativen namngivna, se nedan. Ett ja stoppar posten före analys tills valet är avgjort; ett val som redan står under "Avgjorda val" i KÄLLOR flaggas aldrig]
-**Flaggor:** [Koncept-/Diagnos-kandidat med skäl (specen själv bär markörraden, det här är granskarens sammanfattning) · misstänkt bunt/beroende till annan post · sådant som ser ut att röra behörighet, betalning, oåterkallelig data eller personuppgifter]
-**Struket ur underlaget:** [tidsord, belopp, interna anteckningar som inte hör hemma i spec]
+## For the reviewer
+
+**Assumptions:** [interpretations of unclear source material, one line each; "none" if none]
+**Decisions I made:** [decisions you took on your own authority + a one-line rationale; mark the ones that affect what the user gets, they are spec decisions and those are what the reviewer must look at]
+**Open outcome choices:** [questions about what the user gets that could not be decided from the source material; "none" if none. Pure build decisions do not belong here]
+**Price-decisive open choice:** [no · or "yes: <the choice in one sentence, in the customer's language>" when the alternatives differ in what must be built and you cannot pick one without guessing the customer's intent. Built-in feature versus custom build is ALWAYS a yes with both alternatives named, see below. A yes stops the item before analysis until the choice is settled; a choice already listed under "## Avgjorda val" in KÄLLOR is never flagged]
+**Flags:** [Concept/Diagnosis candidate with reason (the spec itself carries the marker line, this is the reviewer's summary) · suspected bundle/dependency on another item · anything that appears to touch permissions, payment, irreversible data or personal data]
+**Struck from the source:** [time words, amounts, internal notes that do not belong in a spec]
 ```
 
-**Avgjorda val i KÄLLOR.** Under `## Avgjorda val` i KÄLLOR står val en människa redan tagit. De är fast indata: skriv specen utifrån dem och flagga dem aldrig som öppna eller prisavgörande.
+**Settled choices in KÄLLOR.** Under `## Avgjorda val` in KÄLLOR are choices a human has already made. They are fixed input: write the spec from them and never flag them as open or price-decisive.
 
-Behörighets-/betalnings-/dataflaggan finns för att poängsättningen väger sådana poster tyngre — granskaren ska inte behöva upptäcka det själv.
+The permissions/payment/data flag exists because the scoring weighs such items more heavily; the reviewer should not have to discover that on their own.
 
-De två vägvalsraderna är åtskilda för att de kräver olika sak av granskaren: den första är beslut som redan är fattade och bara ska bekräftas, den andra är hål i specen som måste fyllas innan posten går vidare. Ett öppet utfallsval som ligger kvar i den första raden ser ut som ett fattat beslut och passerar granskningen.
+The two choice rows are separate because they ask different things of the reviewer: the first is decisions already taken that only need confirming, the second is holes in the spec that must be filled before the item moves on. An open outcome choice left in the first row looks like a decision taken and passes review.
 
-Prisavgörande öppet val är det enda i granskarblocket som stoppar posten. Vanliga öppna utfallsval löses av poängsättarens fyrstegsregel; den här raden är för valet där två alternativ ger två olika priser och bara kunden kan välja.
+Price-decisive open choice is the only thing in the reviewer block that stops the item. Ordinary open outcome choices are resolved by the scorer's four-step rule; this row is for the choice where two alternatives give two different prices and only the customer can choose.
 
-**Egen lösning kontra plattformsfunktion.** Finns i källmanifestet, eller i din egen sökning i repot, en inbyggd funktion i plattformen eller ett redan installerat paket som täcker önskemålet, och du väljer att bygga en egen yta i stället, eller tvärtom väljer bort en fungerande inbyggd yta för en egen, är det ALLTID `Prisavgörande öppet val: ja` med båda alternativen namngivna (inbyggd funktion respektive egenbygge), aldrig ett Vägval jag gjort. Skillnaden i pris mellan de två är som störst just där, och bara kunden kan välja. Ett egenbygge som inte ens nämner den inbyggda ytan ser ut som det enda sättet, och kunden betalar tre gånger priset utan att ha valt det.
+**Custom solution versus platform feature.** If the source manifest, or your own search of the repo, turns up a built-in feature of the platform or an already installed package that covers the request, and you choose to build a custom surface instead, or conversely rule out a working built-in surface in favour of a custom one, it is ALWAYS `Price-decisive open choice: yes` with both alternatives named (built-in feature and custom build respectively), never an entry under Decisions I made. The price difference between the two is at its largest exactly there, and only the customer can choose. A custom build that does not even mention the built-in surface looks like the only way, and the customer pays three times the price without having chosen it.
 
-## Exempel i korthet
+## Example in brief
 
-Rått önskemål: _"Som chef vill jag själv kunna radera en skattning så att olämpligt innehåll kan tas bort direkt utan att ringa Haus."_
+Raw request:
+
+> _"Som chef vill jag själv kunna radera en skattning så att olämpligt innehåll kan tas bort direkt utan att ringa Haus."_
 
 > **Chefer raderar olämpliga skattningar själva**
 >
@@ -136,6 +138,6 @@ Rått önskemål: _"Som chef vill jag själv kunna radera en skattning så att o
 > 2. Radering kräver en bekräftelse först
 > 3. Raderat går inte att återskapa
 
-Notera punkt 3: den stod inte i önskemålet — den är konsekvensen som kunden behöver innan den godkänner. Granskarblocket flaggar: _rör oåterkallelig datahantering_.
+Note point 3: it was not in the request; it is the consequence the customer needs before approving. The reviewer block flags: _touches irreversible data handling_.
 
-Fler kompletta exempel, inklusive fallen med flera specar ur ett önskemål och öppen-fråga-som-blev-inställning, finns i `references/specformat.md`.
+More complete examples, including the cases with several specs from one request and the open question that became a setting, are in `references/specformat.md`.

package/library/global/skills/request-write-spec/references/specformat.md

@@ -1,46 +1,48 @@
-# Specformat
+# Spec format
 
-_Utkast v0.3 · Internt. Formen för specen — dokumentet som beskriver vad vi uppfattat och vad som blir annorlunda. Specen triggar analys och prissättning; priset hör till förslaget kunden sedan tar ställning till, aldrig till specen själv. Klassning och teknisk analys syns inte heller här._
+_Draft v0.3 · Internal. The form of the spec: the document that describes what we have understood and what will be different. The spec triggers analysis and pricing; the price belongs to the proposal the customer then takes a position on, never to the spec itself. Classification and technical analysis do not appear here either._
 
 ---
 
-## Vad specen är
+## What the spec is
 
-Kunden lämnar ett önskemål, bra eller dåligt beskrivet. Vi formulerar om det till vår uppfattning av vad som ska åstadkommas — det är specen. Analysen sätter priset utifrån den, och kunden får spec och pris tillsammans som ett förslag: godkänn, avstå eller revidera, där revidering triggar ny prissättning.
+The customer submits a request, well or poorly described. We reformulate it into our understanding of what is to be achieved: that is the spec. The analysis sets the price from it, and the customer gets spec and price together as a proposal: approve, decline or revise, where a revision triggers new pricing.
 
-Specen är också scopegränsen. Priset ändras aldrig efter byggstart, vilket gör specen till det som avgör vad som ingick — i vardagen, varje gång någon undrar om något var med.
+The spec is also the scope boundary. The price never changes after the build starts, which makes the spec what decides what was included, in everyday work, every time someone wonders whether something was part of it.
 
-Ni kommer läsa många och kunden kommer läsa många. Därför är formen fast — samma rubriker i samma ordning varje gång, så att ögat vet var det ska landa — och korthet en regel, inte en ambition.
+You will read many and the customer will read many. That is why the form is fixed (the same headings in the same order every time, so the eye knows where to land) and brevity is a rule, not an ambition.
 
 ---
 
-## Formen
+## The form
 
-Varje spec har exakt de här rubrikerna, i den här ordningen. De tre sista finns bara när de behövs.
+Every spec has exactly these headings, in this order. The last three appear only when needed. Each heading is shown as its Swedish / English literal (see Language below).
 
-**Rubrik** — det förändrade tillståndet, inte uppgiften. "Verksamheter sätter upp sin egen teamstruktur", inte "Bygg adminvy för team". Rubriken är vad kunden prioriterar på i backloggen.
+**Title**: the changed state, not the task. "Verksamheter sätter upp sin egen teamstruktur", not "Bygg adminvy för team". The title is what the customer prioritises on in the backlog.
 
-**Problem** — en eller två meningar om hur det är idag och vad det kostar i vardagen. Bara problemet — vad vi gör åt det står under nästa rubrik.
+**Problem**: one or two sentences on how things are today and what it costs in everyday work. Only the problem; what we do about it goes under the next heading.
 
-**Lösning** — 2–4 meningar som låter läsaren se förändringen framför sig: vad som dyker upp, var, och hur det används. Lösningen som den upplevs, aldrig som den byggs — teknik, datamodell och arbetssteg bor i påverkansanalysen. Ett påstående, inte ett förslag: är lösningen inte vald är posten en Koncept, inte en spec.
+**Lösning** / **Solution**: 2–4 sentences that let the reader picture the change: what appears, where, and how it is used. The solution as it is experienced, never as it is built; technology, data model and work steps live in the impact analysis. A statement, not a proposal: if the solution has not been chosen, the item is a KONCEPT, not a spec.
 
-**När det är klart** — numrerad lista, 2–5 punkter. Varje punkt är något kunden kan konstatera själv efteråt. Inga "eller".
+**När det är klart** / **Done when**: numbered list, 2–5 points. Each point is something the customer can verify for themselves afterwards. No "or" (`eller`).
 
-**Ingår inte** — bara det som rimligen kan missförstås som inkluderat. Oftast en rad, ibland ingen alls.
+**Ingår inte** / **Not included**: only what could reasonably be misunderstood as included. Usually one line, sometimes none at all.
 
-**Utseende** _(vid behov)_ — när posten har en synlig yta: vilket befintligt mönster den följer, eller att den får ett nytt.
+**Utseende** / **Appearance** _(when needed)_: when the item has a visible surface: which existing pattern it follows, or that it gets a new one.
 
-**Kräver** _(vid behov)_ — vad som måste vara klart först.
+**Kräver** / **Requires** _(when needed)_: what must be done first.
 
-**Villkor** _(vid behov)_ — när posten vilar på något vi inte kan verifiera i förväg. "Bygger på att X. Faller det avbryter vi utan kostnad."
+**Villkor** / **Conditions** _(when needed)_: when the item rests on something we cannot verify in advance. "Bygger på att X. Faller det avbryter vi utan kostnad."
 
-### Språk
+### Language
 
-Specen skrivs på önskemålets språk, svenska eller engelska. Rubrikerna tas ur
-tabellen nedan på samma språk som brödtexten, aldrig blandat: kunden ser
-rubrikerna, och en engelsk spec under svenska rubriker läses som ett
-klipp-och-klistra-fel. Granskarblocket är internt och alltid på svenska.
-Formkontrollen känner båda kolumnerna och fäller en spec som blandar dem.
+The spec is written in the request's language, Swedish or English. The headings
+are taken from the table below in the same language as the body text, never
+mixed: the customer sees the headings, and an English spec under Swedish
+headings reads as a copy-paste error. The reviewer block is internal and always
+written in English. Its heading is `## For the reviewer` and its row labels are
+the English ones (`**Assumptions:**`, `**Decisions I made:**`, and so on).
+The form check knows both columns and rejects a spec that mixes them.
 
 | Svenska          | English      |
 | ---------------- | ------------ |
@@ -52,26 +54,26 @@ Formkontrollen känner båda kolumnerna och fäller en spec som blandar dem.
 | Kräver           | Requires     |
 | Villkor          | Conditions   |
 
-### Kandidatform
+### Candidate form
 
-När formen eller orsaken inte går att avgöra utan kunden (designfråga,
-UX-riktning, okänd felorsak) skrivs ingen låtsasspec. Posten skrivs i
-kandidatform: rubriken, en markörrad direkt under den, sedan Problem. Lösning
-och När det är klart finns inte, det är hela poängen: en kandidat har inget
-utfall att lova ännu. Ingår inte, Kräver och Villkor får stå med när de är
-kända.
+When the form or the cause cannot be decided without the customer (a design
+question, UX direction, an unknown cause of a fault), no pretend spec is
+written. The item is written in candidate form: the title, a marker line
+directly under it, then Problem. Solution and Done when do not exist, and that
+is the whole point: a candidate has no outcome to promise yet. Not included,
+Requires and Conditions may be included when they are known.
 
-Markörraden är en av två, som egen fetstilsrad:
+The marker line is one of two, as a bold line of its own:
 
-| Svenska                | English                   | Utfall                                  |
-| ---------------------- | ------------------------- | --------------------------------------- |
-| `**Koncept-kandidat**` | `**Concept candidate**`   | KONCEPT, formen ska tas fram med kunden |
-| `**Diagnos-kandidat**` | `**Diagnosis candidate**` | DIAGNOS, orsaken ska undersökas först   |
+| Svenska                | English                   | Outcome                                                |
+| ---------------------- | ------------------------- | ------------------------------------------------------ |
+| `**Koncept-kandidat**` | `**Concept candidate**`   | KONCEPT, the form must be worked out with the customer |
+| `**Diagnos-kandidat**` | `**Diagnosis candidate**` | DIAGNOS, the cause must be investigated first          |
 
-En kandidat går aldrig till analys eller poängsättning. Formkontrollen läser
-markören och flödet stoppar posten som KONCEPT eller DIAGNOS direkt, så att
-den når kunddialogen utan att kosta en bedömning. Skriver du en kandidat med
-en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
+A candidate never goes to analysis or scoring. The form check reads the marker
+and the flow stops the item as KONCEPT or DIAGNOS directly, so that it reaches
+the customer dialogue without costing an assessment. If you write a candidate
+with a Solution, it is no longer a candidate, and the form check rejects it.
 
 > **Förhandsgranskning visar ändringen innan den publiceras**
 >
@@ -84,27 +86,27 @@ en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
 
 ---
 
-## Reglerna
+## The rules
 
-**Ett beslut per spec.** Kan kunden tänkas vilja säga ja till hälften är det två specar. Hör de ändå ihop levereras de som en bunt — men de skrivs var för sig, för det är på specen kunden svarar.
+**One decision per spec.** If the customer might conceivably want to say yes to half, it is two specs. If they still belong together, they are delivered as a bundle, but they are written separately, because the spec is what the customer answers.
 
-**Lösningen pekar på listan.** Varje mening under Lösning ska motsvara en punkt under När det är klart. En lösningsmening utan punkt är antingen ett utfall som saknas i listan — eller en egen post som smugit sig in.
+**The solution points to the list.** Every sentence under Solution must correspond to a point under Done when. A solution sentence without a point is either an outcome missing from the list, or a separate item that has crept in.
 
-**Inget "eller" i listan.** Behöver en punkt ett _eller_ är beslutet inte fattat, och då är det ingen spec. Det som saknas är antingen ett vägval — då går en Koncept till kunden i stället — eller ett värde någon annan ska bestämma, och då gör vi värdet konfigurerbart så att frågan upphör att vara en fråga.
+**No "or" in the list.** If a point needs an _or_ (`eller`), the decision has not been taken, and then it is not a spec. What is missing is either a choice (then a KONCEPT goes to the customer instead) or a value someone else should decide, and then we make the value configurable so that the question stops being a question.
 
-**Konsekvensen står i listan.** Är något permanent, oåterkalleligt eller ersätter något befintligt hör det till vad kunden får, inte till en not längst ned.
+**The consequence goes in the list.** If something is permanent, irreversible or replaces something existing, it belongs to what the customer gets, not to a note at the bottom.
 
-**Listan är förhandlingsytan.** Vill kunden ned i pris stryker den en punkt, och posten prissätts om. Därför numrerad, därför korta punkter, därför en sak per punkt.
+**The list is the negotiation surface.** If the customer wants a lower price, it strikes a point, and the item is repriced. Hence numbered, hence short points, hence one thing per point.
 
-**Ingen tid, inget pris.** Timmar finns inte i formatet. Pris sätts av analysen och möter kunden i förslaget — aldrig i specen.
+**No time, no price.** Hours do not exist in the format. The price is set by the analysis and meets the customer in the proposal, never in the spec.
 
-**En skärm.** Behöver specen skrollas innehåller den nästan alltid två beslut.
+**One screen.** If the spec needs scrolling, it almost always contains two decisions.
 
 ---
 
-## Exempel
+## Examples
 
-### Minsta möjliga
+### The smallest possible
 
 > **Chefer raderar olämpliga skattningar själva**
 >
@@ -120,7 +122,7 @@ en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
 > 2. Radering kräver en bekräftelse först
 > 3. Raderat går inte att återskapa
 
-### Med beroende
+### With a dependency
 
 > **Verksamheter sätter upp sin egen teamstruktur**
 >
@@ -143,7 +145,7 @@ en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
 > **Kräver**
 > Administratörsvyn för verksamheter.
 
-### Där en öppen fråga blev en inställning
+### Where an open question became a setting
 
 > **Gammal skattningsdata raderas automatiskt**
 >
@@ -162,24 +164,26 @@ en Lösning är det ingen kandidat längre, och formkontrollen fäller den.
 > **Ingår inte**
 > Att återskapa raderad data.
 
-Frågan om gränsen ska gå vid 12, 18 eller 24 månader finns inte i specen. Den blev punkt 2.
+The question of whether the limit should be at 12, 18 or 24 months is not in the spec. It became point 2.
 
 ---
 
-## Öppet
+## Open
 
-- Om Utseende ska vara en rubrik kunden ser eller ett ställningstagande vi bara gör internt
-- Vad som händer med en reviderad spec — ny version eller ny post
-- Hur förslaget (spec + klass + pris) presenteras för kund — nästa steg efter att formatet satt sig
+- Whether Appearance should be a heading the customer sees or a position we only take internally
+- What happens to a revised spec: a new version or a new item
+- How the proposal (spec + class + price) is presented to the customer: the next step once the format has settled
 
 ---
 
-## Kalibreringsexempel: flera specar ur ett önskemål
+## Calibration example: several specs from one request
 
-Rått önskemål (verkligt, förkortat): _"Som medarbetare på en stor verksamhet vill jag kunna ange team för skattningen så att arbetslagen kan följas upp var för sig. Som chef vill jag filtrera statistik per team men även se alla team aggregerat. Ingen team-uppdelning i tv-skärmsläget. Om teams finns ska val vara obligatoriskt. Öppen fråga: team per skattning eller per inloggning?"_
+Raw request (real, abbreviated):
 
-Detta är minst två beslut: medarbetarens skattningsflöde och chefens statistikvy. Tv-skärmsbegränsningen är en "Ingår inte"-rad på statistikspecen, inte en egen spec. Den öppna frågan (per skattning eller per inloggning) är ett vägval som går att avgöra: per skattning är mest sannolikt (matchar hur skift redan fungerar) — väljs och redovisas i granskarblocket. Resultat: två specar + granskarnotis om att de levereras som bunt och delar beroendet till teamadministrationen.
+> _"Som medarbetare på en stor verksamhet vill jag kunna ange team för skattningen så att arbetslagen kan följas upp var för sig. Som chef vill jag filtrera statistik per team men även se alla team aggregerat. Ingen team-uppdelning i tv-skärmsläget. Om teams finns ska val vara obligatoriskt. Öppen fråga: team per skattning eller per inloggning?"_
 
-## Kalibreringsexempel: internt underlag som ska strykas
+This is at least two decisions: the employee's flow for filling in a skattning and the manager's statistics view. The TV screen restriction is a Not included line on the statistics spec, not a spec of its own. The open question (per skattning or per login) is a choice that can be decided: per skattning is most likely (it matches how shifts already work), so it is chosen and stated in the reviewer block. Result: two specs + a reviewer note that they are delivered as a bundle and share the dependency on the team administration.
 
-Råa underlag innehåller ofta interna anteckningar: timestimat ("2-4h"), lösningsanteckningar ("kontrollera att vi gör backup först"), prioritetsmarkeringar ("behöver estimat (prio)"). Inget av detta hör hemma i specen. Estimat och belopp stryks alltid; interna arbetsanteckningar noteras under "Struket ur underlaget" i granskarblocket så att granskaren ser att de fångats och kan flytta dem dit de hör hemma (påverkansanalysen eller ingenstans).
+## Calibration example: internal material to be struck
+
+Raw material often contains internal notes: hour estimates ("2-4h"), solution notes ("kontrollera att vi gör backup först"), priority markings ("behöver estimat (prio)"). None of this belongs in the spec. Estimates and amounts are always struck; internal work notes are recorded under "Struck from the source" in the reviewer block so that the reviewer sees they were caught and can move them where they belong (the impact analysis or nowhere).