Examples

This page provides concrete examples: workflows that enable Bugbot detection and autofix, comment phrases that trigger fixes or do-user-request, and CLI commands for on-demand detection.

Push workflow (with Bugbot)

The Commit workflow runs on push to branches (typically excluding main and develop). If OpenCode is configured, Bugbot detection runs automatically for branches linked to an issue.

name: Copilot - Commit

on:
  push:
    branches:
      - '**'
      - '!master'
      - '!develop'

jobs:
  copilot-commits:
    name: Copilot - Commit
    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 }}
          opencode-model: ${{ vars.OPENCODE_MODEL }}
          opencode-server-url: ${{ vars.OPENCODE_SERVER_URL }}
          # Optional: Bugbot-specific
          bugbot-severity: "low"
          bugbot-comment-limit: "20"
          ai-ignore-files: "build/*, dist/*"

No contents: write is needed for detection only; the action only posts comments. For autofix and do-user-request, use the issue/PR comment workflows below with contents: write.

Issue comment workflow (for autofix)

Workflows that run on issue_comment allow users to ask the bot to fix findings or apply a do-user-request from an issue. You must grant contents: write so the action can push.

name: Copilot - Issue Comment

on:
  issue_comment:
    types: [created, edited]

jobs:
  copilot-issues:
    name: Copilot - Issue Comment
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - uses: vypdev/copilot@v2
        with:
          token: ${{ secrets.PAT }}
          opencode-model: ${{ vars.OPENCODE_MODEL }}
          ai-ignore-files: build/*
          bugbot-fix-verify-commands: ${{ vars.BUGBOT_AUTOFIX_VERIFY_COMMANDS }}

Note: On issue comment, the action needs an open PR that references the issue to know which branch to checkout and push to. If there is no such PR, autofix and do-user-request are skipped.

Pull request comment workflow (for autofix)

For comments on the PR or replies in a review thread, use a workflow on pull_request_review_comment (and optionally issue_comment if you want both). Again, contents: write is required for autofix and do-user-request.

name: Copilot - Pull Request Comment

on:
  pull_request_review_comment:
    types: [created, edited]

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

      - uses: vypdev/copilot@v2
        with:
          token: ${{ secrets.PAT }}
          opencode-model: ${{ vars.OPENCODE_MODEL }}
          ai-ignore-files: build/*
          bugbot-fix-verify-commands: ${{ vars.BUGBOT_AUTOFIX_VERIFY_COMMANDS }}

On PR events, the action already has the PR’s head branch from the event, so no “resolve branch from issue” step is needed.

Single action: detect potential problems

To run Bugbot detection on demand (e.g. from a manual workflow run), use single-action: detect_potential_problems_action and single-action-issue. The workflow must check out the branch you want to analyze; the action uses the current checkout.

name: Bugbot - Detect (manual)

on:
  workflow_dispatch:
    inputs:
      issue_number:
        description: 'Issue number'
        required: true
        type: number
      branch:
        description: 'Branch to analyze (default: feature/issue-<issue>)'
        required: false
        type: string

jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.inputs.branch || format('feature/issue-{0}', github.event.inputs.issue_number) }}

      - uses: vypdev/copilot@v2
        with:
          token: ${{ secrets.PAT }}
          single-action: detect_potential_problems_action
          single-action-issue: ${{ github.event.inputs.issue_number }}
          opencode-model: ${{ vars.OPENCODE_MODEL }}
          opencode-server-url: ${{ vars.OPENCODE_SERVER_URL }}

After the run, findings appear on the issue and on any open PR for that branch.

CLI: detect potential problems

From the repository root (with a .env that has PERSONAL_ACCESS_TOKEN and, if needed, OpenCode env vars), you can run Bugbot detection locally:

# Require issue number; optional branch (default: current branch)
copilot detect-potential-problems -i 123

# Specify branch explicitly
copilot detect-potential-problems -i 123 -b feature/issue-123

# With token and debug (if not in .env)
copilot detect-potential-problems -i 123 -t $PAT -d

See Testing OpenCode Plan Locally for full setup (OpenCode server, API keys, etc.).

Comment examples: autofix

These are examples of comments that typically trigger Bugbot autofix (fix one or more reported findings). The exact interpretation is done by OpenCode; these are common patterns.

Post these on the issue or on the PR (or reply in the review thread of a finding). The action will run only if you have permission (org member or repo owner) and, for issue comments, there is an open PR for the issue.

Comment examples: do-user-request

These are examples of comments that typically trigger do user request (general code change, not tied to a specific finding).

Same permission and workflow requirements as autofix: contents: write and org member or repo owner.

Example: overflow comment (detection)

When there are more findings than bugbot-comment-limit, the action posts one overflow comment on the issue. It looks conceptually like this (exact wording may vary):

Additional potential problems (not posted individually)
5 more findings were detected. Consider reviewing the branch locally or increasing bugbot-comment-limit.
Titles: "Possible race in cache", "Unused variable in handler", …

So you see at most N individual finding comments plus one overflow comment per run when applicable.

Example: what a finding comment looks like

Each finding is posted as a comment with a title, severity, optional file/line, and description. The body also contains a hidden HTML marker used by the action to update or resolve the finding. As a user you only see the visible part, for example:

Title: Possible null reference in login handler
Severity: medium
File: src/auth/login.ts (line 42)
Description: The variable user may be null when passed to validateSession. Consider adding a null check before use.

The action uses the marker to later mark this finding as resolved when OpenCode reports it fixed (e.g. after you or the bot change the code).

Next steps

• Detection — When and where findings appear.
• Autofix — Permissions and verify commands.
• Configuration — All Bugbot inputs.