Stop adding rules when workflows are the answer
Developers frequently embed project constraints into always-on rule files, but many recurring tasks are better expressed as on-demand automation. Workflows in Cline provide that option: they execute a defined sequence when invoked, inject instructions only into the active message, and disappear after completion. This architectural distinction changes both cost and ergonomics for automation.
What a workflow actually is
Workflows are procedural automations — “first do X, then Y, then Z” — packaged as markdown files that run once when invoked. When triggered (for example, with a command like /pr-review.md), Cline wraps the workflow content in <explicit_instructions> tags and injects it into that specific message. The workflow runs its sequence, produces the outcome, and is not kept in the persistent system context.
This contrasts with clinerules, which append to the system prompt and affect every interaction. The key technical trade-off is token consumption: workflows consume tokens only when invoked; clinerules consume tokens on every message because they remain part of the persistent system context.
A simple decision framework
If a process can be described as a clear sequence of steps, implement it as a workflow. If a directive should influence every interaction — coding standards, architectural constraints, and project-wide preferences — express it as a clinerule. The PR review workflow is a canonical example of a workflow pattern:
- gather PR info via
gh pr viewandgh pr diff - inspect files with
read_fileandsearch_files - analyze changes for quality and bugs
- ask for confirmation with
ask_followup_question - execute
gh pr reviewto approve or reject
That sequence spans multiple tools and decision points, so encoding it as a one-shot automation preserves human oversight while eliminating repetitive manual steps.
Real-world workflow patterns
Examples showcased include:
- PR review: combines GitHub CLI commands, file inspection, analysis, and confirmation.
- Deployment: runs
npm test,npm run build,docker deploy, health checks (curl /health), and team notifications via an MCP server before promoting to production. - Self-improving meta-workflow: reflects on completed tasks and proposes updates to clinerules based on feedback; naturally on-demand rather than continuous.
Content generation, database migrations, and release orchestration also map well to workflows since they involve multiple tools, checks, and notifications.
Creating, managing, and invoking workflows
Workflows are accessible in the Workflows tab of Cline’s interface. Both Global Workflows (stored in ~/Documents/Cline/Workflows) and Workspace Workflows (stored in .clinerules/workflows/) are supported. Each workflow can be enabled, disabled, edited, or deleted. When a local workflow and a global workflow share a name, the workspace (local) workflow takes precedence, enabling project-specific overrides.
New workflows can be created in the UI via “New workflow file...” or by adding files directly to .clinerules/workflows/. Invocation is simple: type the filename as a slash command (for example, /create-new-workflow.md) in the chat.
First steps and resources
Cline can generate a workflow from a recently completed conversation by analyzing the steps and producing a structured workflow file. A dedicated workflow for workflow creation is available at the repository linked below, which guides the process: purpose, objective, major steps, and substeps.
Examples and templates live in the prompts repository on GitHub, including the self-improving Cline workflow and the create-new-workflow workflow.
Teams seeking consistency can encode standard procedures as executable workflows instead of scattered documentation, reducing manual repetition while keeping humans in the loop for critical approvals. Community discussion and shared workflows are available on Reddit and Discord.
Original source: https://cline.bot/blog/stop-adding-rules-when-you-need-workflows
