Most developers using Cursor in 2026 plateau at the same point: the autocomplete is great, the chat is fine, but everything past that feels like a slot machine. You type a prompt, you get something back, you spend ten minutes correcting it, you repeat. The fix isn’t a better prompt—it’s a custom workflow. Cursor’s actual power lives in three systems most users never touch: project rules under .cursor/rules/, the four-way mode system (Ask / Plan / Agent / Debug), and the plan-then-implement loop.

This is a working developer’s setup guide for building your first one. Concrete, opinionated, no fluff about “AI changing how we code.” If you have Cursor Pro at $20/month and a real codebase, you have everything you need to follow along.

What “Custom Workflow” Actually Means in 2026

The phrase has been diluted by influencer content into meaning “any non-default usage of Cursor.” Strip that out. A custom workflow has three concrete layers:

1. Project rules — version-controlled .mdc files in .cursor/rules/ that tell the agent how this codebase wants to be written. Replaces the legacy .cursorrules single-file approach. (Cursor official docs)
2. Mode selection — knowing when to use Ask, Plan, Agent, or Debug for the task in front of you, instead of typing into Agent for everything. Plan Mode in particular is the most under-used feature in Cursor as of May 2026.
3. A repeatable loop — Plan in Ask/Plan Mode → review → implement in Agent → manual edits for the surgical bits. Tossing this in for “vibe coding” is what produces the ten-minute corrections.

That’s it. No subagents, no MCP servers, no Skills (the nightly-channel feature added in 2026). Master the three above first; the rest is incremental.

Step 1: Scaffold .cursor/rules/ Properly

Open your project repo and create:

mkdir -p .cursor/rules
touch .cursor/rules/architecture.mdc

Why a directory and not a single file? The legacy .cursorrules is still read by Cursor, but every line of it loads into every single chat request, eating your context window. The new system lets you scope rules to specific files via glob patterns, so the agent only loads what’s actually relevant to the file it’s editing.

Commit .cursor/rules/ to git. These rules are part of your codebase the same way .eslintrc or tsconfig.json are—they encode team conventions and should travel with the repo.

The four rule activation modes

Each .mdc file is one of four types, controlled by frontmatter:

Activation	Frontmatter	When it loads
Always Apply	alwaysApply: true	Every chat session, every file
Apply to Specific Files	globs: ["src/**/*.tsx"]	When the matched file is in context
Apply Intelligently	description: "..." (with alwaysApply: false, no globs)	When the agent decides the description fits the task
Apply Manually	None of the above	Only when you type @rule-name in chat

The most common mistake is making everything Always Apply. Cursor’s docs explicitly call this out and recommend keeping the always-on rules small and splitting larger guidance across scoped or intelligent rules. Cursor recommends keeping rules under 500 lines and splitting larger ones into composable pieces.

Step 2: Write Your First Scoped Rule

Pick the directory in your repo with the most conventions—usually src/components/ for a React app or app/api/ for a Next.js API layer. Create one rule scoped to it.

Example .cursor/rules/react-components.mdc:

---
description: React component conventions for this codebase
globs: ["src/components/**/*.tsx", "src/components/**/*.ts"]
alwaysApply: false
---

# React component rules

- Use named exports, never default exports
- Co-locate styles in a `Component.module.css` file next to the component
- Keep components under 200 lines; if larger, extract subcomponents
- Use `useId()` for any element needing a stable ID across SSR/CSR
- Server components are the default; mark client components with `'use client'` at the top
- Test files live next to components: `Component.tsx` + `Component.test.tsx`
- Use TanStack Query for server state; never `useEffect` for data fetching

The agent will load this rule only when you’re editing a file matching the glob. That keeps your context budget free for the actual code, which matters because every token in a rule is a token not available for the file or your prompt.

What goes in an Always-Apply rule

Reserve alwaysApply: true for things that genuinely affect every interaction:

---
description: Project-wide conventions
alwaysApply: true
---

- This is a TypeScript monorepo using pnpm + Turborepo
- We use Zod for runtime validation, Zustand for client state
- All public APIs have a corresponding integration test in `__tests__/`
- Never add a new dependency without checking it against our existing stack

Keep this under 30 lines if you can. Anything longer should be extracted into a scoped rule or an Apply-Intelligently rule.

Step 3: Use Plan Mode Before Touching Agent Mode

Cursor 2026 has four modes accessible via Shift+Tab from the chat input or the mode picker:

Mode	What it does	When to use
Ask	Open-form chat, no code changes	Exploration, asking how a library works
Plan	Asks clarifying questions, researches codebase, produces a written plan	Multi-file features, ambiguous specs, anything you’ll regret rushing
Agent	Makes changes across files, runs commands	Implementation of a clear plan
Debug	Active debugging of code/systems	When something broken needs investigation

Plan Mode is the underused star of this list. The way it works: you describe the goal, Plan Mode asks clarifying questions, then it produces an editable implementation plan you review before any code is written. Cursor’s docs are explicit that “for quick changes or tasks you’ve done many times before, jumping straight to Agent mode is fine”—but for everything else, planning first measurably improves output.

A practical loop:

1. Open Plan Mode (Shift+Tab from chat input)
2. State the goal: “Refactor the auth flow to use server actions instead of API routes, keeping the JWT format unchanged”
3. Answer Plan Mode’s clarifying questions
4. Review the generated plan; edit anything wrong
5. Click “Build” to hand the plan off to Agent Mode for implementation

The plan persists. You can move it from the home directory to your workspace for team review or future reference.

Why this beats typing into Agent directly

The University of Chicago research that Cursor’s blog cites about agent best practices found that experienced developers plan before generating code more often than newer ones do—not because planning is intrinsically virtuous, but because it forces the developer to know what they want before the agent starts making files appear. Agent Mode without a plan tends to produce technically-correct code that solves the wrong problem.

Step 4: Build a Repeatable Trigger Pattern

Once you have rules in .cursor/rules/ and you’re using Plan Mode reflexively, the next step is making certain workflows feel automatic. Two patterns work well:

The “new feature” trigger

When you start a new feature, follow this sequence every time:

1. Branch from main: git checkout -b feature/<name>
2. Open Plan Mode, describe the feature
3. Save the plan to the workspace as plans/feature-<name>.md
4. Hand off to Agent Mode for implementation
5. Manual edits for anything Agent got 80% right but not 100%
6. Run tests, commit, push

The third step—saving the plan—is the part most people skip. It becomes a artifact that’s reviewable, shareable, and reusable when the next person on your team hits a similar task.

The “bug fix” trigger

Different workflow for debugging:

1. Switch to Debug Mode
2. Paste the failing test output or error message
3. Let Debug Mode investigate the codebase
4. Once root cause is identified, switch to Agent for the fix

Debug Mode is optimized for investigation; Agent is optimized for changes. Using them in the wrong order—Agent first, then trying to debug what it produced—is how you end up rewriting code that didn’t need rewriting.

Step 5: When (and When Not) to Build a Custom Mode

Cursor 2026 supports creating custom modes beyond the four built-in ones. The temptation, especially for power users, is to build a custom mode for every recurring task: a “Test Writer” mode, a “Refactor” mode, a “Code Review” mode.

Resist this until you’ve done the task manually at least 10 times. Custom modes are configuration overhead. If you build one for a workflow you only use occasionally, you’ll forget what it does, modify it ad-hoc, and end up with a graveyard of half-broken modes that adds friction instead of removing it.

Good candidates for a custom mode:

• Tasks you do weekly or more often with the same structure
• Tasks where the same set of files, rules, and tone is always needed
• Tasks that have a clear “done” state you can describe

Bad candidates:

• One-off project setup
• Anything you’ve done less than 10 times
• “Generic helper” modes—the built-in Agent already covers these

If your team is on Cursor Teams at $40/user/month, custom modes can be shared across the team, which raises the value of building one. On a solo Pro plan, the bar is higher.

Common Mistakes to Avoid

After watching dozens of teams set up Cursor workflows, the same patterns show up:

1. Putting everything in always-apply rules. Symptom: chat feels slow, agent ignores half your prompt. Fix: split into scoped rules with globs.

2. Writing rules as documentation, not instructions. Bad: “This project uses React with TypeScript and Vite for fast hot reloading.” Good: “Use named exports. Co-locate tests. No default exports.” Rules should read like a code review checklist, not a README.

3. Skipping Plan Mode for “small” changes that aren’t small. Symptom: 30-minute Agent sessions that produce 200 lines of unwanted refactoring. Fix: any change touching >2 files goes through Plan Mode.

4. Never editing the generated plan. Plan Mode’s output is a starting point, not a contract. Read it. Strike out the steps that are wrong. Add the constraints it missed. The 60 seconds you spend editing the plan saves 20 minutes of correcting Agent output.

5. Not version-controlling .cursor/rules/. This directory is part of your codebase. Commit it. Code-review changes to it the same way you’d review changes to your linting config. Rules drift is real, and it’s invisible until your code starts not matching your team’s conventions.

6. Treating rules as a substitute for docs. Rules tell the agent how to write code. They don’t tell humans how the system works. Both are needed; one doesn’t replace the other.

Honest Take

If you’re new to Cursor and trying to figure out where to invest the first hour of customization, the answer in May 2026 is: set up .cursor/rules/ properly and learn Plan Mode. Everything else—custom modes, MCP servers, Skills, subagents—is incremental on top of those two foundations.

Cursor Pro at $20/month gives you access to all of this. The Pro+ tier at $60 and Ultra at $200 buy you more usage on frontier models, not more workflow capability—every customization above works the same on Hobby (free, limited) as on Ultra. If you find yourself rate-limited on the free tier while learning these patterns, upgrade to Pro for $20. If you’re hitting Pro limits regularly because you’re using Cursor heavily as a daily driver, Pro+ at $60 is the next step.

For the per-language settings details that go alongside this workflow setup, see our Best Cursor Settings for Python Developers and Best Cursor Settings for TypeScript and React guides. For the broader question of whether Cursor is still the right tool at all, our Cursor IDE Review 2026 walks through what it does and doesn’t justify at $20/month. If you’re considering running a local LLM alongside Cursor for cost or privacy reasons, the Cursor + Local Llama Hardware Tiers guide covers what hardware actually delivers usable latency.

Once your rules are dialed in, automating the review loop is the next leverage point — AI code review with ReviewDog and local LLMs shows how to wire a local model into your pre-commit hooks for zero-cost automated review.

The version of “custom workflow” that sells courses and YouTube tutorials is overengineered. The version that actually saves time fits in 90 minutes of setup: scoped rules per directory, an always-apply rule for project conventions, and Plan Mode as your default entry point for anything multi-file. Build that first, then evaluate what else is worth the configuration cost.

Sources

• Cursor Rules — Cursor Docs (official)
• Plan Mode — Cursor Docs (official)
• Cursor Pricing — official pricing page (verified May 11, 2026)
• Best practices for coding with agents — Cursor blog
• Cursor Rules: Complete .mdc Guide & 15 Templates — Vibe Coding Academy
• Cursor IDE Complete Guide 2026 — Codersera
• A Year with Cursor: Workflow Evolution from Agent to Architect — Subramanya N
• awesome-cursorrules — community rule templates (GitHub)

Last updated May 11, 2026. Cursor’s features and pricing change frequently—verify current state on the official pricing and docs pages before relying on specifics.