Skip to content

Add FAQ entry clarifying slash-command trigger noise and LabelOps mitigation #27389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
pelikhan merged 3 commits into from
Apr 20, 2026
+16 −1
Merged

Add FAQ entry clarifying slash-command trigger noise and LabelOps mitigation #27389

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f7852e1
Initial plan
Copilot Apr 20, 2026
341cd01
docs: add FAQ on slash command skipped runs and labelops noise reduction
Copilot Apr 20, 2026
7f8390d
Merge branch 'main' into copilot/fix-unwanted-slash-command-actions
pelikhan Apr 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion docs/src/content/docs/reference/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -261,6 +261,22 @@ See [Integrity Filtering](/gh-aw/reference/integrity/) for available levels, use

## Configuration & Setup

### Why do slash-command workflows show many "started then skipped" runs on comments?

This is expected behavior. A `slash_command` is compiled into multiple GitHub event listeners (issue/PR bodies, issue comments, PR comments, and review comments, depending on `events:`). GitHub first dispatches the event, then the activation logic checks whether the comment starts with a matching command (for example `/refresh`). If it does not match, the run exits early and appears as a quick skipped/no-op run in Actions.

To reduce this noise, narrow the trigger scope with `events:` so the workflow only listens where you actually use commands, and use [LabelOps](/gh-aw/patterns/label-ops/) for command-style operations that should not activate on every comment. LabelOps (`label_command`) triggers only when a specific label is applied, which produces fewer incidental runs than broad comment listeners.
Comment on lines +266 to +268
Copy link

Copilot AI Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explanation of which surfaces can trigger slash_command appears incomplete: command triggers can also be configured for discussions (discussion, discussion_comment) per docs/src/content/docs/reference/command-triggers.md (supported events list). Consider updating this paragraph to include discussions (or point to the supported event identifiers) so readers don’t assume slash commands are limited to issues/PRs.

Suggested change
This is expected behavior. A `slash_command` is compiled into multiple GitHub event listeners (issue/PR bodies, issue comments, PR comments, and review comments, depending on `events:`). GitHub first dispatches the event, then the activation logic checks whether the comment starts with a matching command (for example `/refresh`). If it does not match, the run exits early and appears as a quick skipped/no-op run in Actions.
To reduce this noise, narrow the trigger scope with `events:` so the workflow only listens where you actually use commands, and use [LabelOps](/gh-aw/patterns/label-ops/) for command-style operations that should not activate on every comment. LabelOps (`label_command`) triggers only when a specific label is applied, which produces fewer incidental runs than broad comment listeners.
This is expected behavior. A `slash_command` is compiled into multiple GitHub event listeners (for example issue/PR bodies, issue comments, PR comments, review comments, and discussion surfaces, depending on `events:`). GitHub first dispatches the event, then the activation logic checks whether the comment starts with a matching command (for example `/refresh`). If it does not match, the run exits early and appears as a quick skipped/no-op run in Actions.
To reduce this noise, narrow the trigger scope with `events:` so the workflow only listens where you actually use commands. See the [`slash_command` supported event identifiers](/gh-aw/reference/command-triggers/) for the full list, including discussion-related events. You can also use [LabelOps](/gh-aw/patterns/label-ops/) for command-style operations that should not activate on every comment. LabelOps (`label_command`) triggers only when a specific label is applied, which produces fewer incidental runs than broad comment listeners.

Copilot uses AI. Check for mistakes.

```yaml wrap
on:
slash_command:
name: refresh
events: [pull_request_comment] # only listen to PR comments
label_command:
name: refresh
events: [pull_request] # optional low-noise label trigger
```

### What is a workflow lock file?

A **workflow lock file** (`.lock.yml`) is the compiled GitHub Actions workflow generated from your `.md` file by `gh aw compile`. It contains SHA-pinned actions, resolved imports, configured permissions, and all guardrail hardening - inspect it to see exactly what will run, with no hidden configuration.
Expand Down Expand Up @@ -521,4 +537,3 @@ engine: claude
```

See [AI Engines](/gh-aw/reference/engines/) for all configuration options.

Loading