Cursor でエージェントに振る舞いを寄せたいとき、指示は いくつかの経路に分かれます。ここでは「どこに書けばよいか」を決めるときの 手順と、各経路の 適用範囲のイメージを整理します。
先に決めることは二つだけ
- 適用範囲 … 誰の Cursor か、どのフォルダを開いているときか、常にか都度か。
- 置き場所 … その範囲に合う経路を選ぶ。
迷ったらこの順番にすると、User Rules に書きすぎたり、リポジトリごとの運用をグローバルに散らしたりしにくくなります。
置き場所の対応表（整理用の番号）
会話やメモで「1 は User」などと呼べるよう、次のように番号を振っておくとよいです。
| 番号 | 置き場所 | 適用のイメージ |
|---|---|---|
| 1 | Cursor 設定の User Rules | そのマシン・そのアカウントで、どのワークスペースでも共通に効かせたい短文向け |
| 2 | 設定の プロジェクト（ワークスペース）ルール | そのフォルダを開いているときだけ |
| 3 | リポジトリ直下の AGENTS.md | メタデータなしのシンプルな恒久指示。多くの場合 リポジトリのルートで開く前提で参照される |
| 4 | .cursor/rules/*.mdc | Git でチーム共有したいルール。YAML の alwaysApply や globs で載せ方を制御できる |
| 5 | チャットで @ によりファイルやルールを添える | そのスレッド・そのターンで強く効かせたいときの一時的な載せ方 |
公式のルール形式や UI の名称はバージョンで変わるため、詳細は Rules | Cursor Docs を正としてください。
よくある勘違い：Git 制約を「どの案件でも」としたい場合
エージェントに勝手に git commit させないなど、全プロジェクトで同じ制約にしたいなら、論理上は 1（User Rules） に短く書くのが筋です。
一方、4（.cursor/rules） にだけ書いた場合は、そのリポジトリをワークスペースのルートとして開いているときに効きやすく、別のリポジトリを開いただけでは自動では載りません。チームで このリポジトリ専用のルールとしてバージョン管理したい、という意図なら 4 は有効です。
プロジェクト限定の運用（質問の前にドキュメントを当てる、など）
単一のナレッジ用リポジトリや案件フォルダだけで効かせたい運用なら、2・3・4 の組み合わせが候補になります。
- 人間とエージェントの双方が読む正本の文章は
AGENTS.mdに寄せる - Cursor が毎回コンテキストに載せやすい短いルールは
.cursor/rulesの.mdcに要約し、alwaysApply: trueにする、といった住み分けがしやすいです。
ワークフローとして「質問には先にリポジトリ内を検索する」といった手順の長文は Markdown で別ファイルに置き、恒久ルールは .mdc や AGENTS.md 側に短く繰り返す形が扱いやすいです。
5 番（@）の位置づけ
5 はポリシーを恒久化する場所ではなく、今の会話でだけルールやファイルを強く参照させたいときの手段です。恒久のものは 1〜4 に残し、例外や実験を 5 で足す、と切り分けると整理しやすいです。
チャット由来の知見をどこに残すか（参考）
会話で整理した内容は、まず 社内・個人用のナレッジに短い要約として置き、型として育ったら 設計パターン用のディレクトリへ移す、といった二段にすると、ブログ記事のような外向きの文章と役割がぶつかりにくいです。外向きに書く場合は、プライベートリポジトリの URL を公開記事に載せないよう注意します（索引はナレッジ側だけで公開ブログへ一方向にリンクする、という運用も取りやすいです）。