GitHub Copilot Custom Instructions Guide [2026]

GitHub Copilot gætter ofte forkert, når den ikke kender dine kodestandarder. Den forslår JavaScript, selvom teamet kører TypeScript. Den skriver tests uden jeres foretrukne mock-bibliotek, og den foreslår biblioteker, I slet ikke har installeret. Løsningen hedder custom instructions, og siden starten af 2026 er systemet udvidet med flere lag: repository-instruktioner, sti-specifikke regler, personlige præferencer, organisationsregler, genbrugelige prompt-filer og specialbyggede agent-profiler.

Mange udviklere kender kun den enkleste udgave, en enkelt copilot-instructions.md-fil i roden af repositoryet. Det er et fint sted at starte, men det er langt fra det hele billede. Et moderne setup kombinerer flere lag, så reglerne passer præcist til den fil, den udvikler og den opgave, Copilot arbejder med lige nu. Denne guide viser dig, hvordan du sætter alle lagene op fra bunden, trin for trin, med rigtig kode, konkrete fejlmeddelelser og et komplet eksempelprojekt du kan kopiere direkte ind i dit eget repository. Du får også en færdig fejlfindingstabel med otte typiske problemer og de faldgruber, de fleste teams rammer i deres første uge med funktionen.

Hvad er GitHub Copilot custom instructions?

Custom instructions er tekstfiler, Copilot læser automatisk, før den svarer på et chat-spørgsmål eller genererer kode. I stedet for at skrive “brug TypeScript og vores interne fejlhåndtering” i hver enkelt prompt, lægger du den instruktion i en fil, og Copilot anvender den i baggrunden hver gang. Ifølge GitHubs egen dokumentation findes der i dag fem forskellige lag af tilpasning: repository-dækkende instruktioner, sti-specifikke instruktioner, personlige instruktioner, prompt-filer og custom chat modes (også kaldet agent-profiler).

De fem lag løser forskellige problemer. Repository-instruktioner sætter en fast ramme for hele kodebasen, mens sti-specifikke instruktioner kun gælder for bestemte mapper eller filtyper, for eksempel frontend-koden i src/frontend/. Personlige instruktioner følger dig som udvikler, uanset hvilket repository du arbejder i. Prompt-filer er genbrugelige opgavebeskrivelser, du kalder manuelt, når du skal løse en specifik opgave som en API-kodegennemgang. Custom chat modes definerer en hel arbejdsrolle for en agent, komplet med hvilke værktøjer den må bruge.

Status på de fem lag er ikke ens. Repository-instruktioner og personlige instruktioner er dokumenteret som tilgængelige funktioner uden preview-mærkat. Prompt-filer er derimod stadig markeret som public preview i GitHubs dokumentation, mens sti-specifikke instruktioner og custom chat modes er mere versionsafhængige, og opdagelsesreglerne for dem ændrer sig fra udgivelse til udgivelse. Byg derfor din opsætning, så den tjekker GitHubs officielle dokumentation for den nøjagtige status, før du ruller noget ud i et team.

Den praktiske forskel mærkes hurtigst, hvis du har arbejdet med Copilot uden nogen instruktioner overhovedet. Uden kontekst gætter modellen på baggrund af, hvad den ser i den åbne fil og de seneste par beskeder i samtalen. Det virker fint til små, isolerede opgaver, men det falder hurtigt igennem i et større projekt med egne konventioner, interne biblioteker og specifikke krav til fejlhåndtering eller logging. Custom instructions flytter den kontekst fra din hukommelse og over i en fil, som både Copilot og dine kolleger kan læse.

Tænk på det som samme princip som en linter-konfiguration eller en .editorconfig-fil. Ingen af dem tvinger en bestemt kodestil igennem med vold, men de giver et fælles udgangspunkt, så nye medlemmer af teamet ikke skal lære reglerne udenad, før de kan bidrage effektivt. Custom instructions gør noget lignende for Copilots forslag: de reducerer antallet af gange, du skal rette et svar til, fordi modellen allerede havde den kontekst, der ellers skulle forklares igen og igen i hver samtale.

Forudsætninger og versioner, du skal bruge

Før du starter, skal du have styr på fire ting: en Copilot-licens, en opdateret editor, det rigtige repository-setup og adgang til at skrive i .github-mappen. Tabellen nedenfor viser, hvad du som minimum skal bruge for at følge denne guide uden at løbe ind i manglende funktioner.

Komponent	Minimumsversion/krav	Bemærkning
Visual Studio Code	1.110 eller nyere	Introducerer kommandoerne `/create-prompt` og `/create-instruction` i Copilot Chat
GitHub Copilot-abonnement	Individual, Business eller Enterprise	Organisationsinstruktioner kræver Business/Enterprise
GitHub Copilot Chat-extension	Nyeste tilgængelige version	Tjek versionsnummer i VS Code’s Extensions-panel, da funktioner rulles ud gradvist
Repository-adgang	Skriverettighed til `.github`-mappen	Nødvendig for repository- og sti-specifikke instruktioner
Indstilling `chat.promptFiles`	Aktiveret	Skal være sat til `true`, før prompt-filer bliver opdaget

Bemærk at GitHub ikke offentliggør et samlet tal for, hvor mange repositories der allerede bruger disse filer. Undgå at stole på et skøn baseret på en simpel filnavnesøgning på GitHub.com, da private repositories og forks ikke er med i en sådan optælling. Brug i stedet denne guide som en praktisk tjekliste, du selv kan teste på dit eget repository.

Tjek også hvilken Copilot-plan din bruger eller organisation faktisk har, før du lover kolleger funktioner, de ikke kan se. Organisationsinstruktioner og visse administrative kontroller er forbeholdt Business og Enterprise, mens de øvrige fire lag i denne guide, repository-, sti-specifikke, personlige og prompt-filer, er tilgængelige uanset planvalg. Du kan se din plan under din profils Copilot-indstillinger på GitHub.com.

Trin 1-3: opret repository-wide instruktioner

Trin 1. Opret mappen .github i roden af dit repository, hvis den ikke findes allerede. Trin 2. Opret filen copilot-instructions.md inde i den mappe. Stien skal være præcis .github/copilot-instructions.md, ellers finder Copilot den ikke. Trin 3. Skriv dine instruktioner i almindeligt Markdown, som vist herunder.

# .github/copilot-instructions.md

Dette er et Node.js/TypeScript API-projekt. Følg disse regler i alle svar:

- Brug altid TypeScript med strict mode, aldrig ren JavaScript.
- Brug vores interne fejlklasse `AppError` i stedet for generiske `Error`-objekter.
- Al database-adgang går via Prisma, aldrig rå SQL-strenge.
- Skriv unit-tests med Vitest, ikke Jest.
- Kommentarer skal skrives på engelsk, variabelnavne på engelsk.
- Foreslå aldrig biblioteker, der ikke allerede findes i package.json.

Når filen er gemt, skal du åbne Copilot Chat og bekræfte, at reglerne bliver fundet. I VS Code kan du klikke på referencer-ikonet i et chat-svar, hvor copilot-instructions.md nu skal fremgå som en af de kilder, Copilot har brugt. Hvis filen ikke dukker op der, er den sandsynligvis placeret forkert, eller du mangler at genstarte Copilot Chat-sessionen efter oprettelsen.

Repository-instruktioner virker i Copilot Chat i VS Code, i Visual Studio og på GitHub.com, men opsætningen er ikke fuldstændig identisk mellem klienterne. På GitHub.com skal repositoryet typisk være “attached” til samtalen, før reglerne bliver hentet ind, hvilket er en detalje mange overser, når de tester funktionen for første gang i browseren i stedet for i editoren.

Trin 4-6: sti-specifikke instruktioner med applyTo

En fælles instruktionsfil for hele repositoryet er fin, men et monorepo med både frontend og backend har ofte brug for forskellige regler i forskellige mapper. Det er her sti-specifikke instruktioner kommer ind. Trin 4. Opret mappen .github/instructions/. Trin 5. Opret en fil med navnet <navn>.instructions.md, for eksempel frontend.instructions.md. Trin 6. Tilføj et YAML front matter-felt kaldet applyTo, der styrer, hvilke filer reglen gælder for.

---
applyTo: "src/frontend/**/*.ts"
---

# Frontend-specifikke regler

- Brug React 19 funktionelle komponenter, aldrig class-komponenter.
- State håndteres med Zustand, ikke Redux.
- Alle komponenter skal have en tilhørende .test.tsx-fil.
- Styling sker udelukkende via Tailwind-klasser.

Du kan oprette flere af disse filer side om side, en for backend og en for frontend, hver med sit eget applyTo-mønster. Copilot slår automatisk den rigtige fil op, baseret på hvilken fil du aktivt redigerer eller spørger om. Det betyder, at samme repository kan have modstridende stilregler i forskellige mapper, uden at de to regelsæt forstyrrer hinanden.

GitHub advarer selv om, at opdagelsesreglerne for disse filer har ændret sig mere mellem versioner end den stabile konvention for copilot-instructions.md. Test derfor altid filen i din aktuelle VS Code-version, før du lægger den ind i et delt repository, og noter versionsnummeret i jeres interne dokumentation, så kolleger ved, hvilken opsætning der er testet.

Trin 7-8: personlige instruktioner i VS Code

Repository-instruktioner er delt med hele teamet, men nogle præferencer er dine egne, uanset hvilket projekt du åbner. Trin 7. Åbn VS Code’s indstillinger som JSON (Ctrl+Shift+P → “Preferences: Open User Settings (JSON)”). Trin 8. Tilføj dine personlige regler under de relevante Copilot-indstillinger.

{
  "github.copilot.chat.codeGeneration.instructions": [
    { "text": "Forklar altid kort hvorfor en løsning er valgt, ikke kun hvad koden gør." },
    { "text": "Foreslå enhedstests sammen med ny funktionskode, uden at jeg skal bede om det." }
  ],
  "github.copilot.chat.reviewSelection.instructions": [
    { "text": "Ved kodegennemgang: fremhæv sikkerhedsproblemer først, stilproblemer sidst." }
  ]
}

Personlige instruktioner lagres i din brugerprofil, ikke i repositoryet, så de følger dig fra projekt til projekt. Det gør dem velegnede til vaner som “vis mig altid alternative løsninger” eller “brug dansk i forklaringer, men engelsk i kode”. Den nøjagtige indstillingssti kan variere en smule mellem VS Code-versioner, så tjek Settings-UI’et under “Copilot Chat” hvis JSON-nøglerne ovenfor ikke matcher din installerede version præcist.

En anden almindelig brug er at tilpasse svarenes detaljeniveau efter din egen erfaring. En senior-udvikler kan sætte en personlig instruktion, der siger “spring de grundlæggende forklaringer over, fokusér kun på edge cases og ydeevne”, mens en nyere udvikler i samme repository kan have sin egen indstilling med “forklar altid hvorfor, ikke kun hvad”. Fordi reglerne er personlige, kan to udviklere i præcis samme repository få markant forskellige svarstile fra Copilot, uden at nogen af dem skal ændre en delt fil.

Trin 9-10: prompt-filer til genbrugelige opgaver

Instruktionsfiler kører i baggrunden hele tiden. Prompt-filer er det modsatte: de er opgaver, du selv kalder, når du har brug for dem, for eksempel “gennemgå denne API-ændring for sikkerhedsfejl”. Trin 9. Aktivér indstillingen chat.promptFiles i VS Code. Trin 10. Opret en fil i .github/prompts/ med endelsen .prompt.md.

# .github/prompts/review-api.prompt.md

Gennemgå den valgte kode som en sikkerhedsfokuseret code reviewer.
Tjek specifikt for:
1. Manglende input-validering på API-endpoints.
2. Hardkodede secrets eller API-nøgler.
3. SQL- eller NoSQL-injection-risici.
4. Manglende rate limiting på offentlige routes.

Svar med en punktopstilling, sorteret efter alvorlighed.

Du kalder filen direkte fra Copilot Chat ved at skrive /review-api, eller ved at bruge kommandoen /create-prompt, som VS Code 1.110 introducerede til at generere nye prompt-filer direkte fra en chat-session. Husk at GitHub stadig klassificerer hele prompt-fil-funktionen som public preview, hvilket betyder opdagelsesstier og front matter-felter kan ændre sig i kommende udgivelser. Skriv det tydeligt i jeres interne README, så ingen bliver overraskede, hvis en opgradering kræver en mindre justering.

Du kan lægge flere prompt-filer side om side i samme mappe, en til sikkerhedsgennemgang, en til performance-analyse og en til at generere release notes ud fra en liste af commits. Hver fil er fuldstændig uafhængig af de andre, så et team kan bygge sit eget lille bibliotek af kommandoer over tid, uden at nogen fil bliver så stor, at den er svær at overskue. Når en ny udvikler starter på projektet, kan vedkommende se hele biblioteket med et kig i .github/prompts/, i stedet for at skulle spørge en kollega, hvilke genveje teamet plejer at bruge.

Trin 11: custom chat modes og agent-profiler

Trin 11. Det sidste lag er custom chat modes, også kaldt agent-profiler. De definerer en hel arbejdsrolle, inklusive hvilke værktøjer agenten har adgang til. Projektspecifikke profiler lægges typisk i .github/agents/<navn>.agent.md, mens brugerspecifikke profiler gemmes i VS Code’s egen profil-lagring for prompts og agenter.

---
name: test-writer
description: Skriver kun tests, rører aldrig produktionskode
tools: ["read_file", "run_tests"]
---

Du er en test-specialist. Din eneste opgave er at skrive og
forbedre Vitest-tests for den kode, brugeren peger på.
Du må aldrig redigere filer uden for mapperne `src/**/*.test.ts`.
Hvis en test afslører en bug, beskriv bugget i dit svar,
men ret den ikke selv.

Denne type profil er den mest versionsafhængige af de fem lag. Formatet og den nøjagtige mappe-konvention kan ændre sig fra en VS Code-udgivelse til den næste, i takt med at Microsoft og GitHub justerer, hvordan agenter køres lokalt, i baggrunden eller i skyen. Pin derfor altid en specifik VS Code-version i jeres dokumentation, hvis I er afhængige af agent-profiler i et produktionsnært workflow.

Du kan oprette flere agent-profiler til forskellige roller i samme repository, for eksempel en til dokumentation, en til tests og en til selve implementeringen, og derefter vælge mellem dem fra chat-grænsefladen afhængigt af opgaven. Det giver samme fordel som at have flere specialiserede kolleger i stedet for en enkelt generalist: hver profil kan holdes fokuseret, enkel at læse og nem at stole på, fordi dens ansvarsområde er snævert defineret fra starten.

Trin 12: forstå rækkefølgen mellem instruktionstyper

Trin 12. Når flere instruktionslag er aktive samtidig, kombinerer Copilot dem i stedet for at vælge ét vindende lag. Det giver et par faldgruber, hvis du ikke har overblik over, hvilke filer der faktisk bidrager til et givent svar. Tabellen nedenfor opsummerer, hvor hvert lag bor, og hvilken rækkevidde det har.

Instruktionstype	Placering	Rækkevidde	Status
Repository-wide	`.github/copilot-instructions.md`	Hele repositoryet	Tilgængelig
Sti-specifik	`.github/instructions/*.instructions.md`	Filer matchet af `applyTo`	Versionsafhængig
Personlig	VS Code brugerindstillinger	Dig, på tværs af alle repositories	Tilgængelig
Organisation	GitHub-organisationens indstillinger	Alle repositories i organisationen	Kræver Business/Enterprise
Prompt-filer	`.github/prompts/*.prompt.md`	Kaldes manuelt per opgave	Public preview

GitHubs egen dokumentation har en dedikeret sektion om præcis denne rækkefølge, fordi den justeres over tid. Stol derfor ikke blindt på et skærmbillede fra en artikel, du læste for et halvt år siden. Tjek i stedet referencer-panelet i et konkret chat-svar, hvis du er i tvivl om, hvilke filer der faktisk blev brugt til at generere det svar, du sidder med.

En praktisk tommelfingerregel er at behandle de brede lag, organisation og repository, som dem der sætter minimumskravene, og de smalle lag, sti-specifik og personlig, som dem der finpudser detaljerne inden for den ramme. Hvis du opdager et svar, der overrasker dig, er den hurtigste fejlfindingsvej altid at åbne referencer-panelet først og derefter arbejde dig udad fra det konkrete svar til de filer, der faktisk blev inkluderet, i stedet for at gennemgå alle fem lag i hovedet på forhånd.

Organisationsinstruktioner: styring på tværs af virksomheden

Hvis din virksomhed kører Copilot Business eller Enterprise, findes der et sjette niveau, der ligger over det enkelte repository: organisationsinstruktioner. De administreres centralt af en organisationsadministrator på GitHub.com, under organisationens Copilot-indstillinger, og de gælder som udgangspunkt for alle repositories i organisationen, uanset om det enkelte team selv har tilføjet en copilot-instructions.md-fil eller ikke.

Formålet er typisk at sætte virksomhedsbrede standarder, som ikke bør være op til hvert enkelt team at huske, for eksempel krav om at al genereret kode skal overholde interne sikkerhedsretningslinjer, eller at Copilot aldrig må foreslå afhængigheder uden for en godkendt liste af biblioteker. Fordi organisationsinstruktioner virker sammen med, og ikke i stedet for, repository-instruktioner, er det vigtigt at koordinere de to niveauer. En sikkerhedsafdeling, der ejer organisationsreglerne, og et udviklingsteam, der ejer repository-reglerne, bør kende hinandens indhold, så de ikke utilsigtet modsiger hinanden.

I praksis betyder det, at en stor organisation med mange teams får mest værdi ved at holde organisationsniveauet kort og principielt, for eksempel sikkerhed, licensoverholdelse og dataklassificering, og lade de mere tekniske detaljer, som valg af testbibliotek eller mappestruktur, blive liggende på repository- og sti-niveau, hvor det enkelte team selv har ejerskab. Den opdeling gør det også nemmere at fejlfinde, hvis et svar fra Copilot pludselig ser anderledes ud end forventet, fordi du hurtigt kan afgøre, om ændringen kom fra en organisationsregel, en repository-regel eller en personlig indstilling.

VS Code, Visual Studio og GitHub.com: hvor virker hvad

Et spørgsmål, der kommer op igen og igen, er hvorfor en instruktionsfil virker perfekt i VS Code, men opfører sig anderledes, når en kollega tester den samme funktion i browseren på GitHub.com eller i Visual Studio. Svaret er, at de tre klienter deler det samme bagvedliggende filformat, men ikke nødvendigvis den samme brugeroplevelse omkring det.

I VS Code er integrationen tættest. Referencer-panelet viser tydeligt, hvilke instruktionsfiler der er brugt i et givent svar, og kommandoerne /create-prompt og /create-instruction giver dig en hurtig vej til at generere nye filer direkte fra en chat-session, uden at skulle skrive front matter-formatet fra bunden. I Visual Studio er repository-instruktioner understøttet, men den tilhørende tooling til at oprette og administrere prompt-filer og agent-profiler er typisk et skridt bagefter VS Code’s udgivelsescyklus, fordi de to editorer har separate release-tidslinjer.

På GitHub.com er den største forskel kravet om, at repositoryet skal være “attached” til samtalen, før reglerne i copilot-instructions.md bliver anvendt. Mange nye brugere tester funktionen første gang direkte i browseren, ser at reglerne ikke bliver fulgt, og konkluderer fejlagtigt, at opsætningen er forkert, når problemet i virkeligheden bare er en manglende vedhæftning af repositoryet i samtalen. Hvis dit team arbejder i en blanding af editorer, er den enkleste løsning at dokumentere denne forskel ét sted, så alle kender den, før de begynder at fejlfinde fra bunden hver gang.

Trin 13: aktivér Copilot code review med instructions

Trin 13. Repository-instruktioner bruges ikke kun i chat-samtaler. De kan også slås til eller fra specifikt for Copilots indbyggede code review-funktion i pull requests. Gå til repositoryets Copilot-indstillinger på GitHub.com, find sektionen for code review, og bekræft at “brug repository custom instructions” er aktiveret, hvis du ønsker, at automatiske PR-gennemgange skal følge samme regler som chat-samtalerne.

Det er en separat kontakt fra selve filen. Mange teams opretter en fin copilot-instructions.md, men glemmer at slå den til for code review-flowet, og bliver så forundrede, når PR-kommentarerne ikke matcher de regler, de lige har skrevet. Tjek den indstilling som et fast punkt, hver gang I opdaterer instruktionsfilen væsentligt.

Når indstillingen er aktiveret, vil Copilots automatiske kommentarer på en pull request begynde at afspejle de samme prioriteter, du har skrevet ind i filen. Hvis copilot-instructions.md for eksempel beder om, at databaseadgang altid går via Prisma, vil en PR med rå SQL-forespørgsler nu typisk få en kommentar om netop det, i stedet for kun generiske stilbemærkninger. Det gør code review-funktionen markant mere nyttig for teams, der allerede har investeret tid i en god instruktionsfil.

Komplet eksempelprojekt: sæt det hele sammen

Herunder er den fulde mappestruktur for et lille Node.js/TypeScript API-projekt, der bruger alle fem lag samtidig. Kopier strukturen direkte ind i et nyt eller eksisterende repository, og udfyld filerne med dine egne regler.

mit-api-projekt/
├── .github/
│   ├── copilot-instructions.md          # Repository-wide regler
│   ├── instructions/
│   │   ├── frontend.instructions.md     # applyTo: src/frontend/**
│   │   └── backend.instructions.md      # applyTo: src/backend/**
│   ├── prompts/
│   │   └── review-api.prompt.md         # Manuel sikkerheds-review
│   └── agents/
│       └── test-writer.agent.md         # Agent der kun skriver tests
├── src/
│   ├── frontend/
│   └── backend/
├── .vscode/
│   └── settings.json                    # chat.promptFiles: true
└── package.json

Tilføj denne linje til .vscode/settings.json, så prompt-filerne bliver delt med alle, der åbner projektet i VS Code, i stedet for kun at virke på din egen maskine:

{
  "chat.promptFiles": true
}

Med den struktur på plads har du et fuldt fungerende setup: faste regler for hele projektet, forskellige regler for frontend og backend, en genbrugelig sikkerhedsgennemgang du kan kalde på kommando, og en begrænset agent, der kun må røre testfiler. Commit hele .github-mappen til versionsstyring, så reglerne følger med repositoryet og ikke kun findes på din lokale maskine.

Test opsætningen i den rigtige rækkefølge, før du erklærer den klar til resten af teamet. Åbn først en fil i src/backend/ og spørg Copilot Chat om en simpel opgave, og tjek i referencer-panelet at backend.instructions.md og den repository-wide fil begge dukker op. Skift derefter til en fil i src/frontend/, og bekræft at det nu i stedet er frontend.instructions.md, der bliver inkluderet. Kald til sidst /review-api manuelt på en tilfældig fil, for at bekræfte at prompt-filen er opdaget korrekt. De tre hurtige tests fanger de fejl, der ellers først viser sig, når en kollega støder ind i dem flere dage senere.

5 almindelige faldgruber

Forkert filplacering. Filen hedder ikke “copilot_instructions.md” med underscore, eller ligger i roden uden .github-mappe. Stien skal matche eksakt, ellers bliver filen stille ignoreret uden nogen synlig fejlmelding, og du bruger timer på at fejlsøge indholdet, når problemet rent faktisk bare er stavningen af filnavnet.
For lange instruktioner. En instruktionsfil på flere tusind ord drukner de vigtige regler i støj, og modellen har sværere ved at veje alle punkter lige vigtigt. Hold hver fil fokuseret på et klart afgrænset emne, og flyt resten til en sti-specifik fil, så hver fil kan læses og vedligeholdes på under et minut.
Modstridende regler i flere lag. Hvis den personlige instruktion siger “brug Jest” og repository-filen siger “brug Vitest”, får du uforudsigelige svar, der skifter afhængigt af hvilken fil du spørger om. Tjek referencer-panelet, når noget virker forkert, i stedet for at gætte dig frem til, hvilken fil der vandt.
Glemt aktivering af code review-flaget. Som nævnt i trin 13 er chat-brug og PR-gennemgang to separate kontakter i GitHubs indstillinger. Mange teams opdaterer kun den ene og bliver forundrede, når automatiske PR-kommentarer stadig ignorerer regler, de troede var aktive for hele repositoryet.
Forventning om GA-stabilitet i preview-funktioner. Prompt-filer og agent-profiler er stadig under aktiv udvikling, og opdagelsesstier kan ændre sig fra en udgivelse til den næste. Byg ikke et kritisk CI/CD-flow, der er fuldstændig afhængigt af, at en preview-fil altid opdages på præcis samme måde efter en opdatering af VS Code eller Copilot Chat.

Fejlfinding: 8 problemer og løsninger

De fleste problemer med custom instructions falder i en af tre kategorier: filen bliver ikke fundet, filen findes men bliver overskrevet af et andet lag, eller funktionen er stadig i preview og opfører sig lidt anderledes end forventet efter en opdatering. Gennemgå listen nedenfor, før du antager, at selve indholdet i instruktionsfilen er problemet, da langt de fleste sager i praksis handler om placering, aktivering af en indstilling, eller et lag der vinder over et andet.

Problem	Sandsynlig årsag	Løsning
Copilot ignorerer copilot-instructions.md	Filen ligger ikke i `.github/`-roden	Flyt filen til eksakt sti `.github/copilot-instructions.md`
Instruktioner virker lokalt, men ikke på GitHub.com	Repositoryet er ikke “attached” til chat-samtalen	Vedhæft repositoryet manuelt i Copilot Chat-panelet på GitHub.com
Prompt-fil dukker ikke op med skråstreg-kommando	`chat.promptFiles` er ikke aktiveret	Sæt indstillingen til `true` og genstart VS Code
applyTo matcher ikke filerne	Forkert glob-mønster i front matter	Test mønsteret separat, brug dobbelte asterisker for dybe mapper, fx `*/.ts`
Personlige instruktioner virker ikke i alle projekter	Indstillingen er sat i workspace-settings i stedet for user-settings	Flyt JSON-blokken til “Open User Settings (JSON)”, ikke workspace-filen
Agent-profil starter ikke korrekt	Forkert eller forældet front matter-felt	Sammenlign med den nyeste dokumentation for din VS Code-version
PR-gennemgang følger ikke reglerne	Code review-flaget for repository-instruktioner er slået fra	Aktivér det i repositoryets Copilot-indstillinger på GitHub.com
Instruktioner forsvinder efter opgradering	GitHub har ændret en preview-funktions opdagelsessti	Tjek release notes for VS Code og Copilot Chat efter hver opdatering

Når du fejlfinder, er den mest effektive metode altid at starte med referencer-panelet i et konkret chat-svar, før du begynder at gætte på, hvilken fil der er problemet. Panelet viser præcis, hvilke instruktionsfiler Copilot har trukket ind i det specifikke svar, og i de fleste af problemerne ovenfor er svaret enten “filen var der slet ikke” eller “en anden fil vandt over den, du forventede”. Begge situationer løses hurtigere, når du har det konkrete bevis frem for at ændre filer på må og få.

Avancerede tips til teams

Når flere udviklere deler samme repository, betaler det sig at behandle instruktionsfilerne som almindelig kode. Kør dem gennem jeres normale PR-proces, og lad en kollega godkende ændringer i copilot-instructions.md, ligesom I ville med en ændring i CI-konfigurationen. Det forhindrer, at en enkelt udvikler stille ændrer hele teamets AI-adfærd uden diskussion.

Opdel store instruktionsfiler i flere mindre, sti-specifikke filer, i stedet for at proppe alt ind i en enkelt lang copilot-instructions.md. Et monorepo med fem services kører bedre med fem fokuserede filer under .github/instructions/ end med én fil, der forsøger at dække det hele på én gang. Resultatet er, at Copilot kun læser den kontekst, der faktisk er relevant for den fil, du arbejder i.

Byg et lille internt prompt-fil-bibliotek til de opgaver, teamet løser oftest: sikkerhedsgennemgang, performance-review, migrering til en ny versionsstandard, eller generering af changelog-tekst. Når en prompt-fil har vist sin værdi i et projekt, kan den kopieres direkte over i et andet repository, fordi formatet er det samme overalt. Dokumentér i jeres interne wiki, hvilken VS Code-version og Copilot Chat-version I har testet hver fil imod, så fejlfinding bliver nemmere, når noget ændrer sig i en fremtidig udgivelse.

Behandl indholdet af instruktionsfilerne som noget, der kan læses af enhver med adgang til repositoryet, også selvom det kun er internt. Skriv ikke hemmeligheder, interne systemnavne for sikkerhedsinfrastruktur eller andre følsomme detaljer direkte i copilot-instructions.md, selv hvis repositoryet i dag er privat. Filer af den type har en tendens til at blive kopieret til nye projekter af bekvemmelighed, og en detalje, der var uskadelig i den oprindelige sammenhæng, kan ende et sted, hvor den ikke burde være.

Overvej at lave en særlig agent-profil med stærkt begrænsede værktøjer til juniorudviklere eller til automatiserede CI-opgaver, hvor du ikke ønsker, at agenten frit kan redigere produktionskode. test-writer-eksemplet tidligere i denne guide er et simpelt eksempel på princippet: giv agenten præcis det, den skal bruge til sin opgave, og intet mere. Læs mere om de bagvedliggende VS Code-funktioner i VS Code’s officielle dokumentation om Copilot-tilpasning og i guiden til prompt-crafting.

Sæt desuden et fast punkt på jeres sprint-retro eller teammøde, hvor I kort gennemgår, om instruktionsfilerne stadig matcher den måde, koden faktisk skrives på. Et projekt, der skifter fra Jest til Vitest, eller fra Redux til Zustand, glemmer ofte at opdatere den tilsvarende instruktionsfil, og så ender Copilot med at foreslå et bibliotek, teamet allerede har lagt bag sig. Da filerne ligger som almindelig Markdown i repositoryet, er det samme proces som at opdatere en README, bare med en direkte effekt på, hvad en AI-assistent forslår fremover.

Endelig kan det være en god idé at måle effekten, i stedet for bare at antage den. Følg i en periode, hvor mange Copilot-forslag et par udviklere accepterer uden ændringer, før og efter I indfører en ordentlig copilot-instructions.md. Det er en simpel, uformel måling, men den giver et konkret signal om, om investeringen i opsætningen rent faktisk sparer redigeringstid, i stedet for blot at være endnu en fil i repositoryet, som ingen husker at holde ved.

Output-eksempel: før og efter custom instructions

Forskellen er lettest at se i praksis. Spørger du Copilot om “skriv en funktion, der henter en bruger fra databasen” uden nogen instruktionsfil, får du typisk et generisk svar som dette, hvor modellen gætter sig til en vilkårlig kombination af rå SQL og generisk fejlhåndtering:

// Output UDEN custom instructions:
async function getUserById(id) {
  const result = await db.query("SELECT * FROM users WHERE id = ?", [id]);
  if (!result) {
    throw new Error("User not found");
  }
  return result;
}

Koden virker måske teknisk, men den bruger rå SQL i stedet for Prisma, en generisk Error i stedet for jeres interne AppError, og ingen TypeScript-typer. Med copilot-instructions.md fra trin 1-3 aktiv, matcher svaret automatisk jeres faktiske stack, uden at du skrev noget af det i selve spørgsmålet.

// Output MED aktive custom instructions:
import { prisma } from "../db/client";
import { AppError } from "../errors/AppError";

export async function getUserById(id: string) {
  const user = await prisma.user.findUnique({ where: { id } });
  if (!user) {
    throw new AppError("USER_NOT_FOUND", `Ingen bruger med id ${id}`);
  }
  return user;
}

Bemærk at svaret respekterer både Prisma-reglen og den interne AppError-klasse fra instruktionsfilen, uden at du skrev det i selve spørgsmålet. Det er den praktiske værdi af hele opsætningen: mindre tid på at rette Copilots forslag til, mere tid på selve opgaven.

Ofte stillede spørgsmål

Skal jeg bruge alle fem lag på samme tid?
Nej. De fleste projekter får det meste af værdien ud af bare copilot-instructions.md og én eller to sti-specifikke filer. Tilføj prompt-filer og agent-profiler, når du har et konkret, tilbagevendende behov for dem.

Virker custom instructions i JetBrains IDE’er eller Visual Studio?
Repository-instruktioner er dokumenteret til at virke i Copilot Chat i VS Code, Visual Studio og på GitHub.com. Detaljerne i opsætningen og den nøjagtige funktionsdækning kan variere mellem klienterne, så test altid i den editor, dit team faktisk bruger.

Hvorfor er prompt-filer stadig i preview så lang tid?
GitHub klassificerer stadig hele funktionen som public preview i sin dokumentation. Det betyder, at filformat og opdagelsesstier kan justeres, før funktionen bliver fuldt stabil, og det er grunden til, at man bør undgå at bygge kritiske automatiseringer, der er helt afhængige af den.

Kan en kollega overskrive mine personlige instruktioner?
Nej. Personlige instruktioner ligger i din egen brugerprofil i VS Code, ikke i repositoryet, så kolleger kan ikke ændre dem via en commit. Repository- og sti-specifikke instruktioner er derimod delt kode, som alle med skriverettighed kan ændre.

Hvordan ved jeg, hvilken instruktionsfil Copilot faktisk brugte?
Åbn referencer-ikonet på et konkret svar i Copilot Chat. Der listes de filer, Copilot har trukket kontekst fra i det pågældende svar, hvilket er den mest pålidelige måde at fejlfinde på, hvis en regel ikke ser ud til at blive fulgt.

Skal copilot-instructions.md committes til Git?
Ja. Hele pointen med repository-instruktioner er, at de deles med alle, der arbejder i projektet. Commit filen sammen med resten af koden, og behandl ændringer i den som enhver anden kodeændring, inklusive code review.

Kan jeg bruge custom instructions til at tvinge et bestemt sprog i svarene?
Ja, du kan skrive en regel som “svar altid på dansk” i en instruktionsfil, og Copilot vil forsøge at følge den i både chat-svar og kodekommentarer, afhængigt af hvad du specificerer.

Hvad sker der, hvis to sti-specifikke filer begge matcher den samme fil?
Begge filers regler bliver taget i betragtning samtidig, da systemet kombinerer relevante instruktioner i stedet for at vælge én vinder. Undgå derfor overlappende applyTo-mønstre, der modsiger hinanden, da det gør adfærden svær at forudsige.

Er organisationsinstruktioner relevante for et lille team?
Sandsynligvis ikke. Funktionen kræver Copilot Business eller Enterprise og giver mest værdi, når flere teams og repositories skal følge samme centrale regler. Et enkelt team med et enkelt repository får typisk mere ud af at starte med repository- og sti-specifikke instruktioner.

Kan jeg teste ændringer i en instruktionsfil, før de rammer resten af teamet?
Ja. Lav ændringerne på en feature-branch og åbn en pull request, ligesom med al anden kode. Test dine egne chat-spørgsmål mod branchen lokalt, og brug referencer-panelet til at bekræfte, at den opdaterede fil faktisk bliver brugt, før du merger ændringen ind i hovedbranchen.

GitHub Copilot Custom Instructions: 13 Trin, 50 Min [2026]