docs: expand slash command event filtering documentation

docs/src/content/docs/reference/command-triggers.md

@@ -83,7 +83,7 @@ This pattern is useful when you want a workflow that can be triggered both manua
 
 ## Filtering Command Events
 
-By default, command triggers respond to `/command-name` mentions in all comment-related contexts. Use the `events:` field to restrict where commands are active:
+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:
 
 ```yaml wrap
 on:
@@ -92,58 +92,30 @@ on:
     events: [issues, issue_comment]  # Only in issue bodies and issue comments
 ```
 
-**Supported events:** `issues` (issue bodies), `issue_comment` (issue comments only), `pull_request_comment` (PR comments only), `pull_request` (PR bodies), `pull_request_review_comment` (PR review comments), `discussion` (discussion bodies), `discussion_comment` (discussion comments), or `*` (all comment events, default).
+**Supported events:** `issues`, `issue_comment`, `pull_request`, `pull_request_comment`, `pull_request_review_comment`, `discussion`, `discussion_comment`, or `*` (all, default).
+
+:::note
+Both `issue_comment` and `pull_request_comment` map to GitHub Actions' `issue_comment` event with automatic filtering to distinguish between issue and PR comments.
+:::
 
 ### Example command workflow
 
-Using object format:
+Issue-only command (avoids skipped runs from PR events):
 
-```aw wrap
----
+```yaml wrap
 on:
   slash_command:
-    name: summarize-issue
-tools:
-  github:
-    toolsets: [issues]
----
-
-# Issue Summarizer
-
-When someone mentions /summarize-issue in an issue or comment, 
-analyze and provide a helpful summary.
-
-The current context text is: "${{ steps.sanitized.outputs.text }}"
+    name: investigate
+    events: [issues, issue_comment]
 ```
 
-PR-focused example using event filtering to restrict to pull requests and PR comments:
+PR-only command:
 
-```aw wrap
----
+```yaml wrap
 on:
   slash_command:
     name: code-review
     events: [pull_request, pull_request_comment]
-permissions:
-  contents: read
-tools:
-  github:
-    toolsets: [pull_requests]
-safe-outputs:
-  add-comment:
-    max: 5
-timeout-minutes: 10
----
-
-# Code Review Assistant
-
-When someone mentions /code-review in a pull request or PR comment,
-analyze the code changes and provide detailed feedback.
-
-The current context is: "${{ steps.sanitized.outputs.text }}"
-
-Review the pull request changes and add helpful review comments on specific
-lines of code where improvements can be made.
 ```
 
 ## Context Text

docs/src/content/docs/reference/triggers.md

@@ -281,7 +281,18 @@ See the [Security Architecture](/gh-aw/introduction/architecture/) for details.
 
 ### Command Triggers (`slash_command:`)
 
-The `slash_command:` trigger creates workflows that respond to `/command-name` mentions in issues, pull requests, and comments. See [Command Triggers](/gh-aw/reference/command-triggers/) for complete documentation including event filtering, context text, reactions, and examples.
+The `slash_command:` trigger creates workflows that respond to `/command-name` mentions in issues, pull requests, and comments.
+
+By default, command triggers listen to **all** comment-related events, which can create noise from skipped runs. Use the `events:` field to restrict where commands are active:
+
+```yaml wrap
+on:
+  slash_command:
+    name: investigate
+    events: [issues, issue_comment]  # Only respond in issue contexts
+```
+
+See [Command Triggers](/gh-aw/reference/command-triggers/) for complete documentation including event filtering, context text, reactions, and examples.
 
 ### Label Command Trigger (`label_command:`)