PR Testing

The review agent prioritizes context signals in this order:

PR description — what does the author say this PR does?
Linked issues/tickets — Jira or Linear tickets referenced in the description, branch name, or commits
Changed files — which files and routes were modified
Commit messages — incremental changes

An empty or vague PR description forces the agent to infer intent from the diff alone — less focused test selection, more guesswork about which user flows are affected. The same applies to the context input when triggering reviews via the Change Review Action or API.

What makes a good PR description

A useful PR description should answer:

Section	What to include
What changed	User-facing behavior changes, not implementation details
Why	The purpose — a user story, bug report, or product goal
What to test	Affected user flows, pages, edge cases
Out of scope	What this PR intentionally does not change

Example

A PR that adds Apple Pay to the checkout flow:

## What changed

Added Apple Pay as a payment method on the checkout page. Users on
supported devices see an Apple Pay button alongside the existing
credit card form.

## Why

Requested by enterprise customers to reduce checkout friction on
Safari/iOS (PROJ-1234).

## What to test

- Apple Pay button visibility on supported vs. unsupported devices
- Completing a purchase with Apple Pay
- Falling back to credit card when Apple Pay is declined
- Existing credit card checkout still works

## Out of scope

- Subscription payments (separate PR)
- Mobile app (web only)

Compare this to a PR titled “Add payment stuff” with no description — the agent won’t know to focus on device compatibility or the fallback flow.

Link your tickets

If PRs reference issue identifiers — like PROJ-1234 in the description, branch name (feature/PROJ-1234-apple-pay), or commits — the agent fetches the full ticket details including acceptance criteria. Works with Jira and Linear when the integration is configured in project settings. Acceptance criteria from the ticket stack with the PR description, so you don’t need to duplicate them.

Automate PR descriptions with an AI agent

AI coding agents can read the diff, inspect surrounding code for context, and generate a structured description in seconds. You can run this as a GitHub Action so every PR gets a description automatically.

GitHub Action example

This example uses OpenCode, but the same idea works with any coding agent or LLM CLI tool. Bring your own API key.

name: Enrich PR description

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  enrich-description:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install OpenCode
        run: curl -fsSL https://opencode.ai/install | bash

      - name: Generate PR description
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          opencode run --auto "
            Look at the diff between this branch and origin/${{ github.event.pull_request.base.ref }}.
            Read relevant source files for context.

            Write a PR description with these sections:
            ## What changed — user-facing behavior changes
            ## Why — purpose of the change
            ## What to test — affected user flows, pages, edge cases
            ## Out of scope — what this PR does not change

            Be specific and concise. Write the output to pr_description.md.
          "

      - name: Update PR
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          if [ -f pr_description.md ]; then
            gh pr edit ${{ github.event.number }} --body-file pr_description.md
          fi

This is illustrative — adapt the prompt and tooling to your stack.

Run it locally

You can do the same thing locally before opening a PR:

opencode run "Write a PR description for my current changes"

Most coding agents support custom commands — reusable prompts you invoke with a shortcut. You can create a /create-pr command that diffs against main, generates a description with test steps, and creates the PR:

opencode run --command create-pr

The command would instruct the agent to run git diff main...HEAD, draft a concise description, and create or update the PR with gh pr create or gh pr edit --body-file. See OpenCode custom commands or your agent’s equivalent. Claude Code also has a built-in /pr command. CI gives you consistency — every PR gets a description regardless of who opens it.

Pass generated context to the Change Review Action

You can also pipe AI-generated context into the context input of the Change Review Action instead of overwriting the PR body.

name: QA.tech PR Review with context

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install OpenCode
        run: curl -fsSL https://opencode.ai/install | bash

      - name: Generate testing context
        id: generate-context
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          opencode run --auto "
            Look at the diff between this branch and origin/${{ github.event.pull_request.base.ref }}.
            Read relevant source files for context.

            Write a brief summary of:
            - What user-facing behavior changed
            - Which pages/flows are affected
            - Edge cases worth testing
            - What should NOT be tested (out of scope)

            Write the output to testing_context.txt. Keep it concise.
          "

          {
            echo 'CONTEXT<<EOF'
            cat testing_context.txt 2>/dev/null || echo ''
            echo 'EOF'
          } >> "$GITHUB_OUTPUT"

      - name: Run QA.tech Change Review
        uses: QAdottech/run-action/change-review@v3
        with:
          api_token: ${{ secrets.QATECH_API_TOKEN }}
          context: ${{ steps.generate-context.outputs.CONTEXT }}
          applications_config: |
            {
              "applications": {
                "YOUR_APP_SHORT_ID": {
                  "environment": {
                    "url": "https://preview-${{ github.event.number }}.example.com"
                  }
                }
              }
            }

You can combine approaches: auto-generate the PR description and pass extra context to the Change Review Action. The agent sees both.

Summary

Approach	Effort	Best for
Write good PR descriptions manually	Low	Small teams with strong PR culture
Link Jira/Linear tickets	None (automatic)	Teams already using issue trackers
Auto-generate descriptions in CI	One-time setup	Teams where PRs consistently lack context
Pass `context` to Change Review Action	Per-workflow	Custom testing guidance per PR type

These approaches stack.

GitHub Actions — Change Review Action reference and examples
GitHub App — Automatic PR reviews
CI/CD Integration — Overview of integration modes
Creating Tests — Writing acceptance criteria in tickets and PR descriptions

Get Started

Core Concepts

Configuration

Best Practices

Test Features

Integrations

Applications

CLI

What makes a good PR description

Example

Link your tickets

Automate PR descriptions with an AI agent

GitHub Action example

Run it locally

Pass generated context to the Change Review Action

Summary

​What makes a good PR description

​Example

​Link your tickets

​Automate PR descriptions with an AI agent

​GitHub Action example

​Run it locally

​Pass generated context to the Change Review Action

​Summary

​Related documentation

What makes a good PR description

Example

Link your tickets

Automate PR descriptions with an AI agent

GitHub Action example

Run it locally

Pass generated context to the Change Review Action

Summary

Related documentation