GitHub Copilot CLI for beginners: check five acceptance criteria before coding

GitHub Copilot CLI found three implementation gaps and two criteria that looked satisfied. Human review then found a problem in the receipt itself: Copilot called one criterion tested even though the test could not observe the behavior.

That is why this workflow stops before the first code change. You get a fast first pass, check the evidence, and correct the test plan before the agent builds anything.

GitHub Copilot CLI is GitHub's standalone terminal interface for Copilot. Here it gets one narrow task: read a GitHub issue, the implementation, and one existing test with file viewing as the only available tool.

Who is this workflow for?

Picture a product owner with five acceptance criteria for a contact import. The code and one test already exist, but the team does not know which requirements are implemented and genuinely tested. In about 15 minutes, the team can produce a reviewed receipt without starting to code.

You will finish with:

• one raw receipt from Copilot
• a separate reviewed copy with recorded corrections
• five focused next tests
• evidence that the three source files did not change

1. Install GitHub Copilot CLI

Open GitHub's installation guide and choose the method for your computer. With npm, run:

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

The npm installation requires Node.js 22 or later. GitHub also offers Homebrew, WinGet, install scripts, and direct downloads. You need an active Copilot subscription, and an organization can disable CLI access through policy.

On first launch, Copilot may ask you to run /login. Follow GitHub's authentication flow. Never put a token in the prompt or demo folder.

The latest stable release was 1.0.80 when this guide was published. Check the latest GitHub release because commands and availability can change.

2. Create a scoped three-file copy

Create a new folder containing only:

• issue.md with exactly five acceptance criteria
• import-contact.js with the current implementation
• import-contact.test.js with the existing test

Use fictional data. Remove API keys, customer records, build folders, and anything unrelated to the review. The copied folder gives you a practical working boundary, but it is not a complete sandbox.

For a broader treatment of file boundaries, see Hammer's guide to letting AI read a copied folder instead of the whole project.

Save a simple integrity check before the run. In our test, we created an SHA-256 list for the three files and stored it outside the working folder.

3. Run one bounded read

Open your terminal inside the demo folder. Run a single task with view as the only available tool:

copilot -p "<paste the prompt below>" \
  --available-tools=view \
  --no-remote \
  --disable-builtin-mcps \
  --no-custom-instructions

--available-tools=view limits the model's tool surface for this run. It is different from --allow-tool, which controls approvals. The setting is not an operating-system boundary, so you still need the scoped copy and the after-run check.

Copy this prompt:

Read only issue.md, import-contact.js, and import-contact.test.js in this folder. Do not edit files or run commands.

Produce an acceptance-coverage receipt with:
- one sentence defining the scope,
- exactly five numbered criteria in the same order as issue.md,
- for each criterion: current PASS or FAIL, direct evidence from the implementation, whether the existing test covers it (YES or NO), and one next test,
- a source receipt listing the three filenames.

Base every claim only on the three files. Return the receipt in your response and stop there.

Save the response as acceptance-coverage-receipt-raw.md in a separate receipt folder, not beside the three source files.

4. Check each criterion against the sources

Our demo issue required name trimming, rejection of blank names, case-insensitive duplicate detection, preservation of the original email spelling, and no welcome message in dry-run mode.

Copilot's first assessment was useful: three FAIL results and two PASS results by static reading. Yet only one of the five criteria had an existing test that genuinely observed the behavior.

Check four things for every criterion:

1. Does it preserve the meaning of the requirement?
2. Does the cited implementation line really prove PASS or FAIL?
3. Does the test observe the behavior, or does it merely use the same input flag?
4. Is the proposed next test executable and focused on that criterion?

The third question caught the error in our example. The test passed dryRun: true, but it had no spy or injected dependency that could observe the internal welcome sender. Copilot wrote YES. The reviewed copy changed it to NO.

The corrected next test was simple: make the sender observable, run the import with dryRun: true, and assert zero calls.

5. Keep the raw and reviewed receipts

Do not overwrite the AI response. Create acceptance-coverage-receipt-reviewed.md and record every correction.

Our publication run corrected three claims:

• the blank-name test stopped requiring an error message that the issue never specified
• criterion 5's existing coverage changed from YES to NO
• criterion 5's next test was rewritten so it could observe the side effect

Now the receipt can be audited. A colleague can see what Copilot proposed and why the human judgment changed.

6. Confirm that nothing changed

Compare the files with the integrity check you saved before the run. In our fresh test, the SHA-256 lists matched before and after. Copilot CLI 1.0.80 used only the view tool, and the run metadata showed that automatic routing selected claude-haiku-4.5 on that run.

That is a run receipt, not a promise about which model another account will receive. GitHub says automatic model selection can vary with the task, availability, plan, and policy.

Stop here. The receipt should shape the test and implementation plan, not quietly begin a code change.

Common mistakes

• Treating folder approval as if it made the run read-only.
• Writing "do not edit" while leaving edit, shell, and patch tools available.
• Confusing --allow-tool with --available-tools.
• Calling a criterion tested because the test happens to use the same flag.
• Replacing the raw output and losing the record of human corrections.

Once the receipt is reviewed, the next step can be one bounded change with a diff and test. Hammer already has a separate Claude Code guide for that stage of the workflow.

Want to apply the same review in your own repository? Hammer Automation can help scope the issue, tool access, and human check before the first code change.

Source: GitHub Copilot CLI command reference