GitHub Copilot Prompts: Comments, Context, and Chat

A developer writes // calculate the total above an empty function. Copilot suggests ten lines that add up the prices, without VAT, without the loyalty discount, using floats where the project uses whole cents. The code compiles and it's wrong, because the comment was the only information given.

GitHub Copilot is steered in three ways: what you write in the file, what you ask it in the chat, and the rules you set for the whole repository. Each has its own reflexes.

Inline suggestions: the comment is your prompt

When Copilot completes your code as you type, it relies on what surrounds the cursor: the function name, the open files, the comments. An explicit name and a comment describing the behavior are worth more than a long preamble.

Compare these two function openings.

// calculate the total
function total(items) {

// Total of a cart in cents (integers).
// Applies the 5% loyalty discount if customer.isLoyal is true,
// then adds 20% VAT. Rounded down to the cent.
// Empty cart: returns 0.
function cartTotal(items, customer) {

The second states the unit, the order of operations, the rounding, and the edge case. Copilot no longer has to guess. If you're not sure of the business rule, don't ask the code to guess it for you: write it down first.

Two habits also help. Keep open the files that show how the project does things (a neighboring module, an existing test), because they serve as examples. And review every suggestion before accepting it, especially the longest ones: accepting ten lines at once that you haven't read is writing code that nobody understands.

Chat: choose what it sees

In chat, the quality of the answer depends on what Copilot has in front of it. Depending on your editor, it can see the open file, the code you've selected, and the files you explicitly add to the context (in Visual Studio Code, for example, by naming them with #). Look at what your interface offers, because the options change from one editor to another.

The useful reflex is to select the relevant code before asking your question. An example request to fix a bug:

The selected function returns 0 for a cart of two items when the customer is loyal. Without the discount it gives the right total.

Find the cause, explain it in two sentences, then propose the smallest possible fix. Don't rewrite the rest of the function and don't change its signature.

"The smallest possible" protects your commit history. Without that limit, the tool will happily reorganize the whole file, and the code review becomes a nightmare.

For common tasks, commands like /explain, /fix, or /tests exist in the chat of several editors. They save you from rewriting the same request, but add a sentence of constraints. For example, after /tests:

Write the tests for the selected function with the framework already used in the tests/ folder. Cover the empty cart, the loyal customer, a price of zero, a rounding that falls between two cents. One test per case, with a name that describes the case.

Then run the tests. A test Copilot wrote can pass because it verifies what the code does, not what it should do. Reread the expected values one by one.

Project rules: an instructions file

Tired of repeating "we use whole cents" and "no new dependency without discussing it"? GitHub lets you put a .github/copilot-instructions.md file in the repository, written in Markdown and natural language. Copilot reads it for requests concerning that repository. Support varies by editor and feature, so look at GitHub's documentation for your case.

# Project rules

- Amounts are integers in cents. Never floats for money.
- Tests with Vitest, in the tests/ folder, one file per module.
- Don't add a dependency without flagging it in your answer.
- User-facing error messages are in French, code names in English.

Keep this file short and checkable. Ten precise rules are worth more than three pages of principles, and a rule you never reread ends up contradicting the code. The same reasoning applies to system instructions and to agent instructions: write what a new colleague should know on day one.

What Copilot doesn't know

It doesn't know your architecture decisions, your bug history, or the rules that live in the team's heads. It can also suggest a function from a library that doesn't exist or syntax from an old version. If a suggestion uses a call you don't recognize, open the library's documentation before continuing.

Also think about the content of your code: access keys, passwords, customer data. Don't put them in a comment or in the chat, and read the terms of your plan and your employer's rules on sending code to an outside service. The basics of review and debugging with an AI are in our article on prompts for developers.

To try today

Take the next function you're about to write. Before typing the first line, write its complete behavior as a comment: inputs, outputs, one edge case. See what Copilot suggests, then fix the comment, not the code, if the suggestion strays from what you wanted.