커서 규칙이 적용되지 않는 이유는 보통 커서가 읽지 않아서가 아니라, 규칙 유형, 경로 범위, 트리거 메서드가 짝이 맞지 않기 때문입니다. 먼저, 규칙이 항상 (Always), 자동 첨부(Auto Attached), 에이전트 요청(Agent Requested), 또는 수동(Manual)인지 확인한 후, 파일이 '.cursor/rules'에 있는지 확인하세요.
먼저 네 가지 규칙 유형을 구분하라.
항상 도입되며, "답변하기 전에 기존 구현을 검토하라"와 같은 매우 짧은 글로벌 관례에 적합합니다. 자동 첨부는 프론트엔드, 백엔드, 테스트 디렉터리가 각각 규칙을 설정할 수 있도록 파일 경로와 일치해야 합니다. 에이전트 요청은 명확하게 설명되어야 에이전트가 전화할지 말지 결정할 수 있습니다. 매뉴얼은 대화 중에 규칙 이름을 명시적으로 언급해야 합니다.
많은 사람들이 이 규칙을 '매뉴얼'로 작성하며 자동으로 적용될 것이라고 생각하지만; 또는 자동 첨부(Auto Attached)라고 쓰는 것도 방법인데, 글롭스가 현재 파일과 일치하지 않아서 당연히 쓸모없어 보입니다.
경로 위치도 매우 중요합니다
프로젝트 규칙은 '.cursor/rules' 아래에 배치해야 합니다. 서브디렉터리는 또한 코드를 로컬적으로 제한하는 데 사용되는 자체 규칙 디렉터리를 가질 수도 있습니다. 예전 '.cursorrules'는 여전히 작동하지만, 범위와 트리거 방식을 제어하는 프로젝트 규칙으로 옮기는 것이 더 권장됩니다.
일반 문서 디렉터리에 규칙을 넣으면 커서가 자동으로 규칙으로 사용하지 않습니다. 규칙 시스템을 통해서든, 채팅에서 '@'가 있는 특정 파일을 참조하든 상관없습니다.
빠르게 확인하는 방법
새로운 짧은 항상 규칙을 만들어 상담원이 플랜에 답할 때 "어떤 파일을 읽을지"를 기재하도록 요구하세요. 그런 다음 새 대화를 열고 작은 업무를 맡기세요. 만약 이를 준수한다면, 규칙 체계가 정상임을 의미하며; 문제는 원래 규칙이 너무 길거나, 타입이 잘못됐거나, 경로가 맞지 않는다는 점입니다.
에이전트 사이드바에 활성 규칙이 표시되어 있는지 다시 확인해 보세요. 표시되지 않고, 기본적으로 트리거되지 않습니다.
규칙 쓰기는 너무 위시리스트처럼 보이지 않아요
"고품질 코드를 작성하고, 성능에 신경 쓰며, 안전하고 신뢰할 수 있어야 한다"는 원칙은 약합니다. 특정 동작으로 변경: "수정 전에 같은 이름을 가진 컴포넌트를 검색하세요; 새로운 인터페이스는 조드 스키마로 보완되어야 합니다. 두 번째 요청 패키지 세트를 만들지 마세요. "팀 내에서 규칙이 많이 개발될수록 적용이 더 쉬워집니다.
결론: 커서 규칙은 긴 파일에 억지로 넣어서는 안 되고, 트리거 방식으로 작성되어야 합니다. 먼저 올바른 타입을 선택한 뒤, 경로를 제어한 뒤, 마지막으로 작은 작업으로 검증하세요.
