GitHub Copilot prompt files for QA can turn a frequently repeated test-review request into a version-controlled checklist. Instead of rewriting the same prompt for every Playwright, Selenium, API, or mobile test change, a QA team can save task-specific instructions in a .prompt.md file and invoke them when a review is needed.

This tutorial builds a reusable prompt that asks Copilot to inspect test automation changes for risk, selector quality, assertion depth, negative coverage, evidence, and deterministic validation. The goal is consistency, not automatic approval. GitHub notes that AI responses are non-deterministic, so the final gate must remain executed tests, CI evidence, code review, and human QA judgment.

Prompt files versus custom instructions

The distinction matters. Repository custom instructions provide ongoing project context, such as the test framework, coding conventions, and standard validation commands. Prompt files are reusable prompts for a specific interaction. A review checklist belongs naturally in a prompt file because a tester invokes it for a defined task.

  • Repository instructions: durable context that should influence many Copilot interactions.
  • Path-specific instructions: guidance that applies when Copilot works with matching files or directories.
  • Prompt files: an on-demand procedure for one recurring task, such as reviewing a test diff.

GitHub currently documents prompt files as a public-preview feature in supported IDEs, including Visual Studio Code, Visual Studio, and JetBrains IDEs. Support can vary, so confirm the current support table for the IDE used by your team.

Choose a narrow QA outcome

A prompt called “review my tests” is too broad. Define what a useful review must produce. For this workflow, the output should include a concise risk summary, findings tied to files or code areas, missing test ideas, validation commands, and an explicit list of evidence that the reviewer could not verify.

The prompt should not ask Copilot to declare the change production-ready. It should separate observations from assumptions and avoid inventing test results. That boundary prevents a polished answer from being mistaken for executed evidence.

Create the reusable prompt file

Create a prompt file in the location supported by your IDE. Use a descriptive name such as review-test-automation.prompt.md. Keep it in version control so the QA team can review changes to the checklist just like application or test code.

Review the selected test automation changes as a QA engineer.

Context to inspect:
- changed test files and related production code
- existing nearby tests and shared fixtures
- repository test instructions and validation commands

Review checklist:
1. Summarize the behavior and highest regression risks.
2. Identify brittle selectors, timing assumptions, shared-state leaks, and order dependence.
3. Check that assertions verify business outcomes, not only status codes or element visibility.
4. Identify missing positive, negative, boundary, permission, and recovery scenarios.
5. Flag hard-coded data, secrets, environment assumptions, and destructive actions.
6. Propose the smallest deterministic validation commands.
7. List screenshots, logs, traces, reports, or CI evidence still needed.

Output format:
- Risk summary
- Findings with severity and evidence
- Missing scenarios
- Validation plan
- Unverified assumptions

Do not claim tests passed unless supplied output proves it. Do not edit files.

This template reflects the practical angle of the queue item: selector standards, assertion depth, negative coverage, evidence, and deterministic validation. Adapt the framework-specific terms, but preserve the evidence boundary.

Add the right context

A reusable prompt becomes useful only when it receives relevant context. Include the selected diff, related production code, nearby tests, fixtures, and repository instructions. For API tests, add the OpenAPI contract or response schema. For UI tests, add page-object conventions and selector policy. For mobile tests, add platform-specific behavior and device assumptions.

Avoid dumping the entire repository into one request. Start with the changed files and expand only when the review exposes a dependency. Focused context makes findings easier to validate and reduces unrelated suggestions.

Run a practical Playwright review

Imagine a pull request adds a checkout test. Invoke the prompt with the changed spec, checkout page object, and relevant fixture. A useful review should question whether the selector is based on user-visible semantics, whether the assertion proves the order was created, whether test data can collide in parallel execution, and whether failure evidence is retained.

The reviewer should also distinguish code inspection from execution. It can recommend a focused Playwright command, but it must not say the test passed until you provide the actual terminal or CI output. If the test depends on payment, inventory, or asynchronous processing, the “unverified assumptions” section should make those dependencies visible.

Review the response like test evidence

Do not accept every finding. Check each one against the diff and the product requirement. Remove suggestions that increase scope without covering meaningful risk. Convert valid findings into concrete review comments or test tasks.

  1. Confirm the referenced file or behavior exists.
  2. Reproduce the risk where practical.
  3. Decide whether the change, fixture, product code, or environment owns the fix.
  4. Run the smallest relevant test command.
  5. Record the result and attach useful evidence.

This step is especially important for selector advice. A selector that looks brittle in isolation may be part of an approved test-id strategy. Conversely, a visually readable text selector may fail in localized builds. Repository rules and actual application behavior should settle the decision.

Make findings consistent across frameworks

The core checklist can stay stable while small sections vary by framework. For Selenium, emphasize explicit conditions and stale-element risks without using fixed sleeps. For Playwright, inspect locator semantics, auto-wait assumptions, traces, and parallel isolation. For API suites, verify schemas, response bodies, headers, authorization boundaries, and meaningful negative assertions.

If framework differences make the file too long, split it into focused prompt files. A short UI review prompt and a short API review prompt are easier to maintain than one universal checklist full of conditional instructions.

Add screenshot-friendly review checkpoints

For a tutorial or team runbook, capture screenshots at four points: the prompt file in the repository, the IDE action used to invoke it, the structured Copilot review response, and the terminal or CI output used for validation. Redact tokens, customer data, internal URLs, and confidential source code before sharing.

The screenshot sequence should show that the AI review is an input to validation, not the final proof. A clean workflow image is: prompt file, findings, executed command, evidence, human decision.

Common mistakes to avoid

  • Turning the prompt into policy: prompt files guide an AI response; they do not enforce a merge gate.
  • Requesting vague quality: name the risks and output sections you expect.
  • Accepting invented execution: require an unverified-assumptions section and actual command output.
  • Overloading context: begin with the diff and closest dependencies.
  • Ignoring preview status: check current IDE support before standardizing the workflow.
  • Skipping prompt review: changes to the checklist can change team behavior, so review them in pull requests.

Definition of done

A successful prompt-file workflow produces repeatable review structure without hiding uncertainty. The prompt is committed, understandable, and narrow. Findings map to observable code or stated requirements. Recommended commands are safe and deterministic. Test results come from execution, and a QA engineer makes the final risk decision.

Frequently asked questions

Do Copilot prompt files replace repository custom instructions?

No. Use repository instructions for persistent project context and prompt files for reusable task-specific requests. They can complement each other.

Can a prompt file guarantee that Copilot follows every QA rule?

No. GitHub documents AI responses as non-deterministic. Use CI checks, linters, permissions, review rules, and executed tests for enforcement.

Should the prompt allow Copilot to edit test files?

For a review-only workflow, begin with no edits. Review findings first, then use a separate, clearly scoped task if you want assistance implementing an approved change.

What evidence should QA keep?

Keep the reviewed diff, relevant requirement, executed test output, CI link, useful logs or traces, and the human decision. The Copilot response is supporting analysis, not proof by itself.

Official sources