YAML Workflows

Caution

You can continue to use YAML-based workflows, but we recommend using new workflows in Warp Drive instead for a better editing experience.

What is it

Workflows are easily parameterized and searchable by name, description, or command arguments. Common Workflows sourced by the Warp team and community are readily available within the app. Additionally, you can create and scope Workflows locally or to a Git repository.

How to use it

• Open the Command Search or Workflow Search Ctrl+Shift+R panel to find Workflows.
• Once inside the menu, start typing in the search bar to filter the existing Workflows. (e.g. git, android, npm, etc.)
• When a Workflow is selected with Enter, you can use Shift+Tab to cycle through the arguments.
• You can also expand the menu horizontally with the mouse by dragging it on the right edge.

Note

Tailor your Command Search experience by toggling off “Show Global Workflows” in Settings > Features > Workflows. When disabled, your search will exclusively encompass YAML and Warp Drive Workflows.

How it works

How is this different from aliases?

Workflows solve some major pain points with aliases, specifically the:

1. need to context switch
   1. leave vim, source dotfiles, or reset shell
2. difficulty with attaching documentation
3. inability to easily search or share
4. inability to easily parameterize

Creating custom workflows

How to create a workflow with YAML

You can store local workflows (scoped to your machine) in:

macOS

$HOME/.warp/workflows/

Windows

$env:APPDATA\warp\Warp\data\workflows\

Linux

${XDG_DATA_HOME:-$HOME/.local/share}/warp-terminal/workflows/

Or, you can share them with your team by saving them in {{path_to_git_repo}}/.warp/workflows/. Local and repository Workflows can be accessed under the “My Workflows” and “Repository Workflows” tab of the Workflows menu, respectively.

See the existing Workflow spec within the Workflows repo for examples. Additionally, we outline the file format below:

Workflow File Format

The Workflow file format is a yaml file and must have either a .yml or .yaml extension. If you’re new to YAML and want to learn more, see Learn YAML in Y minutes.

---

name

The name of the Workflow. Required.

command

The command that is executed when the Workflow is selected. Required.

tags

An array of tags that are useful to categorize the Workflow. Optional.

tags: ["git", "GitHub"]

description

The description of the Workflow and what it does. Optional.

source_url

The URL from where the Workflow was originally generated. Used for attribution of the original source. Optional.

author

The original author of the Workflow. For example, if this Workflow was generated from StackOverflow, the author would be the author of the StackOverflow post. Used for attribution. Optional.

author_url

The URL of the original author of the Workflow. For example, if this Workflow was generated from StackOverflow, the author_url would be the StackOverflow author’s profile page. Used for attribution. Optional.

shells

The list of shells where this Workflow is valid. If not specified, the Workflow is assumed to be valid in all shells. This must be one of zsh, bash, or fish.

arguments

A Workflow can have parameterized arguments to specify pieces of the Workflow that need to be filled in by the user.

You can specify which part of the Workflow command maps to an argument by surrounding it with two curly braces ({{<argument>}}).

For example the Workflow command:

for {{variable}} in {{sequence}}; do
  {{command}}
done

Includes 3 arguments: variable, sequence, and command.

arguments.name

The name of the argument. The argument name is used within the command to specify the ranges of the argument. Required.

name: Example Workflow
command: echo {{string}}
arguments:
  - name: string
    description: The value to echo

arguments.description

The description of the argument. Warp surfaces this to help users fill in Workflow arguments. Optional.

arguments.default_value

The default value for the argument. If specified, the default_value replaces the argument name within the command. Optional

---

Where to save workflows

Local Workflows are scoped to your machine. Repository Workflows are scoped to a Git repository and can be accessed by anyone who has cloned the repo.

macOS

# Local Workflow Path
$HOME/.warp/workflows/

# Repository Workflow Path
{{path_to_git_repo}}/.warp/workflows

Windows

# Local Workflow Path
$env:APPDATA\warp\Warp\data\workflows\

# Repository Workflow Path
{{path_to_git_repo}}\.warp\workflows

Linux

# Local Workflow Path
${XDG_DATA_HOME:-$HOME/.local/share}/warp-terminal/workflows/

# Repository Workflow Path
{{path_to_git_repo}}/.warp/workflows

Local Workflows

To start, create a Workflow subdirectory within

macOS

mkdir -p $HOME/.warp/workflows/

Windows

New-Item -Path "$env:APPDATA\warp\Warp\data\workflows\" -ItemType Directory

Linux

mkdir -p ${XDG_DATA_HOME:-$HOME/.local/share}/warp-terminal/workflows/

Add your Workflow’s .yaml file to this directory; if the file format is valid Warp should automatically load it into the Workflows menu.

cp ~/path/to/my_awesome_workflow.yaml {{path_to_local_workflow_folder}}

Repository Workflows

You can add a repository Workflow similarly to how you added a local Workflow. Create a Workflows folder in a repository’s root directory and save your .yaml file like so:

cd {{repository_path}}
mkdir -p .warp/workflows/
cp ~/path/to/my_awesome_workflow.yaml {{path_to_local_workflow_folder}}

Global Workflows

You can contribute Workflows that will be made available to other Warp users by forking the Workflows repo and opening a pull request. See the Contributing section for more details.