Apply prompt engineering and context crafting

Why does "fix the bug in this function" get a useful answer in one editor tab and a confused one in another? Because the words you type are only part of what the language model receives. A prompt is the request you make to GitHub Copilot, and in addition to your prompt, Copilot uses additional context, like the code in your current file and the chat history; this guide calls the complete input the model receives for one request the assembled request, and the language model can only reason over information included in its current context. Every technique in this domain controls what that assembled request contains, and the classic exam trap is an answer that assumes the model knows something that never entered it: which code "this" means, a file nobody opened or attached, or a correction made in a different session.

Step one, writing the prompt, is Craft Effective Prompts: reach for it when one prompt produced the wrong result and the fix lies in what you wrote, showed, or attached. It covers the four things a prompt author controls: the request text (goal first, then requirements, with exact names instead of "this"), the surrounding context (open files, selection, attachments), examples (a zero-shot prompt gives instructions with no example completions, meaning sample responses, not Copilot's code suggestions offered as you type; a few-shot prompt adds several examples before the new request), and task scope (how much you ask for at once, in what order). Step two, managing the assembled request across a session, is Engineer Prompts for Performance: reach for it when a question involves how Copilot builds the assembled request, earlier turns, a long or drifting conversation, an agent session (Copilot working through a task itself, as in agent mode), or a second attempt. It covers how Copilot combines context layers such as your message, earlier turns, and the editor state and attachments from step one, the prompt process flow a Copilot Chat request passes through, why every source shares one limit on how much information a model can process in one request (the context window), the four moves for managing chat history (follow-up prompt, delete a turn, compaction, and new session; compaction summarizes older turns to free space), and how to iterate after a miss: redirect a running agent, refine with a follow-up, or restart by rephrasing or splitting the prompt. After a miss the pages meet: step one says which of the four to change, step two how to try again; the tree below picks both page and part.

When two answers both sound reasonable, prefer the one that puts a specific missing piece into the assembled request over the one that adds volume: name the exact function instead of "this", add an important source explicitly instead of relying on the agent to infer that it is relevant, show a representative example when the output shape is the problem, and add the missing constraint in a follow-up instead of resending the same prompt. Removing matters as much as adding, because the user message, conversation history, instructions, referenced files, and tool outputs all use space in the context window. Keeping a failed turn in the history spends that space on material that competes with what the model needs, unrelated open files compete with the useful signals Copilot uses for suggestions as you type, and packing every feature into one prompt hides errors inside one oversized change.