Branch and PR automation from a remote trigger

Decision. For a Slack/chat → PR pipeline, fire a repository_dispatch from your bot, run the work on a GitHub-hosted (or self-hosted) runner, and let anthropics/claude-code-action [6] ⭐ 7.3k or peter-evans/create-pull-request [1] ⭐ 2.8k push the branch and open the PR. Auth via a custom GitHub App token, not the default GITHUB_TOKEN — otherwise downstream CI on the PR will not run [2]. For non-AI workflows (issue → scaffold branch, dependency bump), the same shape works with gh pr create or peter-evans/create-pull-request directly.

The four moving parts

Any “remote thing happens → branch + PR” pipeline factors into four decisions. Pick once per layer; everything else follows.

Transport: how the trigger gets in

peter-evans/repository-dispatch [13] ⭐ 1.2k is the de-facto wrapper for firing a dispatch from inside one workflow into another.

Compute: where the branch+PR work runs

Auth: the one footgun everyone hits

The default GITHUB_TOKEN looks fine until you notice CI never runs on the PRs your automation opens. From peter-evans’s own concepts doc [2]:

Pull requests created with the default token “cannot trigger other workflows.”

Documented in community threads going back years [5]. Pick one of these instead:

Anthropic’s docs make the same call: their troubleshooting section literally lists “Ensure you’re using the GitHub App or custom app (not Actions user)” as the fix when CI does not run on Claude’s commits [7].

PR mechanics: what pushes the branch

End-to-end shapes worth copying

Shape A — Slack message → PR (chat-driven coding)

1. Slack slash-command (or thread reaction) hits your bot.
2. Bot fires POST /repos/{owner}/{repo}/dispatches with event_type: "slack-claude" and client_payload: { user, thread_ts, prompt, channel }.
3. A workflow on: repository_dispatch: types: [slack-claude] runs actions/create-github-app-token, then anthropics/claude-code-action@v1 with prompt: $.
4. Claude edits files, the action commits, pushes a claude/<thread-ts> branch, opens the PR. Because the push is signed with a GitHub App token, downstream CI runs [2].
5. Bot watches pull_request.opened (or polls gh pr view) and posts the PR URL back to the Slack thread.

Kilo for Slack [16] is the productized version of exactly this loop.

Shape B — Issue label → scaffold branch + draft PR

1. User opens an issue, adds label ai-scaffold.
2. Workflow on: issues: types: [labeled] with if: github.event.label.name == 'ai-scaffold'.
3. robvanderleek/create-issue-branch [10] creates issue-{N}-{slug} branch and (configured) opens a draft PR.
4. Optional: chain a claude-code-action step on pull_request.opened to populate the branch with a first-pass implementation.

This is the IssueOps pattern [8] — the audit trail (label, branch, PR, comments) all lives inside GitHub.

Shape C — Scheduled scan → many PRs

1. Renovate (or a custom workflow on schedule:) scans the repo on cron.
2. Each finding gets its own branch and PR, opened against the configured base branch [11].
3. Use peter-evans/create-pull-request with branch-suffix: random [1] to avoid colliding branches when several findings open in parallel.

Pitfalls

• pull_request_target + checkout of fork code is a known repo-takeover pattern [12]. If your branch+PR automation must run on contributions from forks, treat the fork’s HEAD as untrusted: don’t check it out into a job that has write tokens, and split the job into a sandboxed read-only stage and a privileged write-stage that operates only on data you’ve validated.
• repository_dispatch only runs workflows on the default branch [3] — committing your dispatch handler on a feature branch and watching nothing fire is the most common mis-step.
• The “create or update” PR branch needs to exist on a remote — peter-evans/create-pull-request will not work for events that check out a commit (e.g. release, pull_request) without an explicit base input [2].
• Self-hosted runners on public repos are dangerous because PRs from forks can execute on your hardware [17]. Keep automation that requires self-hosted runners in private repos, or gate it behind label-based triggers that maintainers add manually.

Recommendation matrix