02 - カーソル ルール: プロジェクトに合わせて AI を構成する
各開発者には独自の規則、アーキテクチャ パターン、品質基準があります。一緒に仕事をするときは 人間の同僚である場合、これらのルールはコード レビュー、ペア プログラミング、ドキュメントを通じて伝達されます。 しかし、同じ期待を AI エージェントにどのように伝えることができるでしょうか?カーソルの応答と ルールシステム: AI に次の方法を指示できる強力かつ柔軟なメカニズム プロジェクトのコードを生成、変更、推論する必要があります。
この記事では、カーソル ルール システムの歴史的な進化から、カーソル ルール システムのあらゆる側面を探っていきます。 Angular、React、Python、API バックエンドの実践的な例を通じて、高度な構成戦略まで説明します。 などなど。最終的には、Cursor AI を協力者に変えるためのすべてのツールが手に入ります。 チームの慣例を、まるで以前から知っていたかのように尊重してください。
この記事で学べること
- ルールシステムの進化：から
.cursorrulesディレクトリに.cursor/rules/ - 4 つのルール タイプ: 常時、自動接続、エージェント要求、および手動
- ユーザー ルールとプロジェクト ルールの違いと、それぞれのタイプをいつ使用するか
- フロントマター、グロブ、説明を使用して効果的なルールを作成する方法
- Angular、React、Python、FastAPI、REST API の完全な例
- 高度な戦略: 条件付きルール、ルール継承、自動生成
- チームのワークフロー: git を介した共有、オンボーディング、および共有規約
- CLAUDE.mdと他のAI命令システムとの比較
カーソル IDE および AI ネイティブ開発シリーズの概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | 完全なカーソル IDE ガイド | 完全な概要 |
| 2 | あなたはここにいます - カーソルルール | カスタム AI セットアップ |
| 3 | エージェントモード | 高度な自動化 |
| 4 | プランモード | 計画支援 |
| 5 | フックとMCP | 拡張性と統合 |
| 6 | プロフェッショナルなワークフロー | ベストプロダクションプラクティス |
カーソルのルール システムの進化
Cursor のルール システムは、最初の導入以来、大幅な進化を遂げてきました。 この歴史を理解することは、現在のシステムがなぜ特定の方法で構造化されているかを理解するための基礎となります。 異なる構成世代間の混乱を避けるためです。
第 1 世代: .cursorrules ファイル
最初の実装では、Cursor は単一のファイルをサポートしていました .cursorrules プロジェクトのルートにあります。
このファイルには、各 AI インタラクションのコンテキストに挿入されるフリーテキストの命令が含まれていました。
それはシンプルで簡単でした。ルールをファイルに書き込むと、AI がそれに従うようになります。
Sei uno sviluppatore senior specializzato in Angular e TypeScript.
Regole di codice:
- Usa sempre standalone components
- Preferisci signals rispetto a BehaviorSubject
- Usa OnPush change detection in tutti i componenti
- Scrivi sempre i test unitari per i servizi
- Segui le convenzioni di naming Angular (kebab-case per i file)
Stile di risposta:
- Rispondi in italiano
- Spiega il ragionamento dietro ogni scelta
- Includi gestione degli errori in ogni esempio
このアプローチには明らかな制限がありました。 すべてのルールは単一のモノリシック ファイルにまとめられました。
Angular フロントエンド、Python バックエンド、Docker インフラストラクチャ、CI/CD パイプラインを含む複雑なプロジェクトでは、
ファイル .cursorrules それはすぐに巨大になり、管理が困難になりました。また、すべてのルールは、
現在のコンテキストに関連していない場合でも、常に AI に送信されます。
第 2 世代: .cursor/rules/ を使用したプロジェクト ルール
これらの制限を解決するために、Cursor は プロジェクトルール に基づいて
ディレクトリ .cursor/rules/。この新しいアプローチにより、ルールを別のファイルに整理できます。
構造化メタデータとファイル パターンに基づく条件付きアクティベーションを使用します。
ディレクトリ .cursor/rules/ そして、git リポジトリにコミットされることを意図しているため、誰もが
チームメンバーは同じ AI 命令を自動的に共有します。ディレクトリ内の各ファイルはファイルです
.mdc (コンテキスト付きマークダウン) YAML フロントマターとマークダウンのステートメントの本文が含まれます。
なぜ .md ではなく .mdc なのか?
フォーマット .mdc (Markdown with Context) は独自の Cursor 拡張機能であり、
標準の Markdown 構造化フロントマター。フロントマターはメタデータを、
ルール、自動アクティブ化のグロブ パターン、およびフラグ alwaysApply。カーソルの解釈
このメタデータを使用して、各ルールをいつどのように適用するかを決定します。
4種類のルール
最新の Cursor システムは 4 つのルール アクティベーション モードを定義しており、それぞれが次のように設計されています。 特定の使用例。指示の関連性のバランスを取るには、適切なタイプを選択することが重要です AI コンテキストの消費を伴う。
1. 常にルール
型のルール いつも 関係なく、AI とのあらゆるやり取りに含まれます。 作業中のファイルまたは作成したリクエストから。それらは世界共通の慣例に最適です。 常に尊重されなければならないプロジェクト。
---
description: Convenzioni globali del progetto
alwaysApply: true
---
# Convenzioni Progetto
## Linguaggio
- Rispondi sempre in italiano
- Usa commenti in inglese nel codice
- Variabili e funzioni in inglese (camelCase)
## Architettura
- Pattern: Feature-based folder structure
- State management: Signals (Angular) / Zustand (React)
- Testing: Ogni modulo deve avere copertura > 80%
## Git
- Commit messages in conventional commits format
- Prefissi: feat, fix, refactor, docs, test, chore
- Branch naming: feature/xxx, bugfix/xxx, hotfix/xxx
コンテキストの消費に注意する
ルールは必ず来る いつも AI に送信され、それぞれのコンテキスト トークンを消費します インタラクション。このタイプは、真に普遍的なルールにのみ使用してください。ルールが特定のユーザーにのみ適用される場合 ファイルまたはシチュエーションの場合は、コンテキストの使用を最適化するために、自動添付またはエージェント要求を選択してください。
2. 自動添付ルール
ルール 自動添付 一致するファイルの作業を行うと自動的にアクティブになります 特定のグロブパターンに。これらは、言語、フレームワーク、またはファイル タイプに固有のルールに最適です。
---
description: Regole per componenti Angular
globs: ["**/*.component.ts", "**/*.component.html"]
alwaysApply: false
---
# Componenti Angular
## Struttura
- Usa SEMPRE standalone components (no NgModule)
- Implementa OnPush change detection strategy
- Preferisci signals() e computed() per lo stato reattivo
- Usa input() e output() signal-based (non @Input/@Output decorators)
## Template
- Usa la nuova control flow syntax: @if, @for, @switch
- Preferisci @defer per lazy loading di sezioni pesanti
- Non usare mai ngIf, ngFor, ngSwitch (legacy)
## Naming
- File: kebab-case (es. user-profile.component.ts)
- Selettore: prefisso app- (es. app-user-profile)
- Classe: PascalCase (es. UserProfileComponent)
フィールド globs 標準のグロブパターンをサポートします。次のような単純なワイルドカードを使用できます *.ts
または次のような複雑なパターン {**/*.service.ts,**/*.guard.ts}。ファイルを開くとき
パターンに一致するルールは、自動的に AI コンテキストに組み込まれます。
3. エージェントが要求したルール
ルール エージェントがリクエストしました AI には説明を通じてそれらが表示されますが、実際に来ます。 エージェントが現在のタスクに関連すると判断した場合にのみコンテキストに含められます。この男と 常に必要ではないが、必要に応じて AI が参照できるようにする必要がある専門的なルールに最適です。
---
description: Regole per la creazione e gestione delle migrazioni database con Prisma
alwaysApply: false
---
# Migrazioni Database
## Creazione Migrazioni
- Usa sempre `prisma migrate dev --name descrizione-cambiamento`
- Nomi migrazioni: snake_case, descrittivi (es. add_user_roles_table)
- Non modificare MAI migrazioni già applicate in produzione
## Schema Prisma
- Ogni modello deve avere: id, createdAt, updatedAt
- Usa @@map per nomi tabella in snake_case
- Relazioni: definisci sempre entrambi i lati
- Indici: aggiungi @@index per campi usati in WHERE e JOIN
## Rollback
- Testa sempre il rollback prima di applicare in staging
- Documenta i passaggi manuali necessari nel file di migrazione
この例では、ルールには globs そしてそれは alwaysApply: false。 AI が認識するのは
説明「Prisma によるデータベース移行の作成と管理のルール」は独自に決定します
タスクにデータベース操作が含まれる場合に、ルールの完全な内容を含めるかどうか。このアプローチ
特に効率的: AI はコンテキストを無駄にすることなく、専門知識のカタログにアクセスできます。
必要ないとき。
4. マニュアルルール
ルール マニュアル これらは自動的に含まれることはありません。明示的に言及する必要があります
開発者がリファレンスを使用して @ruleName プロンプトで。テンプレートとしては便利ですが、
特定の状況でのみ使用するスニペットや指示。
---
description: Template per la creazione di una nuova feature Angular completa
alwaysApply: false
---
# Template Nuova Feature
Quando creo una nuova feature Angular, genera i seguenti file:
## Struttura Directory
```
src/app/features/[feature-name]/
[feature-name].component.ts # Componente principale
[feature-name].component.html # Template
[feature-name].component.css # Stili
[feature-name].component.spec.ts # Test componente
[feature-name].service.ts # Servizio dati
[feature-name].service.spec.ts # Test servizio
[feature-name].routes.ts # Routing lazy-loaded
[feature-name].model.ts # Interfacce e tipi
```
## Checklist
- [ ] Componente standalone con OnPush
- [ ] Servizio con HttpClient e gestione errori
- [ ] Route lazy-loaded registrata in app.routes.ts
- [ ] Test unitari per componente e servizio
- [ ] Interfacce per i modelli dati
このルールを使用するには、開発者は次のように記述します。 「@new-feature-template に従って、ユーザー プロファイルの新しい機能を作成してください」。 AIはルールの内容をコンテキストに含めて、テンプレートに従ってコードを生成します。
ルールの種類の概要
| タイプ | アクティベーション | 使用事例 | 消費コンテキスト |
|---|---|---|---|
| いつも | 常に含まれています | ユニバーサルデザインの規約 | 高 (常にアクティブ) |
| 自動添付 | ファイル上のグロブパターン | 言語/フレームワーク固有のルール | 中 (関連ファイルのみ) |
| エージェントがリクエストしました | 記述を基にAIが判断 | オンデマンドの専門知識 | 低 (必要な場合のみ) |
| マニュアル | @name を使用した明示的な呼び出し | テンプレート、スニペット、珍しい説明書 | 最小値（リクエストに応じてのみ） |
ユーザー ルールとプロジェクト ルール
カーソルは 2 つの構成レベルを区別します: le ユーザールール 誰にでも当てはまること あなたのプロジェクトと プロジェクトルール これらは単一のリポジトリに固有のものです。 効果的なセットアップには、どちらをいつ使用するかを理解することが重要です。
ユーザー ルール: 全体的な設定
ユーザールールは以下で設定されます Cursor Settings > General > Rules for AI。これらのルール
これらは、取り組んでいるプロジェクトに関係なく、一定の個人的な好みを定義します。
これらはリポジトリ内のファイルではなく、ローカルの Cursor 設定に存在します。
## Preferenze Generali
- Rispondi sempre in italiano per le spiegazioni
- Scrivi commenti nel codice in inglese
- Quando generi codice, aggiungi sempre la gestione degli errori
- Preferisci l'immutabilita: crea nuovi oggetti invece di mutare quelli esistenti
- Usa TypeScript strict mode in tutti i progetti TypeScript
- Segui i principi SOLID e clean code
- Quando suggerisci soluzioni, spiega il ragionamento
## Formato Preferito
- Funzioni brevi (<50 righe)
- File focalizzati (<400 righe)
- Nesting massimo: 4 livelli
- Naming esplicito e descrittivo
プロジェクト ルール: リポジトリの規則
プロジェクトルールはディレクトリ内に存在します .cursor/rules/ プロジェクトに参加し、コミットしている
git リポジトリ内。これは、リポジトリのクローンを作成するすべてのチーム メンバーが自動的に
同じ AI 命令を使用して、コード生成の一貫性を確保します。
ユーザー ルールとプロジェクト ルール: いつ何を使用するか
| 待ってます | ユーザールール | プロジェクトルール |
|---|---|---|
| ほうき | すべてのプロジェクト | 単一リポジトリ |
| 位置 | カーソル設定 | .cursor/rules/*.mdc |
| 共有 | ローカルのみ | git 経由 (チーム) |
| 優先順位 | ベース (プロジェクトによってオーバーライド) | 高 (コンテキスト固有) |
| Esempio | 言語、応答スタイル、一般原則 | フレームワーク、アーキテクチャ、特定のパターン |
La 優先順位 直感的に操作できます。プロジェクト ルールはユーザー ルールよりも優先されます。 紛争が起こったとき。ユーザー ルールには「クラスを使用する」と書かれているが、プロジェクト ルールには「関数を使用する」と書かれている場合、 AI はプロジェクト ルールに従います。これにより、各プロジェクトに独自の規則を持たせることができます。 グローバル設定を変更する必要があります。
効果的なルールの構造
AI が正しく従うことができるルールを作成するには、構造と明確さに注意を払う必要があります そして説明書の簡潔さ。適切に作成されたルールは、コードを生成する AI との違いです 汎用性があり、標準に完全に一致したコードを生成する AI です。
.mdc ファイルの構造
各ファイル .mdc 2 つの部分で構成されています。 YAML のフロントマター によって区切られる
--- そして マークダウンの本文 実際の指示付き。
---
description: [Descrizione concisa per l'AI - usata per Agent Requested]
globs: ["pattern1", "pattern2"]
alwaysApply: true|false
---
# Titolo della Rule
## Sezione 1: Istruzioni Generali
- Istruzione chiara e specifica
- Esempio concreto se necessario
## Sezione 2: Pattern da Seguire
- Pattern preferito con esempio
- Anti-pattern da evitare con spiegazione
## Sezione 3: Eccezioni
- Quando NON applicare queste regole
- Casi limite e come gestirli
効果的なルールを作成するためのベスト プラクティス
実際のプロジェクトで何百ものルールを設定した結果、私は 5 つの基本原則を特定しました。 ルールの有効性を決定します。
1. 一般的なものではなく、具体的なものにしてください。 「きれいなコードを書く」というルールは役に立ちません。 「各関数には最大 4 つのパラメータが必要で、それぞれ明示的な型と JSDoc が必要」というルール AIによる操作も可能。
2. 伝えるだけではなく、見せる。 必ず少なくとも 1 つの具体的なコード例を含めてください。 ルールを尊重します。 AI は抽象的な説明よりも例からよりよく学習します。
3. アンチパターンも定義します。 してはいけないことを明確に示します。ルールなら 「シグナルを使用する」とは言うものの、「BehaviorSubject を使用しない」とは言わない場合、AI は 2 つのアプローチを混合する可能性があります。
4. ルール、テーマ。 すべてをカバーするモノリシック ファイルを作成しないでください。ルールを分割する エリアごと: テスト用に 1 つのルール、CSS 用に 1 つ、アーキテクチャ用に 1 つ。これによりメンテナンスが容易になります グロブを介した選択的なアクティブ化が可能になります。
5. AI を念頭に置いて説明を書きます。 フィールド description 前題で
AI が何を読み取って、エージェント要求ルールを含めるかどうかを決定します。簡潔でなければなりませんが、
AI がルールがいつ関連するかを理解できるようにするのに十分な情報が得られます。
Angular のルール: 完全な例
Angular は、正確な規約と急速に進化するエコシステムを備えたフレームワークです。通路とともに スタンドアロンのコンポーネント、信号、新しい制御フロー構文に対応するには、AI がコードを生成することが不可欠です それは最新のベストプラクティスに従っています。ここでは、Angular プロジェクトの完全なルール セットを示します。
---
description: Architettura e pattern generali del progetto Angular
alwaysApply: true
---
# Architettura Angular
## Versione e Stack
- Angular 19+ con standalone components
- TypeScript 5.7+ in strict mode
- Stato: Angular Signals (signal, computed, effect)
- HTTP: HttpClient con interceptor funzionali
- Routing: Lazy loading con loadComponent/loadChildren
## Struttura Cartelle
```
src/app/
core/ # Servizi singleton, guard, interceptor
shared/ # Componenti, pipe, direttive condivise
features/ # Feature modules (una cartella per feature)
feature-a/
components/
services/
models/
feature-a.routes.ts
layouts/ # Layout components (header, footer, sidebar)
```
## Principi
- NESSUN NgModule: tutto standalone
- Lazy loading per ogni feature route
- Servizi in core/ forniti in root (providedIn: 'root')
- Componenti condivisi in shared/ senza logica di business
- Un componente = un file .ts + .html + .css + .spec.ts
---
description: Regole per l'uso di Angular Signals e reattività
globs: ["**/*.component.ts", "**/*.service.ts"]
alwaysApply: false
---
# Angular Signals
## Stato Reattivo
- USA: signal() per stato locale del componente
- USA: computed() per valori derivati
- USA: effect() SOLO per side effects (logging, localStorage)
- NON USARE: BehaviorSubject per stato locale
- NON USARE: getter con logica complessa (usa computed)
## Input/Output Signal-based
- USA: input() e input.required() per gli input
- USA: output() per gli eventi
- NON USARE: @Input() e @Output() decorators (deprecati)
- USA: model() per two-way binding
## Esempio Corretto
```typescript
export class UserCardComponent {
// Input signal-based
readonly user = input.required<User>();
readonly showAvatar = input(true);
// Computed da input
readonly displayName = computed(() =>
`${this.user().firstName} ${this.user().lastName}`
);
// Output signal-based
readonly selected = output<User>();
onSelect(): void {
this.selected.emit(this.user());
}
}
```
## Anti-pattern da Evitare
```typescript
// SBAGLIATO: decoratori legacy
@Input() user!: User;
@Output() selected = new EventEmitter<User>();
// SBAGLIATO: BehaviorSubject per stato locale
private userSubject = new BehaviorSubject<User | null>(null);
```
---
description: Convenzioni per i test unitari Angular con Jest/Vitest
globs: ["**/*.spec.ts"]
alwaysApply: false
---
# Testing Angular
## Framework
- Test runner: Jest o Vitest (NO Karma/Jasmine)
- Asserzioni: expect() nativo
- Mocking: jest.mock() o vi.mock()
## Struttura Test
- Raggruppa con describe() per metodo/feature
- Naming: "should [expected behavior] when [condition]"
- AAA pattern: Arrange, Act, Assert
- Un assert per test (quando possibile)
## Componenti
- Usa TestBed.configureTestingModule con standalone: true
- Mock tutti i servizi iniettati
- Testa il rendering del template con fixture.debugElement
- Testa gli input/output signal-based con componentRef.setInput()
## Servizi
- Usa TestBed.inject() per ottenere il servizio
- Mock HttpClient con HttpClientTestingModule
- Testa tutti i path: successo, errore, edge case
- Verifica le chiamate HTTP con expectOne()
## Copertura Minima
- Servizi: 90%
- Componenti: 80%
- Utility: 95%
Python のルール: 完全な例
Python は、正確な哲学 (The Zen of Python) と統合された規約 (PEP 8) を持つ言語です。 Python のルールでは、これらの規則を取り込み、プロジェクトの詳細を追加する必要があります。
---
description: Convenzioni Python per il progetto backend
globs: ["**/*.py"]
alwaysApply: false
---
# Convenzioni Python
## Versione e Stile
- Python 3.12+
- Segui PEP 8 rigorosamente
- Type hints su TUTTE le funzioni e variabili di classe
- Usa f-string per la formattazione (mai .format() o %)
- Line length massimo: 100 caratteri
## Type Hints
```python
def get_user_by_id(user_id: int) -> User | None:
"""Recupera un utente per ID."""
...
def process_items(items: list[Item], *, limit: int = 100) -> list[Result]:
"""Processa una lista di item con limite opzionale."""
...
```
## Struttura Classi
- Usa dataclasses o Pydantic models per i dati
- Protocol per le interfacce (non ABC, salvo casi specifici)
- Metodi privati con prefisso _ (singolo underscore)
- Nessun metodo > 30 righe
## Import
- Ordine: stdlib, third-party, local (separati da riga vuota)
- Import assoluti (mai relativi con .)
- Usa `from __future__ import annotations` per type hints moderni
## Error Handling
- Cattura eccezioni specifiche (mai bare except)
- Usa custom exceptions per errori di dominio
- Logging strutturato con structlog
---
description: Pattern e convenzioni per le API FastAPI
globs: ["**/api/**/*.py", "**/routes/**/*.py", "**/endpoints/**/*.py"]
alwaysApply: false
---
# Pattern FastAPI
## Struttura Endpoint
```python
@router.get(
"/users/{user_id}",
response_model=UserResponse,
summary="Get user by ID",
responses={404: {"model": ErrorResponse}},
)
async def get_user(
user_id: int = Path(..., gt=0),
db: AsyncSession = Depends(get_db),
current_user: User = Depends(get_current_user),
) -> UserResponse:
"""Recupera un utente specifico per ID."""
user = await user_service.get_by_id(db, user_id)
if not user:
raise HTTPException(status_code=404, detail="User not found")
return UserResponse.model_validate(user)
```
## Convenzioni
- Usa Pydantic v2 per request/response models
- Dependency Injection per DB, auth, config
- Async per TUTTE le operazioni I/O
- Response models espliciti (mai dict generici)
- Validazione input con Field() e Path()
- HTTP status codes corretti (201 create, 204 delete, etc.)
## Error Handling
- HTTPException per errori HTTP standard
- Custom exception handlers per errori di dominio
- Formato errore standard: {"detail": "message", "code": "ERROR_CODE"}
React/Next.js のルール: 完全な例
React エコシステムは、サーバー コンポーネント、アプリ ルーター、アクションを備えた React 19 など、常に進化しています。 ルールは現代の慣例を取り入れ、従来のパターンを避ける必要があります。
---
description: Convenzioni React e Next.js per il progetto frontend
globs: ["**/*.tsx", "**/*.jsx"]
alwaysApply: false
---
# React / Next.js Conventions
## Framework
- Next.js 15+ con App Router
- React 19+ con Server Components di default
- TypeScript strict mode
- Styling: Tailwind CSS v4
## Componenti
- Server Components per default (niente "use client" se non necessario)
- Client Components SOLO per interattivita (click, form, state)
- Named export per i componenti (non default export)
- Props tipizzate con interface (non type alias)
## Pattern Preferiti
```tsx
// Server Component (default)
interface UserProfileProps {
readonly userId: string;
}
export async function UserProfile({ userId }: UserProfileProps) {
const user = await getUser(userId);
return (
<section className="p-4">
<h2>{user.name}</h2>
<UserActions user={user} />
</section>
);
}
```
## State Management
- React useState/useReducer per stato locale
- Zustand per stato globale client-side
- Server Actions per mutazioni (form, POST)
- NON usare useEffect per fetch dati (usa Server Components)
## Anti-pattern
- NO default export per componenti
- NO useEffect per data fetching
- NO index.tsx come nome componente
- NO prop drilling > 3 livelli (usa context o composition)
バックエンドとREST APIのルール
API はフロントエンドとバックエンドの間の契約です。明確に定義されたルールにより、応答の一貫性が保証されます。 エラー処理と認証において。
---
description: Convenzioni API REST per tutti gli endpoint
globs: ["**/controllers/**", "**/routes/**", "**/api/**"]
alwaysApply: false
---
# API REST Conventions
## URL Design
- Risorse in plurale: /users, /products, /orders
- Nesting massimo: 2 livelli (/users/{id}/orders)
- Verbi HTTP per le azioni: GET (read), POST (create), PUT (replace),
PATCH (update), DELETE (remove)
- Query params per filtering, sorting, pagination
## Response Format Standard
```json
{
"success": true,
"data": { ... },
"meta": {
"page": 1,
"limit": 20,
"total": 150
}
}
```
## Error Response Format
```json
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "Email format is invalid",
"details": [
{ "field": "email", "message": "Must be a valid email address" }
]
}
}
```
## Status Codes
- 200: Success (GET, PUT, PATCH)
- 201: Created (POST)
- 204: No Content (DELETE)
- 400: Bad Request (validazione fallita)
- 401: Unauthorized (non autenticato)
- 403: Forbidden (non autorizzato)
- 404: Not Found
- 409: Conflict (duplicato, stato inconsistente)
- 422: Unprocessable Entity (logica di business)
- 500: Internal Server Error (mai esporre dettagli)
## Paginazione
- Usa cursor-based pagination per dataset grandi
- Offset-based per casi semplici
- Includi sempre: page, limit, total, hasNext
レガシー .cursorrules ファイルからの移行
古いファイルを使用している場合 .cursorrules、良いニュースは、Cursor がそれを保持することです。
下位互換性: 従来のファイルは引き続き動作します。ただし、新しいシステムに移行する
.cursor/rules/ 組織と柔軟性の点で大きな利点があります。
移行戦略
移行は、全か無かの操作である必要はありません。次の手順に従って、徐々に進めることができます。
- ディレクトリを作成する
.cursor/rules/あなたのプロジェクトで - カテゴリを特定する あなたのファイルに
.cursorrules: 一般的な慣例、 言語のルール、テストパターン、応答スタイル - カテゴリごとに抽出 ファイルの中に
.mdc適切な前付で区切る - 正しいタイプを割り当てる: 常に普遍的な規則に従い、グロブを自動的にアタッチします 言語固有のルールについては、エージェントに専門知識が求められます
- Testa AI はさまざまな状況で新しいルールを尊重する
- 取り除く ファイル
.cursorrules移行に満足したら
.cursorrules と .cursor/rules/ の間の競合
両方が存在する場合、カーソルは両方のファイルをロードします。 .cursorrules ファイルが
.cursor/rules/。これにより、命令が重複したり矛盾したりする可能性があります。その間、
移行、セクションに関するコメント .cursorrules 新しいファイルに抽出すると、
.mdcし、移行が完了した場合にのみレガシー ファイルを削除します。
高度なルール戦略
高度なグロブパターン
グロブ パターンは、ルールを正確にターゲット設定するための最も強力なツールです。パターンは次のとおりです 現実世界のシナリオではより便利です。
# File specifici per tipo
**/*.component.ts # Tutti i componenti Angular
**/*.service.ts # Tutti i servizi Angular
**/*.spec.ts # Tutti i file di test
**/*.stories.tsx # Tutti gli Storybook stories
# Directory specifiche
src/app/core/** # Tutto nella directory core
src/app/features/**/*.ts # Solo TypeScript nelle features
# Combinazioni multiple
**/*.{ts,tsx} # TypeScript e TypeScript React
**/{api,routes}/**/*.py # File Python in api/ o routes/
# Esclusioni con negazione (in alcuni contesti)
!**/*.spec.ts # Escludi i file di test
!**/node_modules/** # Escludi node_modules
ファイルタイプの条件付きルール
効果的な戦略は、ファイルのコンテキストに基づいてアクティブ化されるルールを作成することです。たとえば、 データベース移行ファイルには、アプリケーション ロジック ファイルとは異なるルールを設定できます。 どちらも Python ファイルですが。
---
description: Regole specifiche per file di migrazione Alembic
globs: ["**/alembic/versions/**/*.py", "**/migrations/**/*.py"]
alwaysApply: false
---
# Migrazioni Database (Alembic)
## Struttura
- Ogni migrazione deve avere upgrade() e downgrade()
- Commenta SEMPRE la motivazione della migrazione
- Usa batch operations per SQLite compatibility
## Naming
- Formato: YYYYMMDD_HHMM_descrizione_breve.py
- Descrizione in snake_case, max 50 caratteri
## Safety
- Mai DROP TABLE senza backup esplicito
- Mai ALTER COLUMN che rimuove dati senza migrazione dati
- Testa SEMPRE downgrade() prima di committare
ルールの構成可能性: 相互に補完するルール
ルールは孤立しているのではなく、AI のコンテキストで結合されます。効果的な戦略と設計ルール これらは相互に補完し合い、一貫した指示システムを作成します。
たとえば、一般的な規則には Always ルールを設定し、次の場合には Auto Attached ルールを設定できます。
言語仕様とアーキテクチャ パターンのエージェント要求ルール。仕事をするとき
Angular コンポーネントでは、AI は次のものを受け取ります: 一般的な規則 (常に) + Angular ルール
(グロブから自動接続されます) **/*.component.ts) + おそらくアーキテクチャ上のルール
(エージェントがタスクに関連していると判断した場合)。
ルールを自動的に生成する
Cursor には、既存のコードベースからルールを生成するための組み込みコマンドが含まれています。
/Generate Cursor Rules。このコマンドはプロジェクトを分析し、パターンを特定します
繰り返し実行され、すでに使用されている規則を捕捉する一連の初期ルールが生成されます。
コマンドの使用方法
- カーソルのチャットパネルを開きます (
Cmd+L/Ctrl+L) - タイプ
/Generate Cursor Rules - AI がコードベースを分析し、一連のルールを提案します
- 提案されたルールを確認、変更し、ディレクトリに保存します
.cursor/rules/
ヒント: 既存のコードベースから開始する
コマンド /Generate Cursor Rules 特に既存のプロジェクトに役立ちます。
規則はコード内に暗黙的に含まれていますが、文書化されていません。 AI は次のようなパターンを識別します。
コンポーネントの構造、命名、エラー処理パターンを明示的なルールに変換します。
この結果は、最終的な構成としてではなく、調整の開始点として考えてください。
プロンプト付きの生成支援
Cursor の AI に手伝ってもらい、ルールを手動で作成することもできます。サンプルファイルを提供してください あなたの理想のスタイルをAIに抽出してもらいます。
Analizza il file user.service.ts e genera un file .mdc per
.cursor/rules/ che catturi tutte le convenzioni che vedi:
- Pattern di gestione errori
- Struttura dei metodi
- Uso di tipi e interfacce
- Pattern di dependency injection
- Formato dei commenti e della documentazione
Il file deve essere Auto Attached per tutti i file *.service.ts
チームワークフロー: 共有ルール
プロジェクト ルールの最も重要な利点の 1 つは、git 経由でプロジェクト ルールを共有できることです。 This opens up huge possibilities for team alignment and onboarding new developers.
共有戦略
ディレクトリ .cursor/rules/ としてリポジトリにコミットする必要があります
.editorconfig, .eslintrc o tsconfig.json。これらのルール
それらはプロジェクト定義の一部となり、各チームメンバーがいつでも
カーソルを使用すると、同じ AI 命令を受け取ります。
.cursor/
rules/
# Always Rules - Convenzioni universali
01-project-overview.mdc # Descrizione del progetto e stack
02-coding-standards.mdc # Standard di codice condivisi
03-git-workflow.mdc # Convenzioni git e PR
# Auto Attached - Per linguaggio/framework
angular-components.mdc # Regole componenti Angular
angular-services.mdc # Regole servizi Angular
angular-testing.mdc # Regole test Angular
css-conventions.mdc # Regole CSS/SCSS
api-endpoints.mdc # Regole API REST
# Agent Requested - Conoscenze specialistiche
database-schema.mdc # Schema e migrazioni DB
deployment-pipeline.mdc # Pipeline CI/CD
security-guidelines.mdc # Linee guida sicurezza
# Manual - Template e snippet
new-feature-template.mdc # Template nuova feature
bug-fix-checklist.mdc # Checklist per bug fix
code-review-criteria.mdc # Criteri per code review
ルールを使用したオンボーディング
プロジェクト ルールを使用すると、新しい開発者のオンボーディングを大幅にスピードアップできます。新しいもの リポジトリのクローンを作成して Cursor の使用を開始したチーム メンバーは、すぐにすべてのリポジトリにアクセスできるようになります。 AI によるプロジェクトの慣例。 50 ページのオンボーディング ドキュメントを読む必要はありません。 コードを記述するたびに、AI が自動的に正しい規則を適用します。
共有ルールの利点
- 一貫性： すべての AI 生成コードは、関係なく同じ標準に従います。 開発者による
- 素早いオンボーディング: 新しい開発者は初日から準拠したコードを作成します
- コードレビューの削減: スタイルや慣習についての解説を減らし、ロジックに重点を置きます
- ライブドキュメント: ルールはプロジェクトとともに更新される実行可能なドキュメントです
- 制御された進化: 規約への変更は他のものと同様に git review を通過します 変化する
CLAUDE.mdと他のシステムとの比較
Cursor のルール システムは、プロジェクトのコンテキストについて AI を教育する唯一の方法ではありません。
クロードコードはファイルを使用します CLAUDE.md、GitHub Copilot が導入しました。
.github/copilot-instructions.md ウィンドサーフィンでの使用 .windsurfrules。
それらをどのように比較してみましょう。
AI構成システムの比較
| 特性 | カーソルのルール | クロード.md | 副操縦士の指示 |
|---|---|---|---|
| 複数のファイル | はい (.cursor/rules/) | はい (.claude/ ディレクトリ) | 単一ファイル |
| アクティベーションの種類 | 4種類（常時、自動、エージェント、手動） | 常にアクティブ + メモリ | 常にアクティブ |
| 地球のパターン | はい (フロントマター グロブ) | No | No |
| Git の共有 | Si | Si | Si |
| ユーザーレベルのルール | はい（設定） | はい (~/.claude/) | 限定 |
| 形式 | .mdc (YAML フロントマター + MD) | .md (純粋なマークダウン) | .md (純粋なマークダウン) |
| 自動生成 | はい (/カーソル ルールの生成) | いいえ (ただし /init は利用可能) | No |
最も大きな違いはシステムです 条件付きアクティベーション カーソルの。
CLAUDE.md と Copilot 命令は常にアクティブですが (すべての対話でコンテキストを消費します)、
カーソルを使用すると、ルールが関連する場合にのみルールをアクティブ化できます。フロントエンドを備えたフルスタック プロジェクトの場合
Angular、Python バックエンド、Terraform インフラストラクチャ、Angular ルールは次の場合にのみ含まれます。
ファイルで作業する .component.ts、関連する指示のための貴重なコンテキストを保存します。
Cursor のもう 1 つのユニークな利点は、次のタイプです。 エージェントがリクエストしました。 AIが判断できる タスクに基づいてどのルールを参照するかを自律的に決定し、オンデマンドの知識システムを作成します。 コンテキストを不必要に消費することなく、制限なく拡張できます。
完全な実践例
このセクションでは、一般的なシナリオですぐに使用できるルールのコレクションを収集します。
各サンプルは完成しているので、ディレクトリに直接コピーできます。 .cursor/rules/.
ルール: BEM およびカスタム プロパティを使用した CSS スタイル
---
description: Convenzioni CSS con BEM naming e custom properties
globs: ["**/*.css", "**/*.scss"]
alwaysApply: false
---
# CSS Conventions
## Naming: BEM (Block-Element-Modifier)
- Block: .card, .nav, .form
- Element: .card__title, .card__body, .nav__link
- Modifier: .card--featured, .nav__link--active
## Custom Properties (Design Tokens)
- Colori: --color-primary, --color-surface, --color-text
- Spacing: --space-xs (4px), --space-sm (8px), --space-md (16px)
- Typography: --font-heading, --font-body
- Breakpoints: --bp-mobile (768px), --bp-tablet (1024px)
## Regole
- Mobile-first: min-width per media queries
- No !important (mai, salvo utility override)
- No nesting > 3 livelli in SCSS
- Usa logical properties (margin-inline, padding-block)
- Preferisci Grid e Flexbox (no float)
ルール: Docker とコンテナ化
---
description: Regole per Dockerfile e docker-compose
globs: ["**/Dockerfile*", "**/docker-compose*.yml", "**/.dockerignore"]
alwaysApply: false
---
# Docker Conventions
## Dockerfile
- Multi-stage build SEMPRE (build + runtime)
- Immagine base: usa versioni specifiche (node:20-alpine, non node:latest)
- USER non-root: crea e usa un utente applicativo
- COPY selettivo: prima package*.json, poi npm ci, poi il resto
- .dockerignore: escludi node_modules, .git, test, docs
## Esempio Struttura
```dockerfile
# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build
# Stage 2: Runtime
FROM node:20-alpine AS runtime
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER app
EXPOSE 3000
CMD ["node", "dist/main.js"]
```
## docker-compose
- Usa version "3.8" o superiore
- Health checks per tutti i servizi
- Named volumes per dati persistenti
- Environment variables via .env file (non inline)
ルール: セキュリティと認証
---
description: Linee guida di sicurezza per autenticazione, autorizzazione e protezione dati
alwaysApply: false
---
# Security Guidelines
## Autenticazione
- JWT con refresh token rotation
- Access token: breve durata (15 min)
- Refresh token: durata media (7 giorni), one-time use
- Password: bcrypt con salt rounds >= 12
- NESSUN segreto hardcoded nel codice
## Autorizzazione
- RBAC (Role-Based Access Control) come base
- Verifica permessi a livello di controller E service
- Principio del minimo privilegio: concedi solo ciò che serve
- Audit log per operazioni sensibili
## Input Validation
- Valida TUTTI gli input a livello di boundary (controller)
- Sanitizza HTML per prevenire XSS
- Query parametrizzate SEMPRE (mai concatenazione SQL)
- Rate limiting su tutti gli endpoint pubblici
## Headers di Sicurezza
- Content-Security-Policy
- X-Content-Type-Options: nosniff
- Strict-Transport-Security
- X-Frame-Options: DENY
ルール: 言語間のエラー処理
---
description: Pattern di gestione errori consistente tra frontend e backend
alwaysApply: true
---
# Error Handling Pattern
## Principi
- Non ingoiare MAI un errore silenziosamente
- Log dettagliato server-side, messaggio user-friendly client-side
- Errori previsti: gestione esplicita con recovery
- Errori imprevisti: catch globale + logging + notifica
## Frontend (Angular/React)
- HttpClient: gestisci errori con catchError/try-catch
- Mostra toast/snackbar per errori utente
- Retry automatico per errori di rete (max 3 tentativi)
- Fallback UI per stati di errore (ErrorBoundary/error template)
## Backend (Node/Python)
- Custom exception classes per errori di dominio
- Global exception handler come middleware
- Structured logging: livello, timestamp, correlation-id, stack trace
- Non esporre MAI stack trace o dettagli interni al client
## Formato Standard
```
Log: [LEVEL] [TIMESTAMP] [CORRELATION-ID] [SERVICE] Message {context}
API: { "success": false, "error": { "code": "XXX", "message": "..." } }
```
ベストプラクティスとよくある間違い
避けるべき間違い
- 常に多すぎる: すべてのルールが Always の場合、コンテキストが無駄になります。 AI 変数の名前を変更するよう要求した場合でも、何千もの命令トークンが取得されます。
- ルールが曖昧すぎる: 「良いコードを書く」ことはAIにとって役に立ちません。具体的にしてください: 「最大 4 つのパラメータを持ち、それぞれ明示的な型を持つ関数」
- 矛盾したルール: あるルールが「クラスを使用する」と定めており、別のルールが「関数を使用する」と定めている場合、 AIは混乱します。ルールの一貫性を確認する
- 例が不足しています: 具体例のないルールは次のように遵守される 一貫性がない。必ず少なくとも 1 つの肯定的な例と 1 つの否定的な例を含めてください
- ルールを更新しないでください: ルールはプロジェクトとともに進化する必要があります。移住するなら Angular 17 から 19 へ、新しいパターンを反映するようにルールを更新します。
効果的な構成のためのチェックリスト
- プロジェクトの普遍的な規則に従って 1 ～ 3 の Always ルールを定義する
- プロジェクト内の言語/フレームワークごとに自動アタッチルールを作成する
- 専門知識 (データベース、展開、セキュリティ) のためのエージェント要求ルールを追加します。
- 反復的なテンプレートとワークフロー用の手動ルールを準備する
- すべてをコミットする
.cursor/rules/そしてそれをチームに伝えます - スプリントまたはリリースごとにルールを確認して更新する
- アメリカ合衆国
/Generate Cursor Rules新しいプロジェクトの出発点として
結論
Cursor のルール システムは、開発者の方法における質的飛躍を表しています。 AIと対話します。チャットボットに指示を与えるだけではありません。 チームの規約を AI が理解して適用できる形式に成文化する 自動的に.
4 つのルール タイプ (常に、自動接続、エージェント要求、手動) は、次のレベルを提供します。 現在、他の AI ツールが提供していない粒度です。ルールをアクティブ化する機能 ファイル タイプに基づいて条件付きで、エージェントが要求したターゲティングと組み合わせて、 プロジェクトの複雑さに応じて機能を低下させることなく拡張できる動的な知識システム AIのパフォーマンス。
最も重要なヒントは? 今すぐ始めましょう。簡単に始めましょう。 Always ルールを作成する プロジェクトの 10 個の最も重要な規則を使用して、 メイン言語を作成し、そこから反復処理します。初日から完璧なセットアップを行う必要はありません。 コードと同様に、ルールもプロジェクトとともに進化します。
シリーズの次の記事では、エージェントモード: タスクを委任する方法 機能全体のリファクタリングからテスト スイートの生成まで、Cursor の AI への複雑な連携 完了しました。この記事で設定したルールは、 エージェントが自分の仕事を構築します。
追加リソース
- カーソルの公式ドキュメント: docs.cursor.com/context/rules-for-ai
- リポジトリの例: github.com/cursor-rules-examples
- コミュニティ： forum.cursor.com でルールを共有および発見する
- 次の記事: エージェント モード - コマンドを使用してコードベースを編集する