GitHub Copilot Deep Dive: Prompting for Code Suggestions

GitHub Copilot is a different kind of AI tool. It does not chat with you — it watches what you write and tries to finish it. That means your prompt is not just what you type into a box; it is the entire file, the open tabs, the function name, and the comment you wrote three lines up. This deep dive shows you how to control all of that intentionally.

Note: GitHub Copilot evolves quickly — slash commands, chat features and model choices change. Refer to the official GitHub Copilot documentation for current behaviour.

1. Introduction

Copilot was the first widely-used AI coding assistant and it remains the benchmark. It lives inside your IDE (VS Code, JetBrains, Neovim, Visual Studio) and offers two main surfaces: inline suggestions (ghost-text completions you accept with Tab) and Copilot Chat (a sidebar conversation aware of your code). Each surface has its own prompting style, and a senior engineer uses them very differently from a beginner.

This tutorial covers comment-driven prompting, naming as a prompt signal, the Copilot Chat slash-command vocabulary, and the workflows that turn Copilot from a clever autocomplete into a productive pair-programmer.

2. The Hidden Prompt: What Copilot Actually Sees

When you press a key and a grey suggestion appears, Copilot has already silently assembled a prompt out of your editor state. That prompt usually includes:

• The file you are editing — especially the lines just before your cursor.
• A handful of nearby open tabs (recently used files in the same project).
• Your filename and the project's language clues (imports, framework markers).
• Any comments, docstrings, or type signatures near the cursor.

You shape this hidden prompt every time you write a comment, name a variable, or open another tab. That is the core insight: everything in your editor is part of your Copilot prompt.

3. Comment-Driven Prompting

The most powerful inline-suggestion technique is to write a short, specific comment before the line you want generated. Treat the comment like a tiny prompt — role, task, constraints, format.

// parse the data
function parseData(input) {

// Parse a CSV string with headers: id,name,email.
// Return an array of objects keyed by header.
// Trim whitespace. Skip blank lines. Throw if a row
// has the wrong number of columns.
function parseUsersCsv(input) {

4. Naming and Type Signatures as Prompts

Copilot reads function names, parameter names, and types as signals. A function called retryWithExponentialBackoff(fn, maxAttempts) nudges Copilot toward a specific implementation. A typed parameter (orders: Order[]) tells it the data shape better than any comment. Two practical habits:

• Name first, body second. Type the full descriptive function signature, then pause. Copilot will often draft a credible body.
• Use rich types. In TypeScript or Python, define the input/output types explicitly. Copilot uses them to constrain its suggestion.

5. Copilot Chat: Slash Commands and Context Variables

Copilot Chat is where you reach for natural language. It has a specific vocabulary worth memorising — slash commands and the # context variables let you scope a request to the right code.

• /explain — explain the selected code in plain English.
• /fix — propose a fix for the selected code or the current error.
• /tests — generate tests for the selected function.
• /doc — generate or improve docstrings.
• /optimize — suggest a more efficient version.
• #file, #selection, #editor, #terminalLastCommand — explicitly attach context.

/tests #selection

Write Jest tests for the selected function. Cover:
- Happy path with 3 valid users.
- Empty input returns an empty array.
- Malformed row throws CsvParseError.
- Whitespace in fields is trimmed.

Use describe/it. No snapshot tests. Mock nothing.

6. Patterns Senior Engineers Use

• Open the right tabs. Before working on a feature, open the related files (types, fixtures, neighbouring modules). Copilot's suggestions improve dramatically when relevant code is in nearby tabs.
• Write the test first. Type out a failing unit test with clear expectations. Then go to the implementation file — Copilot often produces the function body that makes the test pass.
• Keep one example nearby. If you have a similar function in the same file, Copilot will mirror its style — naming, error handling, return shape.
• Refuse the first guess. Press Alt/Option+] to cycle suggestions. The second or third is often better than the first.
• Use Chat for design, inline for filling. Ask Copilot Chat for an approach or skeleton, then accept inline suggestions as you fill it in.
• Never accept blindly. Copilot can invent plausible-looking APIs that do not exist. Treat every suggestion as a draft to review.

7. Practice Exercises

8. Key Takeaways