カーソルルールは効果が出ません。通常はカーソルが読み取っていないからではなく、ルールタイプ、パス範囲、トリガーメソッドがペアになっていないためです。 まず、ルールが「常に」「自動アタッチド」「エージェントリクエスト」「手動」のいずれかかを確認し、ファイルが「.cursor/rules」にあるか確認してください。
まず4つのルールの種類を区別する
「必ず」は毎回持ち込まれ、「回答前に既存の実装を確認する」といった非常に短いグローバルな慣習に適しています。 Auto Attachはファイルパスと一致する必要があり、フロントエンド、バックエンド、テストディレクトリで別々にルールを設定するのに適しています。 エージェントリクエストは明確に説明し、エージェントが電話するかどうかを判断できるようにする必要があります。 マニュアルでは会話の中でルール名を明示的に言及する必要があります。
多くの人はこのルールをマニュアルとして書き、自動的に効力が出ると思い込んでいます。 あるいは「Auto Attached」と書くこともできますが、globsが現在のファイルと一致しないので、当然役に立たないように見えます。
経路の位置も非常に重要です
プロジェクトのルールは「.cursor/rules」の下に置くべきです。 サブディレクトリは、コードの一部をローカルに制約するために使われる独自のルールディレクトリを持つこともあります。 古い「.cursorrules」は引き続き動作しますが、スコープやトリガー方法を制御するプロジェクトルールに移行することを推奨します。
通常のドキュメントディレクトリにルールを入れても、カーソルは自動的にそれをルールとして使いません。 ルールシステムを通じて、チャット内で「@」のついた特定のファイルを参照するのも良いでしょう。
素早く確認する方法
新しい簡単な「いつも」ルールを作成し、担当者がプランに返信する際に「どのファイルを読むか」を記載するよう求めましょう。 そして新しい会話を開いて、小さなタスクを任せましょう。 もしそれに従うなら、そのルールシステムは正常であることを意味します。 問題は、元のルールが長すぎたり、タイプが間違っていたり、経過が合っていないことです。
エージェントサイドバーにアクティブルールが表示されているか再度確認してください。 表示はされません。基本的にトリガーされません。
ルールを書くのは、あまりウィッシュリストには見えない
「高品質なコードを書くこと、パフォーマンスに注意を払うこと、安全かつ信頼性を重視すること」というルールは弱いです。 具体的なアクションに変更:「変更前に同じ名前のコンポーネントを検索; 新しいインターフェースにはゾッドスキーマが補完されなければなりません。 2つ目のリクエストパッケージを作成しないでください。 「チーム内でルールが作られれば作るほど、効果を発揮しやすくなる。
結論:カーソルルールはトリガー形式で書くべきで、長いファイルに詰め込むべきではありません。 まず正しいタイプを選択し、次に経路を制御し、最後に小さなタスクで検証します。
