---
title: "Workflows"
sidebarTitle: "Workflows"
description: "Automate repetitive tasks with Markdown-based workflow files."
---

Workflows are Markdown files that define a series of steps to guide Cline through repetitive or complex tasks. Type `/` followed by the workflow's filename to invoke it (e.g., `/deploy.md`).

Deploying, setting up a new project, running through a release checklist: these tasks often require remembering a dozen steps, running commands in the right order, and updating files manually. Mess up one step and you're debugging for an hour. Workflows turn those multi-step processes into one command. Type `/release.md` and Cline handles the version bump, runs tests, updates the changelog, commits, tags, and pushes. You just review and approve.

## Workflow Structure

A workflow is a markdown file with a title and steps. The filename becomes the command: `demo-workflow.md` is invoked with `/demo-workflow.md`.

````markdown title="demo-workflow.md"
# Demo Workflow

Brief description of what this workflow accomplishes.

## Step 1: Check prerequisites
Verify the environment is ready. Look for required tools and dependencies.

## Step 2: Run the build
Execute the build command:
```bash
npm run build
```

## Step 3: Verify results
Check that the build completed successfully and report any issues.
````

Steps can be written at different levels of detail:

- **High-level**: "Run the test suite and fix any failures" lets Cline decide how to accomplish the goal
- **Specific**: Use XML tool syntax or exact commands when you need precise control

## Creating Workflows

<Steps>
  <Step title="Open the Workflows menu">
    Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Workflows tab.
  </Step>
  <Step title="Create a new workflow file">
    Click "New workflow file..." and enter a filename (e.g., `deploy`). The file will be created with a `.md` extension.
  </Step>
  <Step title="Write your workflow">
    Add a title and numbered steps in markdown format. Describe what each step should accomplish.
  </Step>
</Steps>

<Tip>
**Create workflows from completed tasks.** After finishing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." Cline analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
</Tip>

### Invoking Workflows

Type `/` in the chat input to see available workflows. Cline shows autocomplete suggestions as you type, so `/rel` would match `release-prep.md`. Select a workflow and press Enter to start it.

Cline executes each step in sequence, pausing for your approval when needed. You can stop a workflow at any point by rejecting a step.

### Toggling Workflows

Every workflow has a toggle to enable or disable it. This lets you control which workflows appear in the `/` menu without deleting the file.

## Where Workflows Live

Workflows can be stored in two locations: your project workspace or globally on your system.

**Workspace workflows** go in `.clinerules/workflows/` at your project root. Use these for project-specific automation like deployment scripts, release processes, or setup procedures that your team shares.

**Global workflows** go in your system's Cline Workflows directory. Use these for personal productivity workflows you use across all projects.

### Global Workflows Directory

| Operating System | Default Location |
|------------------|------------------|
| Windows | `Documents\Cline\Workflows` |
| macOS | `~/Documents/Cline/Workflows` |
| Linux/WSL | `~/Documents/Cline/Workflows` |

Workspace workflows take precedence when names match global workflows. See [Storage Locations](/customization/overview#storage-locations) for more guidance.

## What Workflows Can Use

Workflows can combine natural language instructions with specific tool calls. This flexibility lets you write workflows that are as simple or as precise as your task requires.

### Natural Language

Write steps as plain instructions. Cline interprets them and figures out which tools to use:

```markdown
## Step 1: Check for uncommitted changes
Look at the git status. If there are uncommitted changes, ask whether to continue or abort.

## Step 2: Run the test suite
Execute all tests. If any fail, show the failures and stop.
```

This approach works well when you want Cline to adapt to the situation rather than follow rigid steps.

### Cline Tools

For precise control, use Cline's built-in tools with XML syntax. This guarantees specific actions:

```xml
<execute_command>
  <command>npm run test</command>
  <requires_approval>false</requires_approval>
</execute_command>
```

```xml
<read_file>
  <path>src/config.json</path>
</read_file>
```

```xml
<ask_followup_question>
  <question>Deploy to production or staging?</question>
  <options>["Production", "Staging", "Cancel"]</options>
</ask_followup_question>
```

See the full list in the [Cline Tools Reference](/tools-reference/all-cline-tools).

### CLI Tools

Reference any command-line tool installed on your machine. Git, npm, docker, gh, make, curl: whatever you have available.

```bash
git log --author="$(git config user.name)" --since="yesterday" --oneline
```

### MCP Tools

If you have [MCP servers](/mcp/mcp-overview) connected, use them in your workflows with the `use_mcp_tool` syntax. This lets you integrate with external services like GitHub, Slack, databases, or custom internal tools.

```xml
<use_mcp_tool>
<server_name>github-server</server_name>
<tool_name>create_release</tool_name>
<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
</use_mcp_tool>
```

Or describe the intent in natural language and let Cline figure out the tool call:

```markdown
## Step 3: Create GitHub release
Use the GitHub MCP server to create a release tagged with the version from package.json.
Include the changelog as the release body.
```

## Writing Effective Workflows

**Start simple.** Write natural language steps first. Only add XML tool calls when you need guaranteed behavior.

**Be specific about decisions.** If a step requires user input, make that explicit: "Ask whether to deploy to production or staging."

**Include failure handling.** Tell Cline what to do when something goes wrong: "If tests fail, show the failures and stop the workflow."

**Keep workflows focused.** A `deploy.md` should deploy. A `setup-db.md` should set up the database. Split complex processes into multiple workflows that can be run independently.

**Version control your workflows.** Store workflows in `.clinerules/workflows/` and commit them. Your team can share, review, and improve them together.

<Warning>
Workflows execute with your permissions. Review workflows before running them, especially those from external sources.
</Warning>

## Example: Release Preparation

This workflow automates the tedious pre-release checklist. It verifies your working directory is clean, runs tests and builds, prompts you for the version bump, and generates a changelog from recent commits.

The workflow demonstrates both approaches: XML tool syntax (`<execute_command>`, `<ask_followup_question>`) for steps that need precise control, and natural language for steps where Cline should adapt to the situation.

````markdown title="release-prep.md"
# Release Preparation

Prepare a new release by running tests, building, and updating version info.

## Step 1: Check for clean working directory
<execute_command>
<command>git status --porcelain</command>
</execute_command>

If there are uncommitted changes, ask whether to continue or stash them first.

## Step 2: Run the test suite
<execute_command>
<command>npm run test</command>
</execute_command>

If any tests fail, stop the workflow and report the failures.

## Step 3: Build the project
<execute_command>
<command>npm run build</command>
</execute_command>

Verify the build completes without errors.

## Step 4: Ask for new version
<ask_followup_question>
<question>What should the new version be?</question>
<options>["Patch (x.x.X)", "Minor (x.X.0)", "Major (X.0.0)", "Custom"]</options>
</ask_followup_question>

## Step 5: Update version
Update the version in `package.json` to the new version specified by the user.

## Step 6: Generate changelog entry
<execute_command>
<command>git log --oneline $(git describe --tags --abbrev=0)..HEAD</command>
</execute_command>

Use these commits to write a changelog entry for the new version.
````

Invoke it with `/release-prep.md` and Cline walks through each step.