# Slash Command Dispatch keeps the GitHub Actions queue free by moving commands elsewhere

> slash-command-dispatch is a GitHub action that reads slash commands from issue comments and turns them into repository dispatch or workflow dispatch events, so the heavy processing happens in a separate workflow. It suits teams doing ChatOps in busy repositories, at the cost of needing a repo scoped personal access token.

**peter-evans/slash-command-dispatch** — A GitHub action that facilitates "ChatOps" by creating repository dispatch events for slash commands

- Repository: https://github.com/peter-evans/slash-command-dispatch
- Stars: 711 · Forks: 62
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/peter-evans-slash-command-dispatch

## The problem is queue congestion, not command parsing

The usual way to do ChatOps with slash commands in GitHub is to parse them during issue_comment events and act on them right there. The README explains why that breaks down: in repositories with a lot of activity, the workflow queue gets backed up very quickly trying to handle new issue_comment events and process the commands themselves.

That is the specific problem this action addresses, and the distinction matters. The hard part of a ChatOps bot is not recognising that a comment says /deploy. It is keeping the repository responsive while a deploy runs. Slash Command Dispatch splits the two: the comment workflow only reads the first line of the comment, checks it against a configured list of commands, and if it matches, creates a dispatch event carrying the full details of the command and its context. The actual work then happens in a different workflow.

The stated benefit of that split is that the workflow queue keeps moving quickly, and it essentially enables parallel processing of workflows. There is a second, quieter benefit for organisations: non-sensitive workloads can run in public repositories, which saves using private repository GitHub Action minutes.

## Repository dispatch versus workflow dispatch

The action creates two different kinds of event, and which one you get is controlled by the dispatch-type input, whose default is repository.

A repository dispatch event is a general purpose trigger that you attach a workflow to by matching the event type. The action sets the event type suffix through the event-type-suffix input, which defaults to -command, so the type a processor workflow listens for is derived from the command name. A workflow dispatch event, by contrast, is GitHub's mechanism for running a workflow with defined input parameters, and the action supports creating those too.

Both kinds of event are created with a token that has to be a repo scoped Personal Access Token. The README is explicit that the default GITHUB_TOKEN does not have the scopes to create these events, and that if you are dispatching to public repositories only, the more limited public_repo scope is enough. If you use the action inside a GitHub organisation, the user the PAT is created on must be a member of that organisation, and the PAT should be given the org:read scope.

That token requirement is the main operational difference between this action and a plain comment-parsing workflow, and it is worth settling before anything else.

## A minimal workflow with three commands

The standard configuration goes in the repository the commands are dispatched from, and the README shows a workflow responding to /deploy, /integration-test and /build-docs:

```yml
name: Slash Command Dispatch
on:
  issue_comment:
    types: [created]
jobs:
  slashCommandDispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Slash Command Dispatch
        uses: peter-evans/slash-command-dispatch@v5
        with:
          token: ${{ secrets.PAT }}
          commands: |
            deploy
            integration-test
            build-docs
```

Two details in that file carry most of the behaviour. The event filter is types: [created], which means only newly created comments trigger the workflow, and the commands input is a newline separated list of the command names without their leading slash.

The README also points out that not specifying the repository input means dispatch events are created in the current repository by default, and that this is entirely reasonable. It is fine to use the current repository and not dispatch to a separate processor repository. The action only recommends the advanced configuration when you actually need per-command settings.

## Who is allowed to run a command, and where it can be typed

Three inputs control access and placement, and they are where the security-relevant decisions live.

The permission input sets the repository permission level a user must hold to dispatch commands. The options are none, read, triage, write, maintain and admin, and the default is write. The issue-type input restricts where the command may be typed, with the options issue, pull-request and both, defaulting to both. The allow-edits input, defaulting to false, decides whether editing an existing comment can trigger a dispatch, which is a meaningful setting because an edited comment is content someone with write access can change after the fact.

The action also adds reactions to the comment by default. The reactions input controls this, with the seen reaction marking the command as picked up and the dispatched reaction marking it as sent on, and its default is true. The reaction-token input exists so that those reactions can be posted with a different identity from the one creating the dispatch events. Left alone it uses the default GITHUB_TOKEN, and the reaction-token input is where you point it at a PAT if you want the two identities separated.

## The advanced configuration file, and what the standard mode leaves out

Standard configuration gives you a flat list of command names. The advanced configuration lets each command be configured individually, and it comes in two forms: the config input takes JSON configuration for commands, and the config-from-file input takes JSON configuration from a file.

The README's advice is to use the standard configuration unless you require the advanced features, which is worth taking literally. The standard mode is a list of names and nothing else, so there is no place to declare expected arguments, no per-command permission, and no way to attach static values beyond the one static-args input, which is a comma or newline separated list of arguments dispatched with every command.

Static arguments are the mechanism for putting shared context into the payload without repeating it in every comment. A build command that always needs a branch, for example, could carry that branch in static-args so the command itself stays short. The trade-off is that static values apply to every command in the workflow, so the moment two commands need different defaults, you are into the JSON configuration and its per-command model.

## A TypeScript action with a bundled dist directory

The repository layout is what you would expect for a JavaScript GitHub action written in TypeScript. There is src/ for the source, dist/ for the bundled output that GitHub actually runs, action.yml for the action metadata, and docs/ for the documentation the README links to, including getting-started, examples, advanced-configuration, workflow-dispatch and an updating guide for moving to v4.

The package.json shows the shape of the project. The build script is tsc followed by ncc build, the test scripts are jest unit and jest int, and linting is eslint over src. The engine requirement is node >=24.4.0. The runtime dependencies are the GitHub toolkit packages @actions/core and @actions/github, several @octokit packages including the rest endpoint methods and paginate rest plugins, and the http-proxy-agent and https-proxy-agent packages.

The licence is MIT, which is the permissive end of the scale and carries no obligation on the repositories that use the action beyond keeping the notice. The release record shows v5.0.0 in November 2025, then v5.0.1 and v5.0.2 in December 2025, with the last push to main on 2026-10-12. The action is also listed on the GitHub Marketplace, which is how most teams will consume it.

## Conclusion

Adopt slash-command-dispatch when your repository runs ChatOps in comments and the workflow queue is backing up, since dispatching the command out of the comment workflow is the specific problem it solves. Skip it if you have one low-traffic repository, if you cannot issue a repo scoped personal access token, or if you need per-command argument validation without writing the advanced JSON configuration yourself. Before you wire it up, read the token section, because GITHUB_TOKEN does not work for dispatch events, confirm the permission input matches the level your commenters actually hold, and check the reaction-token input if you want the seen and dispatched reactions to come from a different identity. The action is at v5.0.2 with a push to main on 2026-10-12, so pin the version tag you test against rather than tracking main.

## FAQ

### What does the Slash Command Dispatch GitHub action do?

It runs in issue_comment event workflows, checks the first line of comments for slash commands, and when it finds a valid one it creates a repository dispatch event whose payload holds the full details of the command and its context. It can also create workflow dispatch events with defined input parameters.

### Why does Slash Command Dispatch need a personal access token?

The default GITHUB_TOKEN does not have the scopes needed to create repository dispatch and workflow dispatch events, so a repo scoped Personal Access Token is required. If you dispatch to public repositories only, the more limited public_repo scope is enough, and in an organisation the PAT user must be a member and the PAT should carry the org:read scope.

### How do I restrict who can run a slash command with this action?

The permission input sets the repository permission level a user needs to dispatch a command, with the options none, read, triage, write, maintain and admin, and write as the default. The issue-type input limits commands to issues, pull requests or both, and allow-edits controls whether edited comments can trigger a dispatch.

### Can Slash Command Dispatch send commands to a different repository?

Yes, the repository input takes the full name of the repository to send the dispatch events to, and leaving it out means the events are created in the current repository. The README says it is perfectly fine to dispatch to the same repository and not use a separate processor repository.

### What is the difference between repository dispatch and workflow dispatch in this action?

The dispatch-type input selects between them, with repository as the default. A repository dispatch triggers workflows by event type, with the type suffix set by the event-type-suffix input, while a workflow dispatch runs a workflow with defined input parameters.

## Sources

- [Issues](https://github.com/peter-evans/slash-command-dispatch/issues)
- [License: MIT](https://github.com/peter-evans/slash-command-dispatch/blob/main/LICENSE)
- [peter-evans/slash-command-dispatch on GitHub](https://github.com/peter-evans/slash-command-dispatch)
- [README](https://github.com/peter-evans/slash-command-dispatch/blob/main/README.md)
- [Releases](https://github.com/peter-evans/slash-command-dispatch/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/peter-evans-slash-command-dispatch