Cursor Rules Unlocked My Fastest Shipping Ever – Here's How

Tired of AI giving you code that looks nice but breaks in production?

Me too.

After 13 years of coding – messy freelance disasters, late-night fixes, family asking "when will you ship something real?" – I finally made Cursor follow my rules like a good teammate.

The fix? Four .mdc files inside .cursor/rules/.

These cut my refactoring time by 70%. No more fighting AI on logic, style, design, or tests.

Cursor’s official docs say: rules must be focused, actionable, and scoped. Keep under 500 lines, split big ones, use examples, reference files (don’t copy-paste everything).

I followed that exactly.

Here are my four core files with full templates I actually use.

Copy-paste them and tweak for your project.

Quick Setup Reminder

Put these files in .cursor/rules/ folder.

Use .mdc format with YAML frontmatter: description, globs (file patterns), alwaysApply.

This makes Cursor smart – applies rules only when needed.

1. business-rules.mdc – Protect Your Money Logic

This file stops AI from ignoring real business rules.

No negative balances. Proper GST for India. Events over raw CRUD.

Full file example:

markdown

---
description: Enforce core business logic and invariants for the app. Focus on domain events, validations, and flows.
globs:
  - "src/services/**/*.ts"
  - "src/backend/**/*.js"
alwaysApply: false
---

# Business Rules for VibeShip App

## Core Invariants (Things That Must Always Be True)
- User balances cannot go negative: Validate before any deduction (e.g., for premium features).
- Subscriptions auto-renew only if payment succeeds: Check gateway response before updating status.
- For Indian users, apply 18% GST on all transactions above ₹500—reference tax laws in @docs/gst-guidelines.md.

## Domain Events and Flows
- Always prioritize events over raw CRUD: E.g., use 'userSubscribed' event to trigger emails and updates.
- Payment flow: 1. Validate input (amount > 0, valid UPI ID). 2. Call gateway. 3. Log success/fail as event.
- Avoid hardcoding values: Use config for limits (e.g., max free prompts per day = 10).

## Edge Cases to Handle
- Refunds: Reverse balance and notify via email—never delete records, just mark as refunded.
- Multi-currency: Convert to INR for Indian reports; use exchange rates from @utils/currency-converter.ts.

Example: See how this is implemented in @services/payments.ts for a full flow.

Real result: In my SaaS, Cursor now auto-adds balance checks and GST logic. No more refund bugs that could have cost real money.

2. coding-rules.mdc – Clean Code on Autopilot

This keeps code readable and scalable.

No deep nesting. UUIDs. Proper errors.

Full file example:

---
description: Standards for code structure, naming, and best practices to avoid tech debt.
globs:
  - "src/**/*.ts"
  - "src/**/*.js"
alwaysApply: false
---

# Coding Rules: Keep It Clean and Scalable

## Naming Conventions
- Variables: camelCase for locals (e.g., userBalance).
- Constants: UPPER_SNAKE_CASE (e.g., MAX_PROMPTS = 10).
- Functions: descriptive verbs (e.g., calculateGstAmount()).
- Files: kebab-case for utils (e.g., currency-converter.ts).

## Structure and Flow
1. Early returns: Exit functions early on errors instead of deep if-else nesting.
2. Keep functions short: Under 50 lines—split if longer.
3. Error handling: Always use try/catch for async ops; log with structured messages (e.g., {error: 'Payment failed', userId: 123}).

## Data Handling
- IDs: Use UUIDs over auto-increment for scalability (import uuid from 'uuid').
- Async: Prefer async/await over promises; handle rejections properly.
- No globals: Pass dependencies as params.

## Performance Tips
- Avoid heavy loops in hot paths: Optimize for Indian mobile users with slow networks.
- Memoize expensive functions (use lodash.memoize).

See example in @utils/error-handler.ts for full try/catch pattern.

Big win: AI now spits out clean code from the first prompt. No weekend cleanup sessions anymore.

3. design-rules.mdc – Mobile-First UIs That Don’t Suck

India = mostly mobile users on budget phones.

This forces responsive, accessible design.

Full file example:

---
description: UI design patterns for accessible, mobile-first interfaces.
globs:
  - "src/frontend/**/*.tsx"
  - "src/components/**/*.js"
alwaysApply: false
---

# Design Rules: Build UIs That Wow

## Core Principles
- Mobile-first: Design for screens < 768px first, then scale up.
- Accessibility: Always add aria-labels for interactive elements; test with screen readers.
- Consistency: Use shadcn/ui or Tailwind classes only—no custom CSS unless needed.

## Component Guidelines
1. Buttons: Use <Button variant="primary"> for CTAs; add loading states.
2. Forms: Validate on blur; show errors inline (red text below fields).
3. Layouts: Flexbox/Grid over floats; responsive breakpoints at 640px, 1024px.

## Theming
- Colors: Primary #007BFF (blue for actions); use dark mode toggle.
- Fonts: Sans-serif (e.g., Inter) for readability on low-res screens.

Example Before/After:
Before: <div class="button">Submit</div> (no accessibility).
After: <Button aria-label="Submit form" disabled={loading}>Submit</Button>

Reference @components/login-form.tsx for a full example.

Result: One prompt = beautiful, mobile-ready UI. No more "looks good on my laptop but trash on phone" moments.

4. testing-rules.mdc – Tests That Actually Save You

This makes AI write tests first – TDD style.

Catches bugs before you push.

---
description: UI design patterns for accessible, mobile-first interfaces.
globs:
- "src/frontend/**/*.tsx"
- "src/components/**/*.js"
alwaysApply: false
---
# Design Rules: Build UIs That Wow
## Core Principles
- Mobile-first: Design for screens < 768px first, then scale up.
- Accessibility: Always add aria-labels for interactive elements; test with screen readers.
- Consistency: Use shadcn/ui or Tailwind classes only—no custom CSS unless needed.
## Component Guidelines
1. Buttons: Use <Button variant="primary"> for CTAs; add loading states.
2. Forms: Validate on blur; show errors inline (red text below fields).
3. Layouts: Flexbox/Grid over floats; responsive breakpoints at 640px, 1024px.
## Theming
(blue for actions); use dark mode toggle.- Colors: Primary#007BFF
- Fonts: Sans-serif (e.g., Inter) for readability on low-res screens.
Example Before/After:
Before: <div class="button">Submit</div> (no accessibility).
After: <Button aria-label="Submit form" disabled={loading}>Submit</Button>
.tsx for a full example.Reference@components/login-form

---
description: Standards for writing robust tests with high coverage.
globs:
  - "tests/**/*.ts"
  - "src/**/*.test.ts"
alwaysApply: true  # Always think tests!
---

# Testing Rules: Catch Bugs Early

## Test Structure
- Use TDD: Write tests first, then code.
- Tools: Vitest or Jest for units; React Testing Library for components.
- Coverage: Aim for 80%+ on critical paths (use --coverage flag).

## Writing Tests
1. Happy path: Test success scenarios (e.g., valid login).
2. Edges: Invalid inputs, errors (e.g., network fail).
3. Mocks: Mock externals like APIs (use vi.mock from Vitest).

## Examples
- Unit: test('adds GST', () => { expect(calculateGst(1000)).toBe(1180); });
- Integration: Mock payment gateway and assert event fired.

Never push without running tests—reference @utils/test-mocks.ts for common setups.

Saved my ass: Caught a refund edge case before launch. Now I deploy with confidence.

These four files = my vibe-coding superpower.

From chaotic code to clean, safe, shippable apps in one go.

Start today. Create one .mdc file using Cursor’s "New Rule" button.

Copy any of these templates above and tweak.

In Pune right now (4:46 PM IST), I’m probably testing one more prompt.

You?

What’s your biggest AI headache right now? Reply below – I’ll help vibe a fix.

Stop coding alone. Start shipping smarter. 🚀