How I stopped repeating myself to Cline
If you're typing the same instructions to your agent every week, you're the process. Write them once as a markdown workflow, invoke with a slash command, and watch the agent execute with verification.
Write the instructions once as a markdown workflow and invoke it with a slash command. The agent reads it, adds the steps to its focus chain, and executes with verification.
These aren't docs. They're procedures. Each file defines a task family, the exact steps to add to the focus chain, and how to verify the work. Instead of explaining your PR review process again, type /pr-review.md. Instead of walking through dashboard creation, type /weekly-dashboard.md. The workflow materializes as a todo list in Cline's focus chain, then executes step by step.
Docs on building & using workflows in Cline
I use workflows as automations
Yesterday I was building a Streamlit dashboard showing our weekly growth metrics. Screenshots, data exports, CSVs; I guided Cline through building visualizations, calculating growth rates, formatting charts. By the end (30 mins later), I had a beautiful dashboard.
Then I realized I'd be doing this exact same thing next week. And the week after.
So I had Cline build a workflow for it. The conversation where I'd accumulated all the context about how to build the dashboard became the source material. Cline analyzed what we'd done together and generated a workflow that captures the entire process.
Now when I need the weekly dashboard, I type /weekly-dashboard.md. Cline asks for the data inputs, calculates week-over-week comparisons, generates all the visualizations, and outputs a complete dashboard ready to run. What took 30 minutes of back-and-forth now happens in one command.
Example: PR Review automation
Internally, our team uses the /pr-review.md workflow. Instead of manually checking diffs, examining files, analyzing changes, and crafting review comments every time, we defined the process once:
1. Gather PR information using gh CLI
2. Examine modified files for context
3. Analyze for bugs, performance, security
4. Ask for user confirmation with assessment
5. Execute the review with appropriate gh command
Type /pr-review.md, provide the PR number, and Cline handles everything. It pulls the diff, examines surrounding code for context, analyzes the changes, presents its assessment for your approval, then executes the GitHub CLI commands. A 15-minute manual process becomes a single command.
Other workflows emerge naturally. Setting up new projects with your exact structure and dependencies. Running your specific test suites with custom validation. Generating release notes from merged PRs. Deploying to staging with your particular health checks and notifications.
Building your own workflows
Creating a workflow is simpler than you might think. There's actually a workflow for building workflows. Type /create-new-workflow.md and Cline guides you through it:
- It asks for the purpose and a concise name
- You describe the objective and expected outputs
- You list the major steps (Cline can help determine details)
- It generates the properly structured workflow file
The best workflows come from tasks you've already done. After completing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." It analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
Workflows live in .clinerules/workflows/ for project-specific ones or ~/Documents/Cline/Workflows/ for global ones you use across projects. Project workflows take precedence when names match.
Lessons from a YC founder shipping at the scale of an engineering org
I was talking to a founder from the recent YC batch who's achieved something remarkable. He maintains over 20 task-family workflows: integrations-slack.md, integrations-gmail.md, bug-class-auth.md, migration-postgres.md. Each contains domain-specific validation, performance checks, and acceptance criteria.
His results: significant time savings, near-zero rework from missed requirements, and the ability to parallelize work across multiple agent instances. He's moved beyond babysitting to orchestration.
He even uses micro MCPs for constrained operations; read-only database access, sandboxed workflow execution, domain-specific validations. But it all starts with those markdown instruction files that tell agents exactly what to add to their to-do lists.
Start with one workflow
Pick your most annoying repeated task. Turn it into a workflow this week. Include verification steps, handle failures gracefully, and watch your agent transform from an assistant into an executor.
The prompts repository has workflow examples. But your best workflow solves your specific problem.
-Nick
