Problem
When using slash_command in an agentic workflow, the compiler generates triggers for all event types (issue_comment, issues, pull_request, pull_request_review_comment, discussion, discussion_comment). This means every PR open/edit event triggers the workflow, which immediately gets skipped at the pre_activation gate — but still shows up as a cancelled/skipped run in the Actions UI.
For workflows that are issue-only (e.g., a bug investigation pipeline where /investigate only makes sense on issues, not PRs), this creates significant noise. In our repo we have 4 agentic workflows in the bug pipeline, so every PR push creates 4 skipped runs.
Context
We have a label-based bug pipeline with 4 agentic workflows (investigator → analyst → fixer → PR review) dispatched via workflow_dispatch from a unified dispatcher. The /investigate, /analyze, /fix slash commands are only meant for manual re-triggers on issues. Every PR in the repo creates 4 extra skipped runs.
Problem
When using
slash_commandin an agentic workflow, the compiler generates triggers for all event types (issue_comment,issues,pull_request,pull_request_review_comment,discussion,discussion_comment). This means every PR open/edit event triggers the workflow, which immediately gets skipped at thepre_activationgate — but still shows up as a cancelled/skipped run in the Actions UI.For workflows that are issue-only (e.g., a bug investigation pipeline where
/investigateonly makes sense on issues, not PRs), this creates significant noise. In our repo we have 4 agentic workflows in the bug pipeline, so every PR push creates 4 skipped runs.Context
We have a label-based bug pipeline with 4 agentic workflows (investigator → analyst → fixer → PR review) dispatched via
workflow_dispatchfrom a unified dispatcher. The/investigate,/analyze,/fixslash commands are only meant for manual re-triggers on issues. Every PR in the repo creates 4 extra skipped runs.