GitHub announced on June 18, 2026 that Copilot code review now supports repository-level AGENTS.md files. In the same changelog, GitHub also said it is easier to request Copilot reviews on draft pull requests and that Copilot review events on the PR timeline are now collapsed to reduce noise.
For QA engineers, this is a practical workflow update, not just another Copilot UI tweak. If your team uses AI review on Playwright, Selenium, API, or CI-related pull requests, repository instructions are now one of the cleanest ways to tell Copilot what good test automation looks like before reviewers spend time fixing generic feedback.
What GitHub changed on June 18
- Copilot code review now reads
AGENTS.mdfrom the root of the repository. - GitHub says Copilot uses relevant instructions from that file when generating review feedback.
- The Request button now appears next to Copilot on draft pull requests, so teams can ask for a first-pass review earlier.
- Copilot review events on the pull request timeline are collapsed to reduce clutter in the conversation tab.
Those points come directly from GitHub’s official changelog dated June 18, 2026. A related GitHub update from June 12, 2026 also added organization-level runner controls, content exclusion support, and removed the old character limit on repository custom instruction files for Copilot code review. Taken together, the recent updates show GitHub pushing Copilot review toward more governed, repository-aware workflows.
Why this matters for QA engineers
Test automation review quality depends on repository context. A generic AI reviewer might praise readability while missing the issues QA teams actually care about: brittle selectors, weak assertions, hidden retries, over-broad waits, test data coupling, or CI shortcuts that hide failures. Copilot code review AGENTS.md support gives teams a better place to encode those rules once and reuse them across pull requests.
- Stronger review consistency: the same repo guidance can shape reviews for every tester and developer.
- Earlier feedback on draft PRs: QA-heavy changes can get an AI first pass before formal review starts.
- Cleaner PR timelines: collapsing review events makes it easier to spot the comments that need action.
A simple QA use case
Imagine your team reviews Playwright pull requests where the common failure modes are stable across projects: using text selectors when data-testid exists, adding retries instead of fixing synchronization, moving assertions into helpers until business intent disappears, and changing CI settings to make a flaky test look green. Those are exactly the kinds of patterns that belong in repo-level review instructions.
Starter Snippet
# AGENTS.md
When reviewing test automation changes:
- Prefer data-testid, role, or label-based selectors over brittle text chains.
- Flag fixed delays, broad retries, and waits that hide product timing issues.
- Keep assertions focused on user-visible business outcomes.
- Call out CI or workflow edits that can mask real failures.
- Ask for missing negative-path coverage when the change touches validation or auth.This is not a magic rule file. Human reviewers still decide whether the instruction set is good, whether Copilot followed it correctly, and whether the final patch is safe. But it is a better default than letting every AI review start from a blank understanding of your QA standards.
Why the June 12 controls matter too
The June 18 change is more useful because of what GitHub shipped on June 12. GitHub says Copilot code review can now respect content exclusion settings, use organization-level runner controls, and read longer custom instruction files without the old 4000-character cutoff. That gives QA and platform teams two important levers: decide what repository content Copilot should not use, and define more complete review guidance without squeezing everything into a tiny instruction file.
- If your repo contains sensitive fixtures or directories that should stay out of AI context, content exclusion matters.
- If your organization wants one runner default for Copilot review, organization-level controls matter.
- If your QA review checklist used to be too long for instruction limits, the removed cap matters.
Why this matters for QA engineers
The immediate takeaway is operational: QA teams can now make AI review more opinionated about waits, locators, assertions, coverage, and CI risk without repeating those expectations on every pull request. That should reduce low-value review churn and make draft AI feedback closer to what senior test engineers would want to see.
Three checks to run this week
- Create or refine a root
AGENTS.mdfile with specific QA review rules for selectors, waits, assertions, and flaky-test fixes. - Request Copilot review on one draft PR that changes tests or CI, then compare the feedback before and after adding repo guidance.
- Audit content exclusions so Copilot code review does not use directories that should stay outside review context.