GitHub Copilot custom instructions QA workflows help teams stop repeating the same testing rules in every chat. If your QA or SDET team keeps asking Copilot to use pytest fixtures, avoid brittle selectors, add negative cases, or review assertions more carefully, custom instructions are the practical next step.

GitHub’s official documentation supports three useful building blocks for this workflow: repository-wide instructions in .github/copilot-instructions.md, path-specific instructions in .github/instructions/**/*.instructions.md, and test-generation prompts such as /tests in Copilot Chat. Combined, these let QA teams give Copilot stable guidance for test files and review work without claiming that AI output can be accepted blindly.

Why QA Teams Should Care About Custom Instructions

Many AI testing problems are not caused by missing intelligence. They are caused by missing context. Copilot might write a valid test that still breaks team expectations because it uses weak assertions, ignores naming rules, skips setup fixtures, or adds coverage that does not match the repository’s real test strategy.

Custom instructions reduce that drift. Instead of restating the same rules in every prompt, you save those rules in the repository so Copilot can use them repeatedly when writing tests or reviewing pull requests. GitHub’s docs also make an important limitation clear through their best-practice guidance: you still need to review and validate generated output before adoption.

What the Official GitHub Docs Support

  • Repository-wide guidance in .github/copilot-instructions.md.
  • Path-specific guidance in .github/instructions/**/*.instructions.md.
  • Both repository-wide and path-specific instructions applying together when a file path matches the path-specific rule.
  • Copilot Chat test generation with /tests for the active file or selected code.
  • Custom instructions for Copilot code review so review comments are more aligned with team standards.

That combination is enough for a practical QA tutorial. You do not need unstable or version-specific claims to get real value from the workflow.

Step 1: Decide What Copilot Should Repeat Every Time

Start with the rules your team repeats most often during test reviews. Good candidates include:

  • Prefer stable locators and avoid brittle CSS chains.
  • Use clear Arrange, Act, Assert structure.
  • Add at least one negative or edge case when relevant.
  • Do not stop at status-code assertions for API tests.
  • Keep tests isolated, deterministic, and readable.
  • Reuse fixtures and helpers instead of duplicating setup logic.

If a rule matters across the whole repository, keep it repository-wide. If it only matters for test files, API collections, or Playwright specs, make it path-specific.

Step 2: Add Repository-Wide Copilot Instructions

Create .github/copilot-instructions.md at the root of the repository. Put only the rules that should apply broadly. Keep the file short enough that a reviewer can maintain it.

When working in this repository:
- Prioritize readable, maintainable automation over clever shortcuts.
- Keep changes small and easy to review.
- When generating tests, prefer deterministic data and reusable helpers.
- When reviewing tests, call out weak assertions, flaky waits, and duplicated setup.
- Recommend validation steps the tester should run before merge.

This file should not become a giant testing handbook. Use it for repository-level behavior, not every framework detail.

Step 3: Add Path-Specific Instructions for Test Files

GitHub’s customization docs show path-specific instruction files for test automation. This is where QA teams can be much more concrete. Create a file such as .github/instructions/tests.instructions.md and target the folders or file patterns your team actually uses.

---
applyTo: "tests/**/*.py"
---

When writing or reviewing Python tests:
- Use pytest fixtures for setup and teardown.
- Follow Arrange, Act, Assert structure.
- Test edge cases and failure conditions, not only happy paths.
- Prefer descriptive test names that explain business behavior.
- Avoid hidden sleeps; use explicit synchronization or polling helpers.
- Flag status-only API assertions when response body or schema checks are needed.

You can create separate instruction files for Playwright, Selenium, API tests, or performance-test folders. This keeps repository-wide instructions clean while giving Copilot detailed rules exactly where they matter.

Step 4: Use Copilot Chat with the Right Context

GitHub’s IDE chat docs say Copilot works better when you provide relevant file or project context. For QA work, do not ask vague questions like “write some tests.” Open the target file, highlight code when needed, and attach related files if your IDE supports it.

Example prompts:

/tests for this validation helper
/tests add boundary and negative coverage for empty, null, and oversized values
Review this Playwright spec and suggest stronger assertions for checkout failure paths
Using the repository instructions, refactor these duplicated API tests to use shared fixtures

The point is not only to generate code faster. The point is to generate code that already starts closer to your QA review standard.

Step 5: Use the Same Instruction Strategy for Copilot Code Review

GitHub also documents custom instructions for Copilot code review. That matters for QA teams because code review is often where weak waits, vague assertions, and missing negative coverage should be caught. If your repository uses custom instructions for review, Copilot can look for the patterns your team cares about instead of giving only generic feedback.

A practical review-focused addition might be:

When reviewing test automation changes:
- Flag brittle selectors and timing-sensitive waits.
- Flag assertions that only check status codes or element existence.
- Suggest missing negative, boundary, and error-path coverage.
- Prefer comments that mention the risk of the current approach and a safer alternative.

This works best as a review aid, not as final approval. Human reviewers still decide whether a suggested issue is real and whether the proposed test strategy fits the release risk.

Step 6: Validate the Output Before You Trust It

GitHub’s best-practices docs are explicit on this point: review and validate generated code carefully. For QA teams, that means:

  • Run the tests locally or in CI.
  • Read assertions line by line.
  • Check whether fixtures or mocks hide real behavior.
  • Confirm that negative cases reflect actual requirements.
  • Reject unnecessary changes to production code when the goal was test-only work.

Custom instructions improve consistency. They do not replace test design judgment.

Suggested QA Workflow

  1. Write repository-wide instructions for general automation principles.
  2. Add path-specific instructions for test directories and frameworks.
  3. Open the target test file or related production code.
  4. Use /tests or a focused review prompt in Copilot Chat.
  5. Inspect the generated tests for waits, data, assertions, and maintainability.
  6. Run the affected checks and review the diff before merge.

What to Screenshot for This Tutorial

  • The .github/copilot-instructions.md file in the repository.
  • A path-specific .instructions.md file for test folders.
  • A Copilot Chat session using /tests with a real file open.
  • A generated test diff showing stronger assertions or negative cases.
  • A pull request review comment where Copilot flags a weak test pattern.

Common Mistakes

Putting everything in one file. Repository-wide instructions become noisy if they try to describe every test framework in detail. Keep broad rules broad, and move framework-specific guidance into path-specific files.

Writing vague instructions. “Write better tests” is not useful. “Use pytest fixtures, cover error paths, and reject status-only API assertions” is useful.

Assuming instructions guarantee compliance. AI output can still miss rules or misapply them. That is why validation stays mandatory.

Skipping context in the chat prompt. Even with custom instructions, Copilot still performs better when the right file, selection, and nearby code are attached.

References

FAQ

Where should QA teams store GitHub Copilot custom instructions?

Use .github/copilot-instructions.md for repository-wide guidance and .github/instructions/**/*.instructions.md for path-specific rules that target test folders or file types.

Can GitHub Copilot custom instructions improve AI-generated tests?

Yes. They can make outputs more consistent with your team’s testing rules, especially when paired with the right file context and focused prompts such as /tests.

Should QA teams rely on Copilot review comments without manual checking?

No. Copilot review is useful as an additional signal, but QA engineers still need to inspect the diff, confirm the risk, and run the relevant validation steps.

What is a good first custom instruction for QA?

Start with a short rule that Copilot should always apply, such as preferring deterministic tests, stronger assertions, and negative coverage where business risk justifies it.

Conclusion

GitHub Copilot custom instructions for QA are one of the simplest ways to make AI-generated test work more repeatable. Save your broad test-quality rules in repository instructions, move framework-specific details into path-based files, use Copilot with the right context, and keep human review responsible for the final decision.