Workflows enable users to define a series of steps to guide Cascade through a repetitive set of tasks, such as deploying a service or responding to PR comments. These Workflows are saved as markdown files, allowing users and their teams an easy repeatable way to run key processes. Once saved, Workflows can be invoked in Cascade via a slash command with the format of /[name-of-workflow]

​
How it works

Rules generally provide large language models with guidance by providing persistent, reusable context at the prompt level. Workflows extend this concept by providing a structured sequence of steps or prompts at the trajectory level, guiding the model through a series of interconnected tasks or actions.
To execute a Workflow, users simply invoke it in Cascade using the /[workflow-name] command.
You can call other Workflows from within a Workflow!

For example, /workflow-1 can include instructions like “Call /workflow-2” and “Call /workflow-3”.
Upon invocation, Cascade sequentially processes each step defined in the Workflow, performing actions or generating responses as specified.

​
How to create a Workflow

To get started with Workflows, click on the Customizations icon in the top right slider menu in Cascade, then navigate to the Workflows panel. Here, you can click on the + Workflow button to create a new Workflow. Workflows are saved as markdown files within .windsurf/workflows/ directories and contain a title, description, and a series of steps with specific instructions for Cascade to follow.

​
Workflow Discovery

Windsurf automatically discovers workflows from multiple locations to provide flexible organization:
  • Current workspace and sub-directories: All .windsurf/workflows/ directories within your current workspace and its sub-directories
  • Git repository structure: For git repositories, Windsurf also searches up to the git root directory to find workflows in parent directories
  • Multiple workspace support: When multiple folders are open in the same workspace, workflows are deduplicated and displayed with the shortest relative path

​
Workflow Storage Locations

Workflows can be stored in any of these locations:
  • .windsurf/workflows/ in your current workspace directory
  • .windsurf/workflows/ in any sub-directory of your workspace
  • .windsurf/workflows/ in parent directories up to the git root (for git repositories)
When you create a new workflow, it will be saved in the .windsurf/workflows/ directory of your current workspace, not necessarily at the git root. Workflow files are limited to 12000 characters each.

​
Generate a Workflow with Cascade

You can also ask Cascade to generate Workflows for you! This works particularly well for Workflows involving a series of steps in a particular CLI tool.

​
Example Workflows

There are a myriad of use cases for Workflows, such as:

/address-pr-comments

This is a Workflow our team uses internally to address PR comments:
1. Check out the PR branch: `gh pr checkout [id]`

2. Get comments on PR

 bash
 gh api --paginate repos/[owner]/[repo]/pulls/[id]/comments | jq '.[] | {user: .user.login, body, path, line, original_line, created_at, in_reply_to_id, pull_request_review_id, commit_id}'

3. For EACH comment, do the following. Remember to address one comment at a time.
 a. Print out the following: "(index). From [user] on [file]:[lines] — [body]"
 b. Analyze the file and the line range.
 c. If you don't understand the comment, do not make a change. Just ask me for clarification, or to implement it myself.
 d. If you think you can make the change, make the change BEFORE moving onto the next comment.

4. After all comments are processed, summarize what you did, and which comments need the USER's attention.

/git-workflows

Commit using predefined formats and create a pull requests with standardized title and descriptions using the appropriate CLI commands.

/dependency-management

Automate the installation or updating of project dependencies based on a configuration file (e.g., requirements.txt, package.json).

/code-formatting

Automatically run code formatters (like Prettier, Black) and linters (like ESLint, Flake8) on file save or before committing to maintain code style and catch errors early.

/run-tests-and-fix

Run or add unit or end-to-end tests and fix the errors automatically to ensure code quality before committing, merging, or deploying.

/deployment

Automate the steps to deploy your application to various environments (development, staging, production), including any necessary pre-deployment checks or post-deployment verifications.

/security-scan

Integrate and trigger security vulnerability scans on your codebase as part of the CI/CD pipeline or on demand.