diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 4c5bb06..c5e8f9d 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -4,6 +4,9 @@ on:
   pull_request:
   push:
     branches: [main]
+  # Started by the Release workflow for release-please's pull request: GitHub does not run
+  # workflows for pull requests opened by GitHub Actions, and main requires these checks.
+  workflow_dispatch:
 
 concurrency:
   group: ci-${{ github.ref }}
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index cc1c0fb..6e01e3b 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -23,6 +23,7 @@ jobs:
     if: github.event_name == 'push'
     runs-on: ubuntu-latest
     permissions:
+      actions: write
       contents: write
       pull-requests: write
     outputs:
@@ -35,6 +36,21 @@ jobs:
           config-file: release-please-config.json
           manifest-file: .release-please-manifest.json
 
+      # Pull requests opened with the workflow token do not trigger CI, but main requires its
+      # checks. Start CI on the release branch so the release pull request can merge normally.
+      - name: Run CI on the release pull request
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          branch=$(gh pr list -R "$GITHUB_REPOSITORY" --state open --label "autorelease: pending" \
+            --json headRefName -q '.[0].headRefName')
+          if [ -n "$branch" ]; then
+            gh workflow run ci.yml -R "$GITHUB_REPOSITORY" --ref "$branch"
+            echo "Started CI on $branch"
+          else
+            echo "No open release pull request"
+          fi
+
   # Decides what to publish: the release release-please just created, or the tag given to a
   # manual run.
   plan:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8fbd309..5a98583 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -54,6 +54,10 @@ The protocol the bridge speaks is defined in the open-source
    and say in the pull request what you ran and on which OS.
 4. Open the pull request with a [Conventional Commit](https://www.conventionalcommits.org/) title.
 
+`main` only changes through pull requests, and CI (format, lint, types and tests on macOS and Linux) must pass before
+anything merges. CI on a pull request from an outside contributor starts once a maintainer approves the run. A maintainer reviews
+and merges outside contributions; maintainers merge their own pull requests once CI passes.
+
 ### Commit and pull request titles
 
 Titles drive the changelog and version numbers, so they follow Conventional Commits:
@@ -86,7 +90,9 @@ Add `!` after the type (`feat!:`) for a breaking change, and describe the migrat
 Releases are automated with [release-please](https://github.com/googleapis/release-please):
 
 1. Merge pull requests with Conventional Commit titles.
-2. release-please keeps a release pull request open with the next version and the changelog entry.
+2. release-please keeps a release pull request open with the next version and the changelog entry. GitHub does not
+   run CI for pull requests opened by GitHub Actions, so the release workflow starts CI on that branch itself; its
+   checks appear on the release pull request like any other.
 3. Merging the release pull request tags the release, and the release workflow runs `bun run check` on the tag and
    publishes to npm.