PR triage

PR triage skips automatic reviews of pull requests you do not want tested. New projects and new GitHub integrations start with it on. Mappings created before that default stay off until you turn them on. Use Settings → Integrations → GitHub App, the PR Triage toggle, and PR triage prompt. When QA.tech skips a pull request that has no earlier review result, the QA.tech / PR Review check is set to skipped with the reason, and QA.tech does not post a review comment. Comment @qa.tech on the pull request to run a review anyway. The prompt is a list of skip rules. Write them from the details in What the prompt can use. A rule about files skips the review only when every changed file matches it. A pull request that mixes a skippable file with a product change is still tested, unless a rule about the base branch, head branch, who opened it, or its deployments skips the whole pull request. If the prompt says to test the pull request, QA.tech runs the review. Docs-only, CI-only, and other untestable changes can still be skipped by the built-in rules even when your prompt does not mention them.

What the prompt can use

The prompt sees only the details in this table. It does not see the diff, your regression tests, or applications.

Detail	What the prompt sees	What you can ask
Pull request title	The full title	Skip or keep a pull request by words in the title.
Pull request description	The description, up to the first 2,000 characters	Skip or keep a pull request by words in the description.
Base branch	The branch the pull request targets, such as `main`	Skip or keep a pull request by that branch. On a later push, this is still the target branch, not the last reviewed commit.
Head branch	The branch that contains the changes, such as `feature/checkout`	Skip or keep a pull request by that branch.
Opened by	The username of the person or bot who opened the pull request, and their display name when the provider sends one	Skip or keep a pull request by who opened it.
Deployments	Each deployment of this pull request: environment name, status, URL, and mapped application. Unknown when deployments have not been loaded	Skip or keep a pull request by whether it has a deployment, or by that deployment’s environment, status, or URL. Unknown does not count as no deployment.
Changed file paths	The path of each changed file, not the contents of the file	Skip by folder, file name, or extension. On a later push, only files changed since the last finished review. See Updates to a pull request.

A pull request that changes more than 40 files is reviewed. The prompt is not applied to that review.

Updates to a pull request

The first review of a pull request is triaged against every file in that pull request. After a review finishes, a later push is triaged against only the diff since that review. A follow-up that only changes docs, CI, or other files your prompt skips can be skipped even when earlier commits in the same pull request changed the product. The QA.tech / PR Review check on the new commit keeps the previous review’s result, passed or failed. A pull request that has not had a result yet still gets a skipped check, with the reason. The existing review comment stays as it is. If those new commits should be tested, QA.tech reviews the whole pull request again, not only the new commits. The finished review replaces the review comment. Comment @qa.tech to review the whole pull request anyway, including after a skipped update. If the reviewed commit is no longer in the repository, for example after a force-push that removed it, triage uses the full pull request diff.

Reviews started from the API or GitHub Action

A review started with POST /v1/chat/change-review or the change-review GitHub Action follows the PR Triage toggle by default, the same as an automatic review. To change this for one review, send triage options in the change-review request:

enabled: true lets triage skip the review even when the toggle is off.
enabled: false always runs the review.
prompt replaces the PR triage prompt for this review, up to 4000 characters. It does not turn triage on. Omit it or leave it empty to use the integration prompt.

"triage": {
  "enabled": true,
  "prompt": "Skip changes that only touch docs or CI. Review everything else."
}

Suggested workflows

Use these as inspiration. Copy, combine, or adapt them. Skip untestable changes (default):

Skip changes that cannot be tested with end-to-end or API tests, for example changes to READMEs, infrastructure, manifests and CI, and build tooling.
Keep user-facing UI, the backend those flows call, and API-testable feature changes.

Skip one product area:

Skip pull requests that only change billing, pricing, or Metronome.
If any other product code changed, run the review.

Only test flows a customer can see:

Skip pull requests that do not change a flow a customer can see.
Skip admin screens, internal tooling, and jobs with no user-facing behavior.
Keep customer UI, the API those screens call, and copy the customer reads.

Skip dependency bumps:

Skip pull requests that only change package manifests, lockfiles, or dependency versions.
If application code also changed, run the review.

Skip only docs and CI:

Skip only pull requests whose every file is docs, a README, or CI config.
Test everything else, including styles, copy, and dependency updates.

Skip pull requests from one account:

Skip pull requests opened by dependabot[bot].
Review pull requests opened by anyone else.

Skip a deployment environment:

Skip pull requests whose only deployment is the production environment.
Review pull requests that have another deployment.

Skip pull requests into one branch:

Skip pull requests whose base branch is main.
Review pull requests opened into any other branch.

Skip a folder:

Skip pull requests whose every changed file is under docs/ or .github/.
If any file outside those folders changed, run the review.

PR Testing

Agents

Choose your CI

What the prompt can use

Updates to a pull request

Reviews started from the API or GitHub Action

Suggested workflows

​What the prompt can use

​Updates to a pull request

​Reviews started from the API or GitHub Action

​Suggested workflows

What the prompt can use

Updates to a pull request

Reviews started from the API or GitHub Action

Suggested workflows