Workflows

Automate repetitive multi-step tasks with Markdown workflow files invoked by a single slash command.

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 — for example, /release.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. 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 numbered steps. The filename becomes the command: deploy.md is invoked with /deploy.md.

# Deploy workflow

Deploy the application to the staging environment.

## Step 1: Check for clean working directory
Verify there are no uncommitted changes. If there are, ask whether to continue or abort.

## Step 2: Run the test suite
```bash
npm run test
```
If any tests fail, stop the workflow and report the failures.

## Step 3: Build the project
```bash
npm run build
```
Verify the build completes without errors.

## Step 4: Deploy to staging
```bash
npm run deploy:staging
```
Report the deployment URL when complete.

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

1. 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.

2. Create a new workflow file

   Click New workflow file… and enter a filename (e.g., deploy). The file is created with a .md extension.

3. Write your workflow

   Add a title and numbered steps in Markdown format. Describe what each step should accomplish.

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.

Invoking workflows

Type / in the chat input to see available workflows. Cline shows autocomplete suggestions as you type — /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 controls which workflows appear in the / menu without deleting the file.

Where workflows live

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.

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.

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:

## 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 (XML)

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

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

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

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

MCP tools

If you have MCP servers connected, use them in your workflows with the use_mcp_tool syntax:

<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:

## 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 focused workflows.

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

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

Example workflow

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

The workflow demonstrates both approaches: XML tool syntax for steps that need precise control, and natural language for steps where Cline should adapt to the situation.

# 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 value 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.
Append it to CHANGELOG.md under a new version heading.

## Step 7: Commit and tag
<execute_command>
<command>git add CHANGELOG.md package.json package-lock.json</command>
</execute_command>

Commit with the message `v<version> Release Notes` and create a git tag.

Invoke it with /release-prep.md and Cline walks through each step, pausing for your approval.