Domain 4: Apply Prompt Engineering and Context Crafting

What Domain 4 tests

#

Domain 4 is about improving Copilot output by improving the request and the context around it. GitHub defines a prompt as your request, and says Copilot also uses additional context such as current-file code and chat history. GitHub Docs — Prompt engineering

The official subskills boil down to this: make the task clear, attach the right context, use examples when behavior is subtle, keep chat history useful, and move repeated guidance into reusable customizations.

Key point: prompt engineering is wording plus context selection.

What makes a good prompt

#

GitHub’s official guidance: start general, get specific, give examples, break complex tasks down, avoid ambiguity, indicate relevant code, iterate, keep history relevant, and follow good coding practices. GitHub Docs — Prompt engineering

A strong prompt usually names the task, scope, constraints, and expected output: “Refactor calculateInvoiceTotal in billing.ts to make tax handling testable. Keep the public signature unchanged, preserve rounding behavior, and show updated unit tests.”

Zero-shot, one-shot, and few-shot prompting

#

Zero-shot means no example. Use it for common, low-ambiguity tasks.

Write a TypeScript function named isStrongPassword that returns true when a password is at least 12 characters and contains an uppercase letter, lowercase letter, number, and symbol.

One-shot means one example. Use it when the output shape matters.

Write a JavaScript function that converts API error objects into user-facing messages.
Example: { code: "CARD_DECLINED" } -> "Your payment method was declined. Please use a different card."
Now support NETWORK_TIMEOUT, INVALID_COUPON, and UNKNOWN_ERROR.

Few-shot means several examples. GitHub explicitly recommends examples of input data, outputs, and implementations, and says unit tests can also serve as examples. GitHub Docs — Give examples

Create a Python function normalize_status(raw: str) -> str.
"In Progress" -> "in_progress"
"in-progress" -> "in_progress"
"DONE" -> "done"
" blocked " -> "blocked"
Return "unknown" for empty or unrecognized values. Include pytest tests.

The GitHub Copilot Cookbook provides task recipes for tests, failures, refactoring, and documentation. GitHub Docs — Copilot Cookbook

Comment-driven development

#

GitHub’s best-practices page says inline suggestions work well for generating code from inline comments, repetitive code, and tests for test-driven development. GitHub Docs — Best practices

// Return newest orders first. Exclude cancelled orders. Default limit is 20.
// Throw RangeError when limit is less than 1 or greater than 100.
export function getVisibleOrders(orders: Order[], limit = 20): Order[] {
  // Copilot suggestion starts here
}

Good comments include behavior, boundaries, defaults, and errors. Vague comments like // process orders do not give Copilot enough structure.

How Copilot determines context

#

In the IDE, GitHub tells you to open relevant files and close irrelevant files. In Chat, open or highlight the code you want referenced, and use chat variables to manually supply context. GitHub Docs — Indicate relevant code

Repository context can also come from semantic indexing. GitHub documents that Copilot Chat can use a repository index to improve answers about code structure and logic, and that excluded content is filtered before being passed to Chat. GitHub Docs — Repository indexing

GitHub does not publish one universal priority order for every context source. Safe exam model: explicit references and selected code are clearest; active/open files and repository context help discovery; chat history carries decisions; custom instructions add standing guidance. If history gets noisy, start a new thread or delete irrelevant requests. GitHub Docs — Keep history relevant

Chat history and prompt process flow

#

Copilot Chat uses chat history as context, so follow-up turns can say “keep the same API,” “add tests for the previous code,” or “explain that tradeoff.” GitHub also warns you to keep history relevant. GitHub Docs — Experiment and iterate

A practical flow is: state the goal, attach context, list constraints, ask for a concrete output, review the result, then follow up with corrections. In the IDE chat view, Copilot responses can show which references were used, including custom instruction files. GitHub Docs — Asking Copilot questions in your IDE

Custom instructions and prompt files

#

Custom instructions are automatic standing guidance. GitHub says they help avoid repeatedly adding project details, team preferences, tools, standards, frameworks, and folder structure to every prompt. They should be short, self-contained, and broadly applicable within their scope. GitHub Docs — Customizing responses

Use .github/copilot-instructions.md for repository-wide guidance and .github/instructions/NAME.instructions.md for path-specific guidance with applyTo globs. GitHub Docs — Adding repository instructions

---
applyTo: "src/components/**/*.tsx"
---
Use function components.
Use accessible labels for interactive controls.
Prefer existing design-system components.
Add or update tests when behavior changes.

Prompt files are manual, reusable task prompts stored as .github/prompts/*.prompt.md. The customization cheat sheet contrasts them with custom instructions: instructions trigger automatically; prompt files are selected directly in chat or through the prompt picker. GitHub Docs — Customization cheat sheet

Review the selected API handler for security and reliability.
Check authentication, authorization, input validation, error handling, rate limits, and failure-path tests.
Return a table with finding, risk, affected code, and recommended fix.

Common anti-patterns

#

Always check Copilot’s work: understand suggested code, review function and security, and use tests, linting, code scanning, and IP scanning where appropriate. GitHub Docs — Check Copilot’s work

Check yourself

#