Capstone: Build a Real Workflow

Putting It All Together

🔄 Over seven lessons, you’ve learned each Cursor feature individually: Tab completion (Lesson 3), inline editing (Lesson 3), Chat and context (Lesson 4), Agent mode (Lesson 5), rules and configuration (Lesson 6), and advanced features (Lesson 7). Now let’s combine them into a workflow you can use on any project.

The scenario: you’re adding a user notifications feature to an existing Node.js/TypeScript API. This is a realistic task that touches multiple files, requires understanding existing code, and benefits from every Cursor feature you’ve learned.

Step 1: Set Up Rules (5 minutes, one-time)

Before writing code, make sure your project has rules. If .cursor/rules/ doesn’t exist, create it:

general.mdc — Project conventions: TypeScript strict mode, named exports, error handling patterns, testing framework (Vitest), response shape.

api-patterns.mdc — API-specific rules: route structure, middleware order, validation patterns, error response format.

This takes five minutes and pays off for every future Cursor interaction in this project. From here on, every Agent task, Chat response, and Cmd+K edit follows your conventions automatically.

Step 2: Understand the Codebase (10 minutes)

Before writing anything, use Chat to understand what exists:

Open Chat (Cmd+L):

“@Codebase How is the API structured? What’s the routing pattern and where do database queries live?”

“@Codebase Is there an existing notification or messaging system? Show me anything related to user communications.”

“@api/routes/ What middleware is applied to authenticated routes?”

This surfaces the architecture you need to work within. You learn the patterns before writing code that violates them.

Step 3: Plan the Feature (5 minutes)

Open Composer (Cmd+I) in Plan mode:

“I need to add a user notifications feature. Requirements: (1) Database table for notifications with user_id, type, message, read status, created_at. (2) API endpoints: GET /api/notifications (list, filtered by read/unread), POST /api/notifications/mark-read. (3) Follow existing patterns in @api/routes/. Plan the implementation — don’t write code yet.”

Review the plan. Does it match the existing architecture? Are the file locations right? Does it use the right ORM and patterns? Adjust before any code is written.

Step 4: Build with Agent (20 minutes)

Approve the plan, then let Agent execute:

Watch as it creates the database migration, model, routes, controllers, and middleware. Each change creates a checkpoint. If something goes wrong, you can revert to any point.

Things to watch for during Agent execution:

• Does it follow your rules? (Right testing framework, right error handling)
• Does it match existing patterns? (Same route structure, same response shapes)
• Are the file locations correct? (In the right directories, following naming conventions)

If Agent goes off track, stop it, revert to the last good checkpoint, and give more specific instructions.

✅ Quick Check: Agent created the notifications table but used VARCHAR(255) for the message column. Your existing tables use TEXT for variable-length content. What’s the fastest way to fix this? Use Cmd+K. Highlight the migration line, type “Change message column to TEXT to match our existing table conventions.” Surgical edit, instant fix. No need to launch Agent again for a one-line change.

Step 5: Refine with Cmd+K (10 minutes)

Agent gets the structure right. The details need polish.

Highlight the notification model, Cmd+K: “Add an index on user_id and created_at for query performance”

Highlight the route handler, Cmd+K: “Add pagination — accept page and limit query params, default to page 1, limit 20”

Highlight the validation logic, Cmd+K: “Add rate limiting — max 100 mark-read requests per minute per user”

Cmd+K is perfect for these surgical improvements. Each edit is small, focused, and reviewable.

Step 6: Test with Agent (10 minutes)

Back in Composer:

“Write tests for the notifications API. Cover: (1) listing notifications for authenticated user, (2) marking notifications as read, (3) pagination, (4) rate limiting. Follow the testing patterns in @tests/.”

Let Agent write the tests, run them, and fix failures. This is where Agent shines — the write-run-fix loop is exactly what autonomous execution was built for.

Step 7: Polish with Tab (ongoing)

As you review and tweak the code, Tab predicts your edits. Renaming a variable? Tab predicts the next rename. Adding a type annotation? Tab suggests the rest. This is the background acceleration that makes everything faster.

The Feature Matrix

Here’s when to reach for each tool:

Self-Assessment

Rate your confidence with each Cursor feature:

Score 15+: You’re ready to use Cursor effectively on real projects.

Score 10-14: Revisit the lessons where you scored 1. Practice with a small project.

Under 10: Try each feature individually on a test project before combining them.

Common Workflow Mistakes

Mistake 1: Using Agent for everything. Agent is powerful but slow. Tab and Cmd+K are faster for small edits. Match the tool to the task size.

Mistake 2: Long conversations. Start fresh (Cmd+N) after completing each feature or bug fix. Stale context makes everything worse.

Mistake 3: No rules file. Every time you repeat a convention in chat, that’s a rule you should write once and forget about.

Mistake 4: Ignoring checkpoints. When Agent goes wrong, people try to fix it with more instructions. Often, reverting to a checkpoint and trying a different approach is faster.

Mistake 5: Not reviewing Agent output. AI-generated code can look right while being subtly wrong. Read the diffs. Run the tests. The faster Agent works, the more important your review becomes.

Key Takeaways

• The full Cursor workflow: Rules → Plan → Agent → Cmd+K → Tab → Test
• Match the tool to the task: Tab for flow, Cmd+K for surgical edits, Chat for understanding, Agent for autonomous work
• Set up rules once, benefit forever — commit them to your repo for team-wide consistency
• Start conversations fresh, keep them focused, and review every AI-generated change
• Cursor is a coding partner, not a replacement — your judgment on architecture, edge cases, and code quality is what makes the output production-ready

Continue Learning

• Cursor docs (docs.cursor.com) — the official reference for every feature
• cursor.directory — community-curated rules files for popular frameworks
• Experiment with MCP — connect Cursor to your database, project management, or design tools
• Join the Cursor community (forum.cursor.com) — tips, rules files, and workflow ideas from other developers