Cursorプロジェクトルールの使い方：.cursor/rules、種類、最初の Agent ルール
.mdc を .cursor/rules に置き、Agent の diff をリポジトリに合わせる。
Ask Cursor Agent to tweak one component and it reformats unrelated imports across the tree — review noise beats the actual fix. Project rules live in .cursor/rules/ as .mdc files with YAML frontmatter so the Agent knows scope, test commands, and style limits. See Cursor’s official Rules / Project rules documentation.
Searchers looking for Cursor プロジェクトルール .cursor/rules ルール種類 Agent 編集 need: understand rule types (always apply, file globs, on-demand), add a first verifiable rule, and make the next Agent diff match team habits. Steps follow Cursor docs — no third-party plugins required.
Who this helps
Shared monorepos
Frontend, backend, and scripts coexist — you want Agent hands off backend/public and build artifacts.
Teams with lint but messy Agent diffs
ESLint/Prettier handle save-time format; Agent batch edits still need prose constraints (tests, minimal diff).
New Cursor Agent adopters
Turn README verbal agreements into versioned rules that apply on every clone.
Where rules live
Project rules sit under .cursor/rules/, one .mdc per concern: frontmatter + Markdown body. Commit them like code. This guide focuses on .cursor/rules; AGENTS.md can complement but not replace focused rules.
| Type (UI label) | Frontmatter | When it applies |
|---|---|---|
| Always Apply | alwaysApply: true | Every Agent / Chat session |
| Apply to Specific Files | globs: **/*.vue | When matching paths are in context |
| Apply Intelligently | description: | Model decides from the description |
| Apply Manually | No always, no globs | You attach or enable in the rule list |
First project rule: minimal diff
- 1
Create the folder
From repo root:
mkdir -p .cursor/rules. If rules already exist, review them before adding duplicates. - 2
Add an .mdc file
e.g.
.cursor/rules/agent-minimal-diff.mdc. UsealwaysApply: trueonly for short universal constraints; for Vue-only guidance setglobs: frontend-app/**/*.vueandalwaysApply: false. - 3
Write actionable bullets
State: touch only task-related files, plan before editing, which test command to run, forbidden paths. Keep one theme per file; aim for under ~50 lines.
- 4
Commit and review
Rules change Agent behavior long-term — PR review them like application code.
- 5
Accept with a tiny Agent job
Ask Agent to add one small feature; confirm the diff stays scoped. Tighten globs or forbidden paths if not.
---
description: Keep Agent edits scoped and minimal
alwaysApply: true
---
# Agent edit scope
- Change only files required for the user request.
- Do not reformat unrelated files or reorder imports repo-wide.
- Before editing, list planned files in the chat.
- After edits, run `npm run test -- --run` when tests exist.
- Never edit `backend/public/` or lockfiles unless asked.
User Rules vs project rules
- User Rules
- Stored in Cursor settings — cross-project personal prefs, not repo-specific paths.
- Project Rules
- Travel with the repo — monorepo paths, test commands, release checks.
- Skills
- Long workflows belong in skills; day-to-day coding constraints stay in short rules.
A few sharp rules beat one megabyte README pasted into every chat.
Align rules with teammates from the wbroom homepage — create and join a room. For terminal Git UX see our lazygit guide and Zed getting started.
Questions worth checking
Rules not applying?
Open the repo root in Cursor, confirm .mdc files under .cursor/rules/ with valid frontmatter. Check Settings → Rules lists project rules; start a fresh Agent session after edits.
alwaysApply plus globs?
Follow Cursor docs: global constraints use alwaysApply: true; path-specific rules use globs. Avoid duplicating the same theme twice.
.md instead of .mdc?
Project rules use frontmatter .mdc. Migrate legacy .cursorrules into split files under .cursor/rules.
Secrets in rules?
Never. Reference command names and path patterns only; keep API keys in env or a secrets manager — do not commit .env.