Workflow setup

Enable the Copilot action for pull_request events and what runs when.

Workflow setup

To run Copilot on pull request events, add a workflow that uses the pull_request trigger and passes the required inputs (at least token). This page describes the events to use and a minimal workflow example.

Trigger events

Use the pull_request trigger with the types you need. Common setup:

on:
  pull_request:
    types: [opened, reopened, edited, labeled, unlabeled, closed, assigned, unassigned, synchronize]
Event typeWhen it runsTypical use
openedA new PR is createdLink to issue, link to projects, assign reviewers, apply size/priority, generate AI description (if enabled).
reopenedA closed PR is reopenedRe-apply linking and labels.
editedPR title or body is editedUpdate linking/labels; regenerate or update AI description if configured.
labeled / unlabeledLabels changeSync project/state if needed.
synchronizeNew commits are pushed to the PR branchRe-run size/priority (and progress if push workflow runs); AI description can be updated.
closedPR is closed or mergedUpdate project state.
assigned / unassignedAssignees or reviewers changeSync if your flow depends on it.

For first-time setup, at least opened and synchronize are useful so that new PRs get full treatment and updates when the branch changes.

Minimal workflow

Create a file under .github/workflows/ (e.g. copilot_pull_request.yml):

name: Copilot - Pull Request

on:
  pull_request:
    types: [opened, reopened, edited, labeled, unlabeled, closed, assigned, unassigned, synchronize]

jobs:
  copilot-pull-requests:
    name: Copilot - Pull Request
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - uses: vypdev/copilot@v2
        with:
          token: ${{ secrets.PAT }}
          project-ids: ${{ vars.PROJECT_IDS }}
  • token is required (use a fine-grained PAT with repo and project permissions; see Authentication).
  • project-ids is optional but needed if you want PRs linked to GitHub Project boards and moved to columns (e.g. "In Progress").

Add other inputs as needed: desired-reviewers-count, commit-prefix-transforms, ai-pull-request-description, opencode-server-url, opencode-model, etc. See Configuration and Examples.

What runs when

  1. On every trigger (with valid token): The action loads the PR and repository context. If the event actor is the same as the token owner, the action may skip the normal pipeline (see Troubleshooting); use a bot account for the PAT if you want full behavior when you open your own PRs.

  2. PR–issue linking: The action infers the issue number from the PR branch name (e.g. feature/123-add-login → issue 123) and links the PR to that issue (and posts a comment on the PR when configured).

  3. Project linking: If project-ids is set, the PR is added to those projects and moved to the configured column (e.g. "In Progress"). See Capabilities.

  4. Reviewers: If desired-reviewers-count is set, the action assigns up to that many reviewers. See Configuration.

  5. Size and priority: The action computes size (XS–XXL) and progress (if OpenCode is configured) from the branch diff and applies the corresponding labels to the issue and to the PR. Same thresholds as in Configuration.

  6. AI PR description: If ai-pull-request-description is true and OpenCode is configured, the action can generate or update the PR description from the issue and the branch diff. See AI PR description.

  7. Comments and images: The action can post a comment on the PR with optional images per branch type (feature, bugfix, etc.). See Capabilities.

Next steps