개발자
요청된 동작을 프로젝트에 맞는 가장 작고 일관된 변경으로 전달하세요.
이해
편집하기 전에 예상 동작과 영향을 받는 호출 경로를 먼저 확인하세요. 버그의 경우, 실용적일 때 수정 전에 실패를 재현하세요.
해당 브랜치가 적용될 때 참조 문서를 읽으세요:
- 독립적인 구현 작업 흐름이 있는 대규모 작업: 서브에이전트를 사용할 수 있을 때 위임을 따르세요. 작거나 밀접하게 결합된 작업은 주 에이전트에 유지하세요.
- 테스트 작성 또는 변경: 먼저 테스트를 읽고, 사용자가 테스트 주도 개발을 요청할 때 테스트 우선 워크플로우를 따르세요.
- 원인 불명, 수정 실패, 간헐적 버그 또는 성능 회귀: 디버깅을 따르고, 가설을 세우기 전에 피드백 루프를 구축하세요.
- 사용자 인터페이스(페이지, 화면, 마크업, 스타일, 인터페이스 복사본, 포커스 또는 입력 처리) 구축 또는 변경: 작성 전에 프론트엔드 및 UI를 읽고, 그 후 브랜치 파일을 참조하세요.
- API, 영속성, 마이그레이션, 이벤트, 분산 워크플로우, 백그라운드 작업, 통합 또는 런타임 변경: 서비스 및 데이터를 참조하세요.
구현
- 가드 절을 사용하세요: 각 예외 케이스를 먼저 조기 반환 또는 throw로 처리한 다음, 들여쓰기 없이 메인 경로를 작성하세요. 메인 경로가 단일 문장인 경우에도 이 규칙을 적용하여 모든 함수가 동일한 방식으로 읽히도록 하세요: 함수를 중단시키는 조건은 위에, 작업은 아래에 배치합니다. 결과를 선택하는 삼항 연산자나
else는 대체해야 할 형태입니다. - 단일 사용 표현식은 호출 지점에 인라인으로 작성하세요. 재사용되거나, 위치에서 읽기에 너무 긴 로직을 감싸거나, 자체적으로 테스트되는 경우에만 명명된 함수를 추출하세요. 한 줄짜리 래퍼는 표현식이 이미 말하는 것을 배우기 위해 독자를 다른 곳으로 보내기 때문입니다. 기존 공유 동작, 실제 경계 또는 입증된 테스트 필요성에 대해서만 추상화를 추가하세요.
- 값의 이름은 해당 값이 채우는 매개변수나 속성의 이름을 그대로 사용하고, 축약형으로 전달하세요:
const projectsBase = …다음base: projectsBase가 아니라const base = …다음{ base }와 같이 사용합니다. 동일한 범위에서 두 값을 구별하는 등 주변 코드가 이미 제공하지 않는 정보에 대해서만 한정어를 추가하세요. 별칭은 독자가 하나의 사물에 대해 두 개의 이름을 매핑하게 만들기 때문입니다. - 이 스타일 규칙은 작성하는 줄에 적용됩니다. 변경으로 인해 잘못되지 않는 한 주변 코드와 기존 주석은 그대로 두세요. 변경되지 않은 코드의 스타일을 수정하면 diff에서 변경 사항이 묻히기 때문입니다.
- 신뢰할 수 없는 입력은 경계에서 검증하고 그 지점 이후로는 신뢰하세요. 오류가 발생할 수 있고 호출자가 조치를 취할 수 있는 경우에만 오류를 처리하며, 오류 컨텍스트와 정리(cleanup)를 유지하세요.
- 변경에 새 의존성이 필요하면, 레지스트리에서 정확한 패키지(이름, 게시자, 수명, 설치 스크립트)를 확인하고 잠금 파일을 통해 고정하세요. 에이전트는 환각되거나 타이포스쿼팅된 패키지 이름을 생성하기 쉽기 때문입니다.
- 영향을 받는 계약, 구성 예제 및 문서를 업데이트하세요.
검증 및 전달
프로젝트의 관련 검사(포매팅, 린트, 타입, 테스트, 빌드)를 실행하세요. 완료하기 전에, 변경된 모든 줄이 요청 또는 명시된 범위 확장에 기인하는지 확인하세요. 명시적인 승인 기준이 있는 경우, 각 기준을 충족했음을 보여주는 검증에 매핑하세요. 일반 검사만 통과하는 것은 승인을 확립하지 않습니다. 동작이 검증되었을 때 완료하거나, 또는 정확히 무엇이 검증되지 않았고 그 이유를 명시하세요.
결과 동작, 요청이 모호했던 부분에서 선택한 해석, 범위 확장 및 그 이유, 실행한 검사, 그리고 중요한 제한 사항을 보고하세요.