← Previous: The “Approve and run workflows” Gate

Table of Contents

Next: Operating Within a Fork →

The “Apparent vs. Actual” Trigger Surface

Many of the agentic workflow event triggers are simulated conveniences that operate over broader underlying triggers. For example, slash_command: seemingly triggers only when somebody comments /backport. In reality, it runs on every issue open/edit, every PR open/edit, every comment, every PR review comment, every discussion, and every discussion comment in the repo — and then decides to skip if the first word isn’t /backport.

The official docs acknowledge this in two places:

“By default, command triggers listen to all comment-related events, which can create skipped runs in the Actions UI. Use the events: field to restrict where commands are active.”¹

“The command must be the first word of the comment or body text to trigger the workflow. This prevents accidental triggers when the command is mentioned elsewhere in the content.”¹

The first quote concedes the noise; the second concedes that even narrow matching is post-event, not pre-event.

Review the [Triggers

GitHub Agentic Workflows](https://github.github.com/gh-aw/reference/triggers/) documentation and experiment with the gh aw compile command to ensure the desired trigger doesn’t have a broader subscription than expected and accepted for the scenario.

Why this matters operationally

Consequence	Mechanism
Runner consumption	Pre-activation job uses ubuntu-latest for ~5–30 s per skipped run; on a busy repo with slash_command: on a single small command this can be hundreds of skipped runs/day.
Copilot token consumption	Zero — the agent step is gated by the activation output and never runs in skipped cases. The COPILOT_GITHUB_TOKEN selection happens in pre-activation but no model requests are made.
Concurrency cancellations	If concurrency.group is shared across the workflow, a non-matching activation can cancel an in-progress matching one. See Concurrency and Race Conditions.
Actions UI noise	Operators learn to ignore “skipped” runs and miss real failures.
Audit surface	Every skipped run still emits webhook events for workflow_run listeners downstream.
Approval prompts (forks)	A first-time fork contributor opening any PR can produce an “Approve and run” entry on a slash_command workflow whose intent had nothing to do with PRs — see The “Approve and run workflows” Gate.

---

← Previous: The “Approve and run workflows” Gate

Table of Contents

Next: Operating Within a Fork →

1. gh-aw Command Triggers reference ↩ ↩²