Apply prompt engineering and context crafting
Domain 4 is 10-15% of GH-300. It tests practical prompt habits, shot patterns, instruction precedence, and the context signals Copilot uses to answer well.
The 4 Ss: Single, Specific, Short, Surround
The official material names the 4 Ss. Treat them as a memorization item. If a question asks how to improve a weak prompt, map the fix to one of these four words.
| S | Definition | Example |
|---|---|---|
| Single | Focus the prompt on one well-defined task or question. | Write unit tests for this function, not tests, docs, and refactoring in one request. |
| Specific | Make the instructions explicit and detailed. | Ask for edge cases around null input and duplicate IDs, not just better tests. |
| Short | Keep prompts concise and to the point. | State the goal, constraints, and expected format without dumping unrelated history. |
| Surround | Use descriptive filenames and keep related files open. | Open the service, model, and test file so Copilot can infer the local pattern. |
If the prompt is trying to do too much, fix Single. If it is vague, fix Specific. If it is bloated, fix Short. If Copilot lacks nearby code, fix Surround.
Zero-shot, one-shot, and few-shot prompting
The study guide names zero-shot and few-shot, but the training material defines one-shot too. All three are fair game.
Zero-shot
You give the task without an example. Use it when the request is common and the expected format is obvious.
Example: Explain what this function does in plain English.
One-shot
You give one example of the desired pattern, then ask Copilot to apply it to a new case.
Example: Show one test naming style, then ask for another test that follows it.
Few-shot
You give several examples so Copilot can infer a pattern, style, or mapping.
Example: Provide three API error mappings, then ask for the remaining mappings.
No example means zero-shot. One example means one-shot. Several examples mean few-shot. The count is about examples supplied in the prompt, not how many files are open.
Prompt patterns for performance
Prompt engineering is not magic wording. It is structuring the request so Copilot has the right job, role, sequence, and history.
Role prompting
Role prompting asks Copilot to respond from a useful perspective, such as a security expert, performance optimization specialist, or testing specialist. Use the role to focus the review criteria, not to replace validation.
Chain prompting
Chain prompting breaks a larger task into a sequence. First ask Copilot to inspect or explain. Then ask it to propose a change. Then ask it to implement or generate tests. This keeps each turn narrower and easier to verify.
Chat history management
Chat history can help Copilot maintain context, but stale or overloaded history can hurt answer quality. Start a narrower thread or restate the current goal when the conversation has drifted.
| Pattern | Best use | Risk if misused |
|---|---|---|
| Role prompting | Direct Copilot toward security, tests, performance, or another lens. | The role sounds authoritative, but output still needs review. |
| Chain prompting | Split a complex task into inspect, plan, change, and verify turns. | A long chain can carry stale assumptions. |
| Chat history management | Preserve useful context and remove distractions. | Too much history consumes context and can confuse the next answer. |
The training mentions PRUs for long prompts. That term is retired. The current term is GitHub AI Credits. Use PRU only as history, not as current product wording.
Custom instructions and precedence
Instruction precedence is one of the easiest GH-300 facts to reverse. The order is not the same as policy control.
Personal beats repository beats organization. Within repository instructions, path-specific beats repo-wide beats AGENTS.md.
Organization ranks lowest for instructions, even though organization policies win over user preferences. That asymmetry is the trap.
| Rank | Instruction source | Notes from the facts brief |
|---|---|---|
| 1 | Personal instructions | Highest precedence. Supported for Copilot Chat on GitHub.com. |
| 2 | Repository path-specific instructions | Stored under .github/instructions/NAME.instructions.md. |
| 3 | Repository-wide instructions | Stored in .github/copilot-instructions.md. |
| 4 | AGENTS.md | Repository agent instructions, below repo-wide instructions. |
| 5 | Organization instructions | Lowest precedence, even though relevant instruction sets are still provided to Copilot. |
Related instruction facts
- All relevant instruction sets are provided to Copilot, even though precedence still matters.
- Organization instructions are currently supported for Copilot Chat on GitHub.com, Copilot code review on GitHub.com, and Copilot cloud agent on GitHub.com.
- Organization instructions apply to all organization members, regardless of whether that organization provides the member’s Copilot subscription.
- On pull requests, Copilot reads instructions and skills from the head branch, not the base branch.
- Prompt files live at .github/prompts/*.prompt.md. They are GA in VS Code and Visual Studio, preview in JetBrains and Xcode, and not supported in Eclipse, on GitHub.com, or in the CLI.
- Hooks live at .github/hooks/*.json.
- Copilot may not follow custom instructions identically every time because it is non-deterministic.
For policy conflict rules, use the privacy and safeguards guide. Instructions are about guidance. Policies are about administrative control.
Context crafting
Context crafting means shaping what Copilot can see and infer. It starts before the prompt: file names, open tabs, current cursor position, and scope all matter.
Open the right tabs
Surround says to keep related files open. Open the implementation, tests, interface, route, schema, or configuration file that shows the local pattern.
Name files descriptively
Filenames and file types are part of context. A descriptive file name gives Copilot a stronger signal than a generic scratch file.
Scope the request
Ask for a focused change in a known area. Tie the request to a function, file, test, or behavior instead of asking for a broad rewrite.
Provide examples
Use one-shot or few-shot prompting when style, format, or mapping matters. Examples reduce guessing.
| Weak prompt | Better prompt | Why it improves |
|---|---|---|
| Make this better. | Refactor this function to reduce duplicate validation logic without changing behavior. | Single and specific. |
| Write tests. | Write unit tests for null input, duplicate IDs, and a successful save using the style in the open test file. | Specific, surrounded, and example-aware. |
| Explain the app. | Explain how this controller calls the service and where errors are handled. | Smaller scope and clearer target. |
Context can include open tabs, filenames, file types, project structure, file paths, languages, frameworks, and code before and after the cursor. See the data lifecycle guide for the full inbound list.
Domain 4 exam traps
Prompting questions usually ask for the next best action, not a definition. Look for the weakness in the prompt, then choose the smallest fix.
| Scenario | Best move | Why |
|---|---|---|
| The prompt asks for a refactor, tests, docs, and a security review at once. | Make it Single. | One well-defined task gives Copilot a cleaner target. |
| The prompt says “fix this” with no behavior or constraints. | Make it Specific. | Explicit details reduce guessing. |
| The prompt includes a long stale chat history and unrelated requirements. | Make it Short or restart with a focused summary. | Concise prompts leave more useful context for the answer. |
| Copilot misses the local test style. | Use Surround and examples. | Open related files and provide one-shot or few-shot examples. |
| Personal, repository, and organization instructions conflict. | Personal wins for instructions. | Organization instructions are lowest, even though organization policies control preferences. |
Instruction files to recognize
.github/instructions/NAME.instructions.md: path-specific repository instructions.
.github/copilot-instructions.md: repository-wide instructions.
AGENTS.md: agent instructions inside the repository precedence stack.
Prompt files and hooks
.github/prompts/*.prompt.md: reusable prompt files. GA in VS Code and Visual Studio, preview in JetBrains and Xcode, not supported in Eclipse, on GitHub.com, or in the CLI.
.github/hooks/*.json: hooks. Do not confuse hooks with custom instructions.
For instructions, personal is highest and organization is lowest. For policies, administrative policy can override user preference. If a question mixes those words, slow down.
Rapid review: choose the prompt fix
Use the 4 Ss as a quick decision tree. If the user asks for many deliverables, make it Single. If Copilot must guess the expected behavior, make it Specific. If the thread is full of old constraints, make it Short. If Copilot cannot see the local pattern, use Surround by opening related files and using descriptive filenames.
A one-shot or few-shot prompt is often the fastest way to communicate style. It is especially useful for tests, error formats, naming conventions, and repeated mappings.
On the exam, prefer the answer that improves the prompt or context without changing the administrative setting. Prompt engineering changes the request. Policy changes belong in the privacy and organization-management objectives.
The night-before cheat sheet
4 Ss
Single: one task. Specific: explicit details. Short: concise. Surround: related files open and descriptive filenames.
Shots
Zero-shot has no example. One-shot has one example. Few-shot has several examples.
Patterns
Role prompting gives a lens. Chain prompting splits work into steps. Chat history management keeps useful context and removes drift.
Precedence
Personal > repository > organization. Inside repository: path-specific > repo-wide > AGENTS.md. Policies are different.