Claude Code 한국어 프롬프트 30개

{file}의 버그를 최소한의 실패하는 테스트로 재현한 다음 고쳐줘. 관련 없는 코드는 건드리지 마. 수정 전 실패하는 테스트와 수정 후 통과하는 테스트를 모두 보여줘.

언제: 회귀 위험이 큰 비자명한 버그에 적합.

스택 트레이스: {paste}. 근본 원인 파일과 라인을 찾고, 무엇이 잘못됐는지 2문장으로 설명한 후, 실패하는 테스트를 통과시키는 가장 작은 수정을 제안해. 검증할 수 없는 원인은 추측하지 마.

언제: 프로덕션 크래시 조사, 특히 익숙하지 않은 코드베이스.

지난 10개 커밋 사이에 {feature}가 깨졌어. `git log -p HEAD~10..HEAD`를 읽고 가능성 순으로 가설 3개를 제안한 다음, 검증 명령어 `{cmd}`로 git bisect를 실행해.

언제: 최근 발생한 회귀 버그 — 수동 bisect보다 빠르게 좁힘.

{function} 주변에 동작에 영향을 주는 변수를 캡처하는 임시 구조화된 로깅을 추가해. 테스트를 10번 실행해. 간헐적으로 실패하면 타이밍/race condition을 식별해. 작업이 끝나면 로깅을 제거해.

언제: flaky 테스트, race condition, 타이밍에 민감한 버그.

`bun run typecheck`을 실행하고 {dir}의 모든 에러를 고쳐. `any`나 `@ts-ignore`는 사용하지 마. 타입을 넓혀야 한다면 주석으로 이유를 설명해.

언제: TypeScript 업그레이드 후 또는 strict mode 마이그레이션 후.

{large_function}을 더 작은 순수 함수들로 추출해. 각 새 함수는 하나의 책임만 가져. 관찰 가능한 동작은 변경하지 마. 추출할 때마다 기존 테스트를 실행해서 확인해.

언제: 읽기 어렵거나 격리해서 테스트하기 힘든 긴 함수.

{dir}에서 가장 많이 중복되는 패턴 3개를 찾아 (grep + 수동 읽기 사용). 각각에 대해 추상화를 제안한 다음, 가장 leverage가 큰 것 하나를 구현해. before/after 라인 수를 보여줘.

언제: 코드베이스가 빠르게 자라면서 복붙이 누적된 경우.

{dir}에서 caller가 1개뿐인 추상화를 찾아. 각각에 대해 결정해: 유지, 인라인, 삭제. 의미를 잃지 않는 삭제/인라인을 적용해.

언제: 이른 추상화가 오히려 더 어렵게 만든 코드베이스.

{file}에서 I/O를 받거나 전역 상태를 변경하지만 순수 함수가 될 수 있는 함수를 식별해. 의존성을 인자로 받도록 리팩토링해. caller를 깨뜨리지 마.

언제: 숨겨진 의존성으로 테스트하기 힘든 코드.

{module}의 public API를 감사해. 각 export에 대해 결정해: public 유지, internal로 변경(`_` prefix 또는 unexport), 별도 internal 모듈로 이동. 변경사항을 적용해.

언제: public surface가 누수되어 발전시키기 힘든 모듈.

커버리지를 실행해. 80% 미만인 파일에 대해 커버되지 않은 분기를 타겟으로 하는 테스트를 작성해. 기존 테스트 프레임워크와 패턴을 사용해. 구현 디테일이 아닌 동작을 테스트해.

언제: 릴리스 전 커버리지 push, 또는 기능 출시 후.

{function}에 대한 property-based 테스트를 fast-check (또는 Python의 hypothesis)로 작성해. 항상 성립해야 하는 속성 3개를 식별 (멱등성, 교환법칙, 경계), 그 다음 1000개의 랜덤 입력을 생성해.

언제: 예제 기반 테스트가 놓치는 엣지 케이스가 있는 순수 함수.

{component}에 대한 스냅샷 테스트를 추가해, 의미적 출력만 캡처 (공백 제거된 렌더링 HTML), 스타일이나 구현이 아닌. 스냅샷이 100라인을 넘으면 거부 — 먼저 리팩토링해.

언제: 픽셀 단위 출력보다 구조가 중요한 UI 컴포넌트.

{module}에 대한 유닛 테스트 5개를 전체 public API를 행사하는 통합 테스트 1개로 교체해. 목표: 같은 커버리지, 리팩토링 시 깨지지 않음.

언제: 실제 버그를 잡지 못하면서 리팩토링마다 깨지는 테스트 스위트.

{function}의 실패 케이스에 대한 테스트를 추가해: 잘못된 입력, 네트워크 실패, 타임아웃, 부분 결과. 각각에 대해 정확한 에러 타입/코드를 단언해, 단순히 'throws'가 아니라.

언제: 외부 의존성 (DB, API, 파일시스템)을 다루는 코드.

{feature}를 추가하고 싶어. {dir}의 관련 파일을 읽고 trade-off (복잡도, 성능, 미래 유연성)와 함께 2-3개의 구현 접근법을 제안해. 아직 코드를 작성하지 마 — 내가 선택할 때까지 기다려.

언제: 비자명한 모든 기능 전. 다시 작성하는 것보다 싸다.

{dir}의 import graph를 매핑해 (`import` 구문에 ripgrep 사용). 사이클을 찾아. 각 사이클에 대해 어떻게 깨뜨릴지 제안해 (공유 모듈 추출, 의존성 역전, 한 방향 삭제).

언제: '어디에 둘까?'가 불명확한 코드베이스.

{module}의 계약을 TypeScript interface (또는 Python protocol)로 정의해. caller에 대해 만드는 모든 가정과 caller에게 보장하는 모든 것을 나열해. 계약을 깨뜨리는 구현을 업데이트해.

언제: 여러 팀이나 서비스가 의존하는 모듈.

{new_thing}을 설계하기 전에 이 5개 파일을 읽어: {list}. 패턴을 요약해. 그 다음 이 코드베이스에서 이미 작동하는 것과 일관된 설계를 제안해 — 다른 곳의 'best practice'가 아니라.

언제: 코드베이스에 합류하거나 비자명한 변경을 제안할 때.

{feature}를 추가하기 전에 추정해: (a) 변경되는 라인 수, (b) 업데이트할 테스트 표면, (c) 작성할 문서, (d) 유사한 과거 변경을 기반으로 다음 30일 동안 발생할 가능성 있는 후속 버그. 어떤 숫자라도 놀랍다면 더 작은 범위를 제안해.

언제: 스프린트 추정에 헌신하기 전에 작업 사이징.

{dir}을 읽어. 다음을 다루는 README를 생성해: 이게 무엇을 하는지, 왜 존재하는지, 로컬에서 어떻게 실행하는지, 흔한 함정, 진입점이 어디인지. 마케팅 문구는 빼고.

언제: 다른 사람을 ramp up시켜야 하는 인계받은 또는 미문서화 코드베이스.

{file}에 코드에서 명백하지 않은 WHY가 있는 곳에만 주석을 추가해. '카운터 증가' 같은 주석은 달지 마. '이 서버는 5분 캐시하므로 여기서 다시 fetch한다' 같은 주석을 달아.

언제: 올바르지만 작성자 외에는 미스터리한 코드.

{API}를 버전 X에서 Y로 변경했어. {tag1}과 {tag2} 사이의 diff를 읽고 마이그레이션 가이드를 작성해: 각 breaking change, before/after 코드, 변경 이유.

언제: 메이저 버전을 릴리스하고 지원 부담을 줄이고 싶을 때.

{service}에 합류하는 신규 엔지니어를 위한 '첫 30분' 가이드를 작성해. 환경이 작동하는지 확인하기 위해 완료해야 하는 작업, 각 단계의 예상 출력 포함.

언제: 반복되는 'setup 도와주세요' 슬랙 메시지.

{file}의 TypeScript 타입에서 API 문서를 생성해. 각 함수의 목적, 파라미터, 반환값, 에러 케이스, 그리고 사용 예제 하나를 포함해.

언제: 외부 문서 없는 라이브러리 또는 공유 모듈.

{dir}에서 사용자 입력을 받는 코드 경로를 스캔해. 각각에 대해 검증/sanitization을 확인해. 입력을 신뢰하거나 SQL, shell, eval, 파일시스템 작업에 직접 전달하는 것을 표시해.

언제: 출시 전 보안 패스 또는 보안 권고 후.

실수로 커밋된 비밀 (API 키, JWT, private key)을 위해 repo를 스캔해. 정규식 패턴을 사용해. 비밀 값을 출력하지 않고 발견 사항을 나열해. rotation 단계를 권장해.

언제: 분기별 또는 repo를 오픈소스화하기 전.

`bun audit` (또는 `npm audit`/`pip-audit`)을 실행해. 각 취약점을 분류: false positive (이유 포함), 낮은 우선순위, 지금 수정. '지금 수정'에 대한 reproduction과 함께 이슈를 열어.

언제: 주간 유지보수 또는 CVE 발표 후.

{dir}의 모든 API 엔드포인트와 각각에 적용된 auth 검사를 나열해. auth가 없거나, 약한 auth (예: 사용자가 제공한 user_id), 또는 불명확한 auth가 있는 엔드포인트를 표시해.

언제: 새 엔드포인트를 도입한 후 또는 보안 리뷰 전.

{module}의 접근 패턴을 감사해. 각 role/permission에 대해 무엇을 할 수 있고 읽을 수 있는지 나열해. 필요 이상으로 하는 'admin' role 또는 검사를 우회하는 non-admin 경로를 표시해.

언제: 메이저 릴리스 전 멀티테넌트 또는 role 기반 시스템.