warpdotdev/workflows is the public catalogue of command recipes for Warp

A catalogue of recipes, not an application

The repository describes itself as the home for all public Workflows that appear within Warp and within commands.dev, and the project description says what a Workflow is for: making it easy to browse, search, execute and share commands, or a series of commands, without leaving the terminal.

That is a narrower thing than a shell framework, and the repository layout matches the narrowness. There is a `specs/` directory where every workflow is defined as a YAML file, a `FORMAT.md` that documents the file format in detail, a `workflow-types/` directory and a `workflows/` directory, a `build_ts/` directory, a `script/` directory and a `Cargo.toml` that defines a Rust workspace.

The Rust part is the surprise, and it is explained by the README's own testing note, which says you can build the workflows locally to validate that the schema is correct, with the comment that this ensures the workflows can successfully be converted into Rust. So the YAML files are the source of truth for the catalogue, and they are compiled into Rust for the product, which is what makes a build a real validation step rather than a formality.

The primary language is recorded as Rust, the licence is Apache-2.0 with the licence text in the `LICENSE` file, and the workspace metadata names the Warp Team as the author and sets `publish = false`, so nothing here is published to a package registry. The default branch is `main` and the repository has no GitHub releases, which is consistent with a repository whose versions are the tags of the terminal product rather than of this catalogue.

A workflow is a YAML spec with named arguments

The example in the README is the fastest way to understand the format, and it is worth reading in full because the fields are opinionated.

---
# The name of the workflow.
name: Uninstall a Homebrew package and all of its dependencies
# The corresponding command for the workflow. Any arguments should be surrounded with two curly braces. E.g `command {{arg}}`.
command: |-
    brew tap beeftornado/rmtree
    brew rmtree {{package_name}}
# Any tags that the workflow should be categorized with.
tags:
  - homebrew
# A description of the workflow.
description: Uses the external command rmtree to remove a Homebrew package and all of its dependencies

The convention is that a parameter is written as a double curly brace placeholder inside the command string, and that the same name has to appear in the arguments list. The argument block is where the user-facing metadata lives.

arguments:
    # Name of the argument within the command. This must exactly match the name of the argument
    # within the command (without the curly braces).
  - name: package_name
    # The description of the argument.
    description: The name of the package that should be removed
    # The default value for the argument.
    default_value: ~

The comment on the name field is the rule that matters. The argument name must match the placeholder in the command exactly, without the braces, and a mismatch is the kind of error that the Rust build would catch rather than something a user would discover by typing.

The rest of the spec carries provenance. There is a `source_url` for where the workflow was generated from, an `author` field, an `author_url` for the original author's profile page, and a `shells` field listing the shells where the workflow should be active, which can be left empty when it applies to all of them.

The shells field is where portability is decided

Most fields in the format exist to make the catalogue searchable. The `shells` field exists to keep a workflow from being offered where it would not work.

The README explains that the field lists the valid shells where the workflow should be active, that it can be left empty if the workflow is valid for all shells, and that the full list of accepted values is in `FORMAT.md`. The repository topics name bash, fish and zsh, which is the set of shells the format is aware of.

This is a small field with a large effect on the catalogue, because a workflow that is valid in bash and offered in fish is a bad experience, and a workflow that is valid in all three is one every user gets. The README's guidance to keep the tags accurate for the same reason, to improve searchability, points at the same principle, which is that the metadata exists to make the right workflow findable by the right person.

The `shells` list is also where a contributed workflow most often has to be checked rather than assumed. A workflow built around a shell function, a specific pipeline, or a tool that only exists in one shell should declare it, and the maintainers can then rely on the field when they review the spec.

For a reader of the catalogue, the same metadata is what makes commands.dev usable, since the README says all public workflows in the repository are also available there, and that the workflows are searchable by name, description or command.

Testing a spec locally before you submit it

The testing section is the most practically useful part of the README, and it offers two routes.

The first is to run the workflow inside Warp as a local workflow. You copy the file into your own workflows directory.

    mkdir -p ~/.warp/workflows && cp {{workflow}}.yaml ~/.warp/workflows/

Then you open Warp, press `ctrl-shift-r` or use the command palette, click on My Workflows on the left to filter for local workflows, and click the workflow you added to check the information is correct.

The second route is a build, and the README is explicit about what it proves, which is that the workflow file format is valid.

# Download the rust toolchain, if not already installed.
brew install rustup
rustup-init

# Ensure the workflows can successfully be converted into Rust.
cargo build

The distinction between the two is worth holding on to. The local workflow test checks that the command works and that the metadata reads correctly, and the cargo build checks that the spec converts. A workflow can pass one and fail the other, and a pull request that claims to be tested is expected to have done both.

The Rust toolchain is therefore a prerequisite for contributing, not only for the maintainers. The README installs it with rustup through Homebrew, which is the same path the workflow catalogue itself assumes, since the example workflow removes a Homebrew package.

What the project considers a useful workflow

The README closes with a quality bar, and it is short enough to quote in substance.

A good workflow is one that includes a command with many flags or arguments, or one that is hard to remember. That is the entire test of usefulness, and it is a sensible one, because a workflow that wraps a short and memorable command saves nobody anything.

Beyond that, a workflow must include several things. A descriptive title that includes the name of the command, which the README justifies as useful for improving the experience of searching for workflows in Warp or on commands.dev. A tag that accurately categorizes it, with the advice to avoid many repetitive tags to improve searchability. A description for the workflow and for each of its arguments where applicable. And a default value for each argument where applicable.

The emphasis on titles and tags is the searchable-catalogue argument again. A repository of commands is only as useful as its indexing, and a pack of a hundred workflows all tagged shell is indistinguishable from a pack of a hundred untagged ones. The same goes for titles that name the command, since the search in the README is by name, description or command.

The contribution model is a pull request against a spec file, and the README's guidance for a new contributor is to send a PR if you have a workflow that would be useful to many Warp users, with the documentation on creating local or repository workflows linked for the mechanics. The default branch is `main`, and the last push was on 2026-09-09.

Editorial conclusion

This repository fits someone who keeps retyping a long command with many flags and wants to publish that recipe so other people can install it, and it fits a team that wants a searchable, versioned catalogue of its own internal commands. Skip it if you are not using Warp, since the specs are consumed by that terminal and by commands.dev. Verify first that the format documentation matches what you are about to submit, that your command is portable across the shells you declare, and that the Rust build passes before you open the pull request.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. warpdotdev/workflows on GitHub