
커서 룰 에 입력하시면 됩니다. 원본 링크 합니다.
커서규칙_대화_지침
커서규칙_코드_스타일- 주석은 영어로만 작성
- 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
사용
- 의존성을 추가할 때, 환경뿐만 아니라 적절한 프로젝트 설정 파일도 업데이트
커서규칙_터미널_사용법
커서규칙_기획_실행_규칙- 사용자는 기능 구현 계획을 생성하도록 요청할 수 있음
- 반드시 임시 디렉터리를 생성해야 함
- 반드시 임시 디렉터리 안에 기능 계획이 담긴 마크다운 파일을 생성해야 함
- 이 기능 계획 파일에는 다음 섹션이 포함되어야 함:
- 기능과 관련된 현재 상태 개요
- 기능의 최종 상태 개요
- 변경할 모든 파일 목록과 변경 내용에 대한 텍스트 설명 (코드가 아님)
- 2단계 마크다운 체크박스 스타일로 수행해야 할 모든 작업의 체크리스트
- 이 기능 계획 파일은 반드시 최소한이어야 하며, 기능과 관련된 가장 중요하고 최소한의 변경 사항만 포함해야 함. 모든 추가적인 변경 사항은 추가 섹션에 아이디어로 기술될 수 있지만, 사용자가 요청하지 않았다면 절대 구현해서는 안 됨
커서규칙_리포지토리_관례.cursorrules
파일이 없으면 README.md
를 읽을 것- 작업하기 전에 프로젝트를 요약할 것
커서규칙_코드_변경- 반드시 사용자가 별도로 지정하지 않는 한, 기존 코드 스타일과 패턴을 존중해야 함
- 반드시 현재 사용자 대화와 관련된 최소한의 변경 사항만 제안해야 함
- 반드시 문제를 해결하는 동안 가능한 한 적은 줄을 변경해야 함
- 반드시 현재 대화에서 사용자가 요청하는 것에만 집중해야 하며, 추가적인 개선은 금지
- 반드시 변경을 제안하기 전에 기존 코드베이스를 이해해야 함
- 반드시 변경을 제안하기 전에 관련 파일과 코드베이스를 읽는 것부터 시작해야 함
원문 : https://kirill-markin.com/articles/cursor-ide-rules-for-ai/?utm_source=chatgpt.com
댓글목록
등록된 댓글이 없습니다.