GitHub Copilot CLI för nybörjare: granska fem acceptanskriterier innan du kodar

GitHub Copilot CLI hittade tre luckor i implementationen och två krav som såg uppfyllda ut. Sedan hittade den mänskliga granskningen ett problem i själva kvittot: Copilot kallade ett krav testat fast testet inte kunde observera beteendet.

Det är precis därför den här arbetsgången slutar före första kodändringen. Du får ett snabbt första underlag, kontrollerar bevisen och rättar testplanen innan agenten får bygga något.

GitHub Copilot CLI är GitHubs fristående terminalgränssnitt för Copilot. Här får det en smal uppgift: läs ett GitHub-ärende (issue), implementationen och ett befintligt test med filvisning som enda tillgängliga verktyg.

För vem passar arbetsgången?

Tänk dig att en produktägare har skrivit fem acceptanskriterier för en kontaktimport. Koden och ett test finns redan, men ingen vet säkert vilka krav som faktiskt är implementerade och testade. På ungefär 15 minuter kan teamet få ett granskat kvitto utan att börja koda.

Efteråt har du:

• ett råkvitto från Copilot
• en separat granskad kopia med dokumenterade rättelser
• fem tydliga nästa testfall
• bevis på att de tre källfilerna inte ändrades

1. Installera GitHub Copilot CLI

Gå till GitHubs installationsguide och välj den metod som passar din dator. Med npm använder du:

npm install -g @github/copilot
copilot --version

Npm-installationen kräver Node.js 22 eller senare. GitHub erbjuder också Homebrew, WinGet, installationsskript och direkta nedladdningar. Du behöver en aktiv Copilot-prenumeration, och en organisation kan stänga av CLI-åtkomst genom policy.

Vid första starten kan Copilot be dig köra /login. Följ GitHubs inloggningsflöde. Lägg aldrig en token i prompten eller i demo-mappen.

När den här guiden publicerades var den senaste stabila versionen 1.0.80. Kontrollera alltid den senaste GitHub-versionen. Kommandon och åtkomst kan ändras.

2. Skapa en avgränsad kopia med tre filer

Skapa en ny mapp som bara innehåller:

• issue.md med exakt fem acceptanskriterier
• import-contact.js med den nuvarande implementationen
• import-contact.test.js med det befintliga testet

Använd påhittade data. Ta bort API-nycklar, kunduppgifter, byggmappar och allt som inte behövs för granskningen. Den kopierade mappen är en praktisk arbetsgräns, men inte en fullständig sandbox.

Om du vill arbeta mer systematiskt med filgränser finns en separat guide om att låta AI läsa en kopierad mapp i stället för hela projektet.

Spara en enkel kontroll av filerna före körningen. I vårt test skapade vi en SHA-256-lista över de tre filerna och sparade den utanför arbetsmappen.

3. Kör en avgränsad läsning

Öppna terminalen i demo-mappen. Kör ett enda uppdrag med view som enda tillgängliga verktyg:

copilot -p "<klistra in prompten nedan>" \
  --available-tools=view \
  --no-remote \
  --disable-builtin-mcps \
  --no-custom-instructions

--available-tools=view begränsar modellens verktygsyta i den här körningen. Det är något annat än --allow-tool, som handlar om godkännanden. Inställningen är inte ett operativsystemsskydd, så den avgränsade kopian och kontrollen efteråt behövs fortfarande.

Kopiera den här prompten:

Läs bara issue.md, import-contact.js och import-contact.test.js i den här mappen. Ändra inga filer och kör inga kommandon.

Skapa ett kvitto över hur väl koden täcker acceptanskriterierna. Kvittot ska innehålla:
- en mening om omfattningen,
- exakt fem numrerade kriterier i samma ordning som i issue.md,
- för varje kriterium: nuvarande PASS eller FAIL, direkt bevis från implementationen, om det befintliga testet täcker kravet (JA eller NEJ) och ett nästa test,
- en källförteckning med de tre filnamnen.

Grunda varje påstående enbart i de tre filerna. Returnera kvittot i svaret och stanna där.

Spara svaret som acceptance-coverage-receipt-raw.md i en separat kvittomapp, inte bland de tre källfilerna.

4. Granska varje krav mot källorna

Vårt demoärende krävde trimning av namn, avvisning av tomma namn, skiftlägesoberoende dubblettkontroll, bevarad stavning av e-postadressen och inget välkomstmeddelande i dry-run-läge.

Copilots första bedömning var användbar: tre FAIL och två PASS vid statisk läsning. Men bara ett av fem krav hade ett befintligt test som faktiskt observerade beteendet.

Kontrollera därför fyra saker för varje kriterium:

1. Är kravet återgivet utan att betydelsen har ändrats?
2. Visar den citerade kodraden verkligen PASS eller FAIL?
3. Observerar testet beteendet, eller råkar det bara använda samma parameter?
4. Går det föreslagna nästa testet att köra och koppla till just det kravet?

Den tredje frågan fångade felet i vårt exempel. Testet skickade dryRun: true, men det hade ingen spy eller beroendeinjektion som kunde se om den interna välkomstfunktionen anropades. Copilot skrev JA. Den granskade kopian ändrade till NEJ.

Det rättade nästa testet blev: gör avsändaren observerbar, kör importen med dryRun: true och kontrollera att antalet anrop är noll.

5. Behåll både råkvitto och granskad kopia

Skriv inte över AI-svaret. Skapa i stället acceptance-coverage-receipt-reviewed.md och notera varje ändring.

I vår publiceringskörning rättades tre påståenden:

• testet för ett blankt namn krävde inte längre ett felmeddelande som ärendet aldrig hade specificerat
• testtäckningen för kriterium 5 ändrades från JA till NEJ
• nästa test för kriterium 5 skrevs om så att sidoeffekten faktiskt kan observeras

Det gör kvittot granskningsbart. En kollega kan se både vad Copilot föreslog och varför den mänskliga bedömningen ändrades.

6. Kontrollera att inget ändrades

Jämför filerna med kontrollen du sparade före körningen. I vårt färska test var SHA-256-listorna identiska före och efter. Copilot CLI 1.0.80 använde bara verktyget view, och körningens metadata visade att automatisk modellstyrning valde claude-haiku-4.5 just då.

Det är ett körningskvitto, inte ett löfte om vilken modell andra konton får. GitHub beskriver automatisk modellstyrning som beroende av uppgift, tillgänglighet, plan och policy.

Stanna här. Kvittot ska forma test- och implementationsplanen, inte smygstarta en kodändring.

Vanliga misstag

• Att lita på mappgodkännandet som om det gjorde körningen skrivskyddad.
• Att skriva "ändra inget" i prompten men lämna edit-, shell- och patchverktyg tillgängliga.
• Att blanda ihop --allow-tool med --available-tools.
• Att kalla ett krav testat bara för att testet använder samma flagga.
• Att ersätta råsvaret och därmed tappa spåret av mänskliga rättelser.

När kvittot är granskat kan nästa steg vara en enda avgränsad ändring med diff och test. Hammer har redan en separat Claude Code-guide om den delen av arbetsflödet.

Vill ni prova samma granskning i ett eget repo? Hammer Automation kan hjälpa er avgränsa ärendet, verktygen och den mänskliga kontrollen före första kodändringen.

Källa: GitHub Copilot CLI-kommandoreferensen