Cursor Notepads

Notepads are named scratchpads that you attach to Composer or Chat prompts with @NoteName. They hold whatever text you want the AI to see every time you invoke them: design tokens, API schemas, commit templates, code review checklists. Where .cursorrules is always on, Notepads are opt-in per prompt, which keeps them out of the way until you need them.

This page covers how to create a Notepad, how to attach it, six practical use cases, and when Notepads beat rules or file attachments.

What a Notepad is

A Notepad is a markdown document stored in your Cursor workspace under .cursor/notepads/. Each notepad has a name and a body. The body can be anything: bullet lists, code snippets, JSON samples, prose instructions.

Cursor does not interpret the content. It just injects the notepad body into your prompt when you reference it with @NotepadName.

Creating a Notepad

Two ways to create one.

First, from the sidebar: open the Notepads panel (the paper icon in the Cursor primary sidebar), click New Notepad, name it, write content, save.

Second, from the @ menu: type @ in Composer or Chat, select Notepads, then Create. You get a new notepad dialog.

Names should be short and memorable. design-tokens, api-schema, commit-template. The AI and you will both see the name, so pick something you can remember without checking.

Attaching a Notepad

Inside Composer or Chat, type @ and the notepad name. The @ menu filters live as you type:

@design-tokens Apply these tokens to the Button component.

The notepad content is prepended to your prompt behind the scenes. The model sees both the notepad and your instruction as a combined input.

You can attach multiple notepads to one prompt. A typical sequence: @api-schema @error-template Add a new GET endpoint for users and follow the error handling pattern in the template.

Notepads vs Rules

The difference is when they fire.

Rules (via .cursorrules or Project Rules) are automatic. Every prompt sees them without you doing anything. Good for conventions that apply to every session.

Notepads are manual. The AI sees them only when you attach them with @. Good for context that matters for some tasks but would be noise on others.

Ask: should the AI see this on every prompt? If yes, put it in rules. If no, put it in a notepad.

Six practical use cases

1. Design system tokens

Paste your color, spacing, and typography variables into a notepad named design-tokens. Attach it when you ask the AI to build UI components:

# Design tokens

Colors:
- primary: #00c896 (teal)
- accent: #f97316 (amber)
- bg: #080604
- surface: #111110
- text: #e7e5e4

Spacing: 4 8 12 16 24 32 48 64
Radius: 6 10 14 (pick one per site, apply everywhere)

Fonts:
- Display: Instrument Serif italic
- Mono: JetBrains Mono
- Body: Inter

Now every UI task gets consistent tokens without you having to re-explain the system.

2. API schema

Paste your OpenAPI or REST schema into a notepad. When you ask the AI to write an integration, attach the notepad:

@api-schema Write a TypeScript client for the billing endpoints.

The AI sees the exact field names, types, and error codes, so it does not invent them.

3. Error template

Standard error handling patterns are easy to document in a notepad:

# Error handling pattern

- Throw typed errors that extend `AppError` from `src/lib/errors.ts`.
- Log to the structured logger with `logger.error({ err, context })`.
- Wrap external API calls in try/catch that translates provider errors to AppError subclasses.
- Route handlers return a `{ error, code, message }` shape with 4xx or 5xx status.

Attach when asking the AI to touch error-prone code paths.

4. Database schema

For query tasks, a notepad with the table definitions beats the AI reading the whole migration history:

# Tables

users(id UUID PK, email TEXT UNIQUE, created_at TIMESTAMPTZ, plan TEXT)
teams(id UUID PK, name TEXT, owner_id UUID REFERENCES users(id))
members(team_id UUID, user_id UUID, role TEXT, PK(team_id, user_id))
subscriptions(id UUID PK, team_id UUID REFERENCES teams(id), status TEXT, renews_at TIMESTAMPTZ)

Attach when writing SQL or ORM queries.

5. Commit format

For consistent commit messages:

# Commit format

`type(scope): summary`

type = feat, fix, chore, docs, test, refactor, perf, ci
scope = the package, module, or feature area
summary = imperative, lowercase, no period, under 72 chars

Body: optional, wraps at 72, explains why, not what.
Footer: BREAKING CHANGE: ... for breaking changes, Refs #123 for issues.

Attach when asking the AI to write commit messages for a batch of changes.

6. Code review checklist

Paste what you look for in review:

# Review checklist

- No console.log in src/
- Error paths covered
- New functions have tests
- Types are narrow, not `any`
- Public APIs have JSDoc
- Migrations are two-step for column drops
- No secret in the diff

Attach when asking the AI to review a PR diff: @review-checklist @Git Review the changes in the last 5 commits.

Managing many notepads

When the notepad count crosses 10 or 15, a naming convention helps.

One working system: prefix by domain. design-tokens, design-patterns, api-billing, api-users, test-patterns, commit-format. Alphabetical sort in the sidebar groups related notepads.

Another: use verb-noun. review-diff, write-commit, explain-function, generate-test. Each notepad maps to one task type.

Pick a convention and stick with it. Fifty notepads with random names is worse than ten with consistent names.

Notepads vs .cursorrules

When to pick each:

• Convention applies to every prompt: rules
• Convention applies to one type of task: notepad
• Large block of reference data (schemas, tokens): notepad
• Short instruction (use type not interface): rule
• Team-shared, project-scoped: rules (check into git)
• Personal shortcut, reused across projects: notepad (in a personal workspace)

Rules and notepads coexist. Most mature Cursor setups have 200-300 lines of rules plus 10-20 notepads.

Notepads vs @File

@File attaches a file from your project. Notepad attaches content you control independent of the project.

If the content lives in a real file (a schema.ts file, a tokens.json), attach the file. If the content is a prompt template, a checklist, or a summary you wrote for the AI, use a notepad.

Rule: files are code, notepads are prompt material. Do not duplicate your schema.ts into a notepad; just attach the file.

Size limits and best practices

Cursor does not enforce a hard size limit, but practical limits apply:

• Keep notepads under 500 lines; past that they crowd the context window
• Split large notepads by topic rather than one giant reference
• Avoid duplicating content that is also in rules
• Review notepads every 3-6 months; delete anything you have not used
• Do not put secrets in notepads; they sync to Cursor servers like any other workspace file

When Notepads are the wrong tool

Patterns where Notepads are not the right answer:

• Always-on conventions: use rules
• Live data that changes: use @Web or a script
• File content that already exists: use @File
• One-off context for a single prompt: paste directly into the prompt; a notepad you use once is overhead

Team sharing

Notepads live in .cursor/notepads/ under your workspace. Check them into git and your team gets the same notepads on every clone. Treat them like prompt source code: review in PRs, document intent, delete when obsolete.

For truly personal notepads that should not be committed, use a global Cursor workspace or keep them in a separate .cursor/personal-notepads/ directory that you gitignore.