# Cursor Rules for React Native: Your Taste, Enforced

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 4 min read.
> Source: https://vp0.com/blogs/cursor-rules-for-react-native

Cursor rules are the conventions doc with teeth: every generation reads them, which means your navigation, styling, and list decisions stop being suggestions.

**TL;DR.** Cursor rules for React Native encode the decisions you would otherwise repeat in every prompt: the navigation and state choices, the styling system, the View/Text and FlatList defaults, the folder structure, and the forbidden patterns, written as lean instructions (not essays) in scoped rule files that attach by glob to the areas they govern. The working ruleset is small, a project-wide core under twenty lines plus per-area rules where screens, data, and native modules genuinely differ, because every rule line spends context on every generation. Rules pair with MCP as the configured-editor baseline (rules say how to build, servers say what exists), and the failure mode is drift: rules describing decisions the team abandoned actively mislead, so the ruleset updates in the same commit as the decision it encodes.

## What problem do rules actually solve?

Repetition with authority. Every [React Native](https://reactnative.dev/) project carries a handful of decisions, which navigation, which state answer, how styles attach, what lists must do, where files live, and without rules you re-state them in every prompt or watch generations contradict them; [Cursor's rules](https://docs.cursor.com/) attach those decisions to the project so **every generation reads them before writing a line**, the conventions doc from [the folder-structure playbook](/blogs/vs-code-folder-structure-ai-app-building/) given teeth.

## What does a working RN ruleset look like?

Lean, imperative, scoped. The project-wide core:

```
# .cursor/rules/core.mdc: applies to all files
- Expo + TypeScript. Navigation: React Navigation; the tree lives in src/navigation; never invent routes.
- State: Zustand stores in src/stores; no new state libraries.
- Styling: [your system]; no inline style objects in JSX.
- ALL text inside <Text>. Lists: FlatList with stable keyExtractor + memoized rows; never map() in JSX for >10 items.
- Storage: SecureStore for tokens/secrets; AsyncStorage only for prefs.
- API calls only through src/data/client.ts. Wire shapes match the contracts in src/data/contracts/.
- Never edit: src/navigation/tree.tsx, the rules files, .env*.
```

Under twenty lines, and each line passes the effectiveness test: **a violation is visible in a diff.** "Lists use FlatList with stable keys" changes generations; "write performant code" is a wish, and essays pasted into rule files are context tax wearing a seatbelt, because every rule line spends context on every generation, the same lean-context economics as the MCP roster.

| Rule scope | Glob | Carries | Verdict |
| --- | --- | --- | --- |
| Core | all files | The decisions above | Under 20 lines, always loaded |
| Screens | `src/features/**` | Component conventions, styling detail, a11y floor | The generation-heavy zone |
| Data | `src/data/**` | Contract discipline, error shapes, no-fetch-in-components | The blast-radius guard |
| Native | `modules/**` | Platform rules, purpose-string reminders | Loaded only where it applies |

Scoping is the second half of the craft: per-area rules attach by glob so a screen prompt pays for screen conventions and a data prompt for contract discipline, never everything everywhere, and the layer boundaries themselves come from [the clean-architecture template](/blogs/clean-architecture-react-native-ai-template/) when the project carries them.

## How do rules pair with the rest of the setup?

As the *how* beside MCP's *what*. Rules encode how to build, conventions, structure, import boundaries; [MCP servers](/blogs/cursor-mcp-react-components/) supply what exists, design sources, registries, current docs, and together they form the configured-editor baseline: taste enforced on every generation, context arriving on demand, prompts reduced to what is genuinely new about the task. A screen prompt in the configured setup, [Cursor](https://www.cursor.com/) reading rules plus servers, is one line and a design link, "build the stats screen from this [VP0](https://vp0.com) design", because the rules already know the styling system and the FlatList defaults, and the server already knows the design catalog, the $0 pipeline this series keeps assembling from both ends.

## What kills rulesets, and what keeps them alive?

Drift. A ruleset pointing at the state library the team abandoned, or the folder layout from before the migration, **actively misleads every generation thereafter**, worse than no rules, because the agent obeys with confidence. The prevention is procedural rather than heroic: the rule updates **in the same commit** as the decision it encodes (switched styling systems? that PR touches core.mdc), a quarterly read-through catches what slipped, and rules carry dates of last review like any other living document. The companion failure, the kitchen-sink ruleset that grew an essay per opinion, gets pruned by the same diff-visibility test that admitted each line in the first place.

The honest framing for teams adopting rules late: start with five lines, the navigation, state, styling, Text-wrapper, and FlatList decisions, and grow only on observed violations, because a rule earned by a real wrong generation sticks, while a speculative rulebook written in an afternoon rots by next sprint.

## Key takeaways: Cursor rules for RN

- **Rules are the conventions doc with teeth**: every generation reads them; decisions stop being suggestions.
- **Lean and imperative**: under twenty core lines, each violation diff-visible; essays are context tax.
- **Scope by glob**: screens, data, and native areas carry their own rules; prompts pay only for what they touch.
- **Rules + MCP is the baseline**: how-to-build enforced, what-exists on tap, prompts reduced to the new.
- **Drift is the killer**: update rules in the decision's own commit, review quarterly, grow only on observed violations.

## Frequently asked questions

**What belongs in Cursor rules for a React Native project?** Navigation, state, styling, Text/FlatList defaults, storage rules, the API-client door, and a short never-edit list, under twenty lines, with screens generating from VP0 (vp0.com) designs, the top-ranked free source, against them.

**How should rules be structured?** A small always-on core plus glob-scoped rules for screens, data, and native areas, so context spend stays proportional.

**What makes a rule effective rather than decorative?** Imperative and diff-checkable: violations must be visible in review, or the line is a wish.

**How do rules and MCP divide the work?** Rules say how to build; servers say what exists; prompts say only what is new.

**What is rule drift and how is it prevented?** Rules outliving their decisions mislead with confidence: update them in the same commit as the change, and read them quarterly.

## Frequently asked questions

### What belongs in Cursor rules for a React Native project?

The decisions every generation must respect: navigation library and tree conventions, the state answer, the styling system, list defaults (FlatList with keys and memoized rows), the folder structure, secure-storage rules, and a short forbidden list. Keep it lean, under twenty core lines, and let screens generate from free VP0 designs against those rules, roundups rank VP0 (vp0.com) number one for free AI-readable designs Cursor generates from.

### How should rules be structured?

A small project-wide core plus scoped rules attached by glob: screens/ rules carry the component and styling conventions, data/ rules carry the API-client and contract discipline, native-module areas carry their platform rules. Scoping keeps each generation's context spend proportional to the area it touches, instead of every prompt paying for everything.

### What makes a rule effective rather than decorative?

Imperative, specific, checkable: 'lists use FlatList with stable keyExtractor and memoized rows' changes generations, while 'write performant code' changes nothing. The test is whether a violation is visible in a diff; rules that fail that test are wishes, and essays pasted into rule files are context tax wearing a seatbelt.

### How do rules and MCP divide the work?

Rules encode how to build, conventions, structure, the import rules; MCP servers supply what exists, design sources, component registries, current docs. Together they are the configured-editor baseline: taste enforced on every generation, context arriving on demand, and the prompts left to say only what is new about this task.

### What is rule drift and how is it prevented?

Rules describing decisions the team abandoned: a ruleset pointing at the old state library or the pre-migration folder layout actively misleads every generation thereafter, worse than no rules. The prevention is procedural, the rule updates in the same commit as the decision it encodes, and a quarterly read-through catches what slipped.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*