• 주석은 영어로만 작성
• OOP보다 함수형 프로그래밍을 선호
• 외부 시스템으로의 커넥터와 인터페이스에만 별도의 OOP 클래스를 사용
• 다른 모든 로직은 순수 함수로 작성 (명확한 입력/출력, 숨겨진 상태 변경 없음)
• 함수는 오직 반환 값만 수정해야 함 - 입력 매개변수, 전역 상태, 또는 명시적으로 반환되지 않은 데이터는 절대 수정 금지
• 최소한의, 집중된 변경을 할 것
• DRY, KISS, YAGNI 원칙을 따를 것
• 모든 언어에서 엄격한 타이핑(함수 반환, 변수)을 사용
• 가능한 경우 함수 호출 시 명명된 매개변수를 사용
• 중복 코드 금지; 코드를 작성하기 전에 일부 로직이 이미 작성되었는지 확인할 것
• 명확한 목적이 없는 불필요한 래퍼(wrapper) 함수는 피할 것
• 복잡한 데이터 구조를 다룰 때 제네릭 컬렉션보다 강력한 타입의 컬렉션을 선호
• 단순하지 않은 데이터 구조에 대해서는 적절한 타입 정의 생성을 고려
• 단순한 데이터 구조에는 네이티브 타입도 괜찮지만, 복잡한 구조에는 적절한 모델을 사용
• 가능한 경우 타입이 없는 변수와 제네릭 타입의 사용을 피하도록 노력
• 함수 정의에서 기본 매개변수 값을 절대 사용하지 말 것 - 모든 매개변수를 명시적으로 만들 것

• 항상 오류를 명시적으로 발생시키고, 절대 조용히 무시하지 말 것
• 코드의 논리적 부분에서 오류가 발생하면 즉시 발생시키고 실행을 계속하지 말 것
• 무엇이 잘못되었는지 명확하게 나타내는 특정 오류 유형을 사용
• 근본 원인을 숨기는 포괄적인 예외 처리기(catch-all exception handlers)를 피할 것
• 오류 메시지는 명확하고 실행 가능해야 함
• 오류를 발생시키기 전에 적절한 컨텍스트와 함께 로그를 남길 것

• 데이터 모델에는 TypedDict보다 Pydantic을 선호 (예: class ContactData(BaseModel): ...)
• Any와 @staticmethod를 피할 것
• 가능한 경우 requirements.txt보다 pyproject.toml을 사용
• 복잡한 구조의 경우, List[Dict[str, Any]]와 같은 제네릭 컬렉션을 피할 것
• 제네릭 Exception 대신 ValueError나 TypeError와 같은 특정 예외를 발생시킬 것
• 외부 시스템에 연결하는 클라이언트(예: NotionClient)에만 클래스를 사용
• 비즈니스 로직의 경우, 클라이언트를 첫 번째 매개변수로 받는 순수 함수를 사용: def change(notion_client: NotionClient, param1: str, param2: int) - Result:

• 복잡한 객체 형태에는 타입 별칭(type aliases)보다 인터페이스(interfaces)를 선호
• 복잡한 상태 관리를 위해 타입이 지정된 객체를 사용
• 설명적인 메시지와 함께 Error 객체를 사용: throw new Error('Specific message')
• 복잡한 타입 시나리오를 위해 판별된 유니온(discriminated unions)을 활용

• 전역이 아닌 가상 환경에 설치
• 일회성 설치가 아닌 프로젝트 설정 파일에 추가
• 이해를 위해 소스 코드 탐색을 사용
• 개별 패키지 설치보다 프로젝트 수준의 의존성 관리를 선호:
  • 좋음: pip install -r requirements.txt
  • 더 좋음: 최신 Python 패키징과 함께 pyproject.toml 사용
• 의존성을 추가할 때, 환경뿐만 아니라 적절한 프로젝트 설정 파일도 업데이트

• 날짜 관련 작업에는 date를 실행
• 여러 줄 텍스트를 위해 printf와 함께 GitHub CLI를 사용:

  git commit -m "$(printf "Title\n\n- Point 1\n- Point 2")"

• 항상 상호작용이 없는 git diff 명령어를 사용할 것: git --no-pager diff 또는 git diff | cat. git diff 또는 git diff --cached는 사용 금지.
• 항상 상호작용이 필요한 명령어보다 프롬프트를 피하기 위해 플래그, 환경 변수 또는 설정 파일을 사용하는, 매개변수가 있는 명령어를 선호

• 사용자는 기능 구현 계획을 생성하도록 요청할 수 있음
• 반드시 임시 디렉터리를 생성해야 함
• 반드시 임시 디렉터리 안에 기능 계획이 담긴 마크다운 파일을 생성해야 함
• 이 기능 계획 파일에는 다음 섹션이 포함되어야 함:
  1. 기능과 관련된 현재 상태 개요
  2. 기능의 최종 상태 개요
  3. 변경할 모든 파일 목록과 변경 내용에 대한 텍스트 설명 (코드가 아님)
  4. 2단계 마크다운 체크박스 스타일로 수행해야 할 모든 작업의 체크리스트
• 이 기능 계획 파일은 반드시 최소한이어야 하며, 기능과 관련된 가장 중요하고 최소한의 변경 사항만 포함해야 함. 모든 추가적인 변경 사항은 추가 섹션에 아이디어로 기술될 수 있지만, 사용자가 요청하지 않았다면 절대 구현해서는 안 됨

• .cursorrules 파일이 없으면 README.md를 읽을 것
• 작업하기 전에 프로젝트를 요약할 것

• 반드시 사용자가 별도로 지정하지 않는 한, 기존 코드 스타일과 패턴을 존중해야 함
• 반드시 현재 사용자 대화와 관련된 최소한의 변경 사항만 제안해야 함
• 반드시 문제를 해결하는 동안 가능한 한 적은 줄을 변경해야 함
• 반드시 현재 대화에서 사용자가 요청하는 것에만 집중해야 하며, 추가적인 개선은 금지
• 반드시 변경을 제안하기 전에 기존 코드베이스를 이해해야 함
• 반드시 변경을 제안하기 전에 관련 파일과 코드베이스를 읽는 것부터 시작해야 함

원문 : https://kirill-markin.com/articles/cursor-ide-rules-for-ai/?utm_source=chatgpt.com