Apply Prompt Engineering and Context Crafting Study Guide — GH-300

Apply Prompt Engineering and Context Crafting

This domain is worth 13% of GH-300 — roughly 8–10 scored items on a typical form. It is the most "hands-on" domain in the exam: questions are written as short IDE scenarios ("a developer has three files open and selects a function…") and you must pick the prompt, the chat variable, or the context action that produces the best result. You are tested on four things: (1) the anatomy of an effective prompt (goal, context, expectations, source), (2) how Copilot assembles context automatically from the current file, neighboring tabs, comments, and chat history, (3) the named techniques — zero-shot, one-shot, few-shot, chain-of-thought, iterative refinement — and (4) the explicit context controls: chat variables (#file, #selection, #editor, #terminalLastCommand), chat participants, slash commands, custom instructions, and session hygiene. Expect precise wording: the exam distinguishes #editor from #file, a variable from a participant, and zero-shot from few-shot on the presence of worked examples, not on prompt length.

Prompt structure and context: what goes into an effective prompt

GitHub's documented prompt anatomy has four components. Memorize the names and the order, because items ask "which element is missing from this prompt?"

Two more properties the exam treats as part of structure:

• Scope — one prompt, one task. Multi-task prompts are a documented anti-pattern (see the 4 S's below).
• Placement — for code completion, the prompt is the surrounding code: a top-of-file comment describing the module's purpose, meaningful identifiers, plus an immediately preceding comment describing the next function. For Copilot Chat, the prompt is the message plus any attached/referenced context.

Copilot never receives only your typed words. The final request sent to the model is a constructed prompt: your text + automatically gathered context + (optionally) custom instructions + retrieved snippets. "Context crafting" on the exam means deliberately controlling that assembly.

What this diagram shows: the context sources Copilot merges into the single prompt sent to the model.

Common traps

• Treating the prompt as only the typed sentence. Distractors claim Copilot "only sees what you type." False — it always gathers file and editor context.
• Assuming longer is better. The exam rewards specific, not verbose. A prompt that names the file, framework, and return type beats a three-paragraph essay.
• Confusing "context" with "source." Context is the environment/constraints; source is the concrete artifact to read (a file, a schema, examples).
• Believing you must restate what's already in the open file. If the file is open and relevant, Copilot already has it; restating wastes context window.
• Options that say "include the entire repository in every prompt" are always wrong — context windows are finite and noise degrades quality.

Worked scenario

Requirement: A developer types "fix this" in Copilot Chat with no selection and 12 unrelated files open. Output is generic. What is the single best correction?

Reasoning: The prompt lacks goal specificity and source. The strongest fix is to select the offending code and reference it (#selection, or use inline chat with /fix), because that supplies both the source and narrows intent. "Open more files" adds noise; "write a longer sentence" doesn't identify the code. Answer: select the code, then ask a specific question about it.