Command Triggers

GitHub Agentic Workflows add the convenience slash_command: trigger to create workflows that respond to /my-bots in issues and comments.

on:
  slash_command:
    name: my-bot  # Optional: defaults to filename without .md extension

You can also use shorthand formats:

on:
  slash_command: "my-bot"  # Shorthand: string directly specifies command name

on: /my-bot  # Ultra-short: slash prefix automatically expands to slash_command + workflow_dispatch

Multiple Command Identifiers

A single workflow can respond to multiple slash command names by providing an array of command identifiers:

on:
  slash_command:
    name: ["cmd.add", "cmd.remove", "cmd.list"]

When triggered, the matched command is available as needs.activation.outputs.slash_command, allowing your workflow to determine which command was used:

---
on:
  slash_command:
    name: ["summarize", "summary", "tldr"]
---

# Multi-Command Handler

You invoked the workflow using: `/${{ needs.activation.outputs.slash_command }}`

Now analyzing the content...

This feature enables command aliases and grouped command handlers without workflow duplication.

This automatically creates issue/PR triggers (opened, edited, reopened), comment triggers (created, edited), and conditional execution matching /command-name mentions.

Code availability: When a command is triggered from a pull request body, PR comment, or PR review comment, the coding agent has access to both the PR branch and the default branch.

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.

You can combine slash_command: with other events like workflow_dispatch or schedule:

on:
  slash_command:
    name: my-bot
  workflow_dispatch:
  schedule: weekly on monday

Note: You cannot combine slash_command with issues, issue_comment, or pull_request as they would conflict.

Exception for Label-Only Events: You CAN combine slash_command with issues or pull_request if those events are configured for label-only triggers (labeled or unlabeled types only). This allows workflows to respond to slash commands while also reacting to label changes.

on:
  slash_command: deploy
  issues:
    types: [labeled, unlabeled]  # Valid: label-only triggers don't conflict

This pattern is useful when you want a workflow that can be triggered both manually via commands and automatically when labels change.

Filtering Command Events

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:

on:
  slash_command:
    name: my-bot
    events: [issues, issue_comment]  # Only in issue bodies and issue comments

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

Issue-only command (avoids skipped runs from PR events):

on:
  slash_command:
    name: investigate
    events: [issues, issue_comment]

PR-only command:

on:
  slash_command:
    name: code-review
    events: [pull_request, pull_request_comment]

Context Text

All workflows access steps.sanitized.outputs.text, which provides sanitized context: for issues and PRs, it’s title + "\n\n" + body; for comments and reviews, it’s the body content.

# Analyze this content: "${{ steps.sanitized.outputs.text }}"

Why sanitized context? The sanitized text neutralizes @mentions and bot triggers (like fixes #123), protects against XML injection, filters URIs to trusted HTTPS domains, limits content size (0.5MB max, 65k lines), and strips ANSI escape sequences.

Comparison:

# RECOMMENDED: Secure sanitized context
Analyze this issue: "${{ steps.sanitized.outputs.text }}"

# DISCOURAGED: Raw context values (security risks)
Title: "${{ github.event.issue.title }}"
Body: "${{ github.event.issue.body }}"

Reactions

Command workflows automatically add the “eyes” () emoji reaction to triggering comments and edit them with workflow run links, providing immediate feedback. Customize the reaction:

on:
  slash_command:
    name: my-bot
  reaction: "rocket"  # Override default "eyes"

See Reactions for available reactions and detailed behavior.

Slash Commands in SideRepoOps

GitHub Actions only delivers events to the repository where they occur. With SideRepoOps — where workflows live in a separate side repository — events from the main repository are never delivered there. Slash command triggers cannot be used directly in a SideRepoOps workflow.

The recommended solution is a bridge pattern: a thin relay workflow in the main repository receives the slash command and forwards it to the side repository via workflow_dispatch.

See Slash Commands in SideRepoOps for a full walkthrough with examples and trade-offs.

Related Documentation

• Frontmatter - All configuration options for workflows
• Workflow Structure - Directory layout and organization
• CLI Commands - CLI commands for workflow management
• SideRepoOps - Running workflows from a separate repository
• ChatOps - Interactive automation with slash commands