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:

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 enables aliases and grouped handlers without duplicating workflows.

The compiler automatically creates issue/PR triggers (opened, edited, reopened), comment triggers (created, edited), and conditional execution for /command-name mentions. The command must be the first word of the comment or body text to avoid accidental triggers.

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.

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

Centralized trigger strategy

Set on.slash_command.strategy: centralized to route slash commands through a shared dispatcher. The workflow compiles as workflow_dispatch-centric, and the compiler generates one agentic_commands.yml workflow that listens to merged slash-command events and dispatches matching target workflows with aw_context.

Centralized routing also enables a builtin /help command that comments on the current issue, pull request, or discussion with the supported slash commands, their descriptions, and a link to this documentation.

To disable the builtin handler, set the top-level help_command field in .github/workflows/aw.json:

{
  "help_command": false
}

on:
  slash_command:
    name: my-bot
    strategy: centralized

With the default inline strategy, you cannot combine slash_command with issues, issue_comment, or pull_request because those triggers conflict. With strategy: centralized, non-slash events are preserved because slash matching moves to the generated central trigger workflow.

You can still combine slash_command with issues or pull_request when those events are label-only (labeled or unlabeled).

Combining slash_command with bots:

Concurrency clash

Combining slash_command with on.bots: produces a compile-time warning. When a bot listed in bots: posts a comment that begins with the slash command text (e.g., /command-name), the command check passes and the bot triggers the workflow — occupying the concurrency slot and potentially blocking a simultaneous manual invocation, since cancel-in-progress is disabled for command-trigger workflows.

To ensure the workflow only runs on explicit user commands, remove the bots: field.

# This configuration produces a compile-time warning:
on:
  slash_command:
    name: rust-review
    events: [pull_request, pull_request_comment]
  bots:
    - "copilot[bot]"

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 events: 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 workflows

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 }}"

Use sanitized context instead of raw event fields. It neutralizes @mentions and bot triggers (such as 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.

# 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 and Status Comments

Command workflows default to reaction: eyes () and status-comment: true. The reaction marks the triggering comment, and the status comment posts started/completed updates with a workflow run link.

Customize or disable either:

on:
  slash_command:
    name: my-bot
  reaction: "rocket"       # Override default "eyes"
  status-comment: false    # Disable the status comment

To disable the reaction entirely, use reaction: none.

See Reactions and Status Comments for all available reactions and detailed behavior.

Customizing the Run-Again Hint (placeholder)

For workflows with a slash_command: trigger, the default footer on generated issues and pull requests includes a hint showing how to invoke the workflow again:

_{Comment /my-bot to run again}

Override the trailing "to run again" suffix with placeholder::

on:
  slash_command:
    name: review-bot
    placeholder: to review this PR

The footer hint then reads:

_{Comment /review-bot to review this PR}

The hint is appended only by the default footer template. Custom footer templates are unaffected.

Slash Commands from a Side Repository

GitHub Actions only delivers events to the repository where they occur, so events from the main repository never reach workflows hosted in a side repository. Slash command triggers cannot be used directly in a workflow hosted in a side repository.

Use a bridge pattern instead: a thin relay workflow in the main repository receives the slash command and forwards it to the side repository via workflow_dispatch.

See Triage from Side Repo 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
• MultiRepoOps — Running workflows from a separate repository
• ChatOps - Interactive automation with slash commands