Cline Workflows: Automate Multi-Step Processes, Not Rules

TL;DR

• Cline workflows automate multi-step processes with a single slash command (e.g., /pr-review.md)
• Workflows execute once and disappear; clinerules persist in every message and cost tokens continuously
• Use workflows for procedural automation ("do X, then Y, then Z"), clinerules for behavioral consistency ("always do this")

What Dropped

Cline is pushing developers to stop cluttering their context with rules when they should be building workflows. The distinction is architectural: workflows are on-demand automation for multi-step processes, while clinerules are persistent behavioral guidelines. A PR review workflow now handles gathering context, analyzing changes, asking for confirmation, and executing approval in a single command—work that previously took 15 minutes manually.

The Dev Angle

Workflows wrap their content in <explicit_instructions> tags and inject only when invoked. They consume tokens only during execution. Clinerules, by contrast, append to your system prompt and burn tokens on every single message because they're persistent context.

The decision framework is straightforward: build a workflow when you can describe something as a sequence ("first I do X, then Y, then Z"). The PR review workflow exemplifies this—it gathers PR info via GitHub CLI, examines files with read_file, analyzes changes, asks for confirmation, and executes approval. That's a complete process with a specific outcome.

Use clinerules when you want consistent behavior across all tasks. Coding standards, architectural constraints, and project-specific context belong in clinerules because they should influence every interaction. The rule "always use TypeScript strict mode" should affect all code generation, not just when you invoke it.

Workflows can orchestrate multiple tools—CLI commands, file operations, MCP servers, user interaction—into a single command. A deployment workflow might run tests, build the app, deploy to staging, run health checks, notify Slack, and ask for production approval. A content generation workflow could gather research, structure arguments, write drafts, and format for publication. Database migration workflows can run migrations, check for conflicts, update documentation, and notify teams.

Access workflows through the Workflows tab in Cline's interface. Global workflows live in ~/Documents/Cline/Workflows and work across all projects. Workspace workflows live in .clinerules/workflows/ and are project-specific. Create new workflows by clicking "New workflow file..." or ask Cline directly: "create a workflow for the process I just completed." There's even a meta-workflow for creating workflows that walks you through defining purpose, objective, and detailed steps.

Should You Care?

If you're repeating multi-step processes manually or adding rules to handle one-off sequences, this is a direct cost savings. Every rule you add to clinerules consumes tokens on every message. A PR review workflow that runs once per PR costs nothing when idle. If you're doing the same deployment, testing, or content generation process weekly, a workflow turns 20 minutes of manual work into a one-shot command.

If you're already using clinerules effectively for behavioral consistency (coding standards, architectural patterns, team conventions), nothing changes—keep doing that. Workflows complement clinerules; they don't replace them. The real win is recognizing which tool solves which problem.

Start with your most tedious recurring task. Turn that repetitive sequence into a single command. The prompts repository has examples you can adapt—PR review, self-improving workflows, and more. Test on small examples first, then iterate. Workflows improve through use.

Source: Cline