systematic-debugging
체계적으로 디버그하고 근본 원인을 찾기
또한 다음에서 사용할 수 있습니다: Cygnusfear,Cycleaddict,DMJGilbert,Doyajin174,obra,Asmayaseen,DYAI2025,ChrisWiles,davila7
추측으로 고치는 일을 멈추고 실제 근본 원인을 찾으세요. 이 스킬은 증상 처방과 반복되는 실패 시도를 막는 체계적인 디버깅 방법론을 제공합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"systematic-debugging" 사용 중입니다. 통합 테스트가 잘못된 디렉터리에 파일을 만드는 이유를 디버그하는 데 도와주세요
예상 결과:
- 1단계: 조사 - 각 컴포넌트 경계에 진단 로그를 추가함
- git init에 빈 projectDir가 전달되는 것을 발견함
- tempDir가 초기화되기 전에 테스트 설정이 접근하고 있음을 추적함
- 2단계: 패턴 분석 - 유사한 테스트가 지연 초기화 패턴을 사용함을 발견함
- 조기 접근이 빈 문자열을 반환함을 식별함
- cwd로 빈 문자열이 전달되면 process.cwd()로 해석됨
- 3단계: 근본 원인 - 테스트 초기화가 beforeEach 이전에 tempDir에 접근하여 빈 문자열을 얻었고, 그 결과 소스 디렉터리에서 git init이 실행됨
- 4단계: 수정 - tempDir를 조기 접근 시 예외를 던지는 getter로 변경하고 4중 검증을 추가함; 이제 버그 재현 불가
"systematic-debugging" 사용 중입니다. 프로덕션에서는 API 호출이 간헐적으로 실패하지만 스테이징에서는 통과합니다
예상 결과:
- 1단계: 각 레이어에서 증거 수집
- CI 환경 변수, 빌드 구성, 배포 컨텍스트
- 2단계: 스테이징과 프로덕션 구성 비교
- 연결 풀 설정의 차이를 발견함
- 3단계: 가설 - 부하 시 연결 풀 고갈
- 4단계: 스테이징에서 먼저 풀 크기 증가 테스트
- 전체 프로덕션 배포 전에 가설 검증
보안 감사
안전All static findings are FALSE POSITIVES. The 'external_commands' patterns are markdown documentation examples, not executable code. The 'find-polluter.sh' script is a legitimate debugging tool. Environment variable access is for defensive test guards. No malicious patterns confirmed after semantic evaluation.
위험 요인
⚡ 스크립트 포함 (1)
📁 파일 시스템 액세스 (1)
⚙️ 외부 명령어 (1)
품질 점수
만들 수 있는 것
지속적인 테스트 실패 해결
테스트가 불규칙하게 실패하거나 여러 번의 수정 시도 이후에도 실패할 때, 임시 처방 대신 체계적 디버깅으로 실제 근본 원인을 찾습니다.
다중 컴포넌트 시스템 이슈 디버깅
각 컴포넌트 경계에 진단용 계측을 추가하여 CI 파이프라인, 빌드 시스템, 배포 체인을 통해 문제를 추적합니다.
테스트 오염 조사
find-polluter 스크립트를 사용해 다른 테스트에 영향을 주는 불필요한 파일이나 상태를 만들어내는 특정 테스트를 식별합니다.
이 프롬프트를 사용해 보세요
체계적 디버깅을 사용해 이 불안정한 테스트 실패를 조사해 주세요. 오류는 약 30% 확률로 무작위 발생합니다. 먼저 일관되게 재현하도록 도와주고, 그다음 근본 원인을 추적해 주세요.
우리 CI 파이프라인이 서명 단계에서만 가끔 실패합니다. 빌드와 테스트 단계는 통과합니다. 체계적 디버깅을 사용해 각 컴포넌트 경계에 진단용 계측을 추가하도록 도와주고, 문제가 어디에서 시작되는지 찾게 해 주세요.
테스트 실행 중 packages/core 디렉터리에 .git 디렉터리가 계속 생깁니다. find-polluter 스크립트로 어떤 테스트가 이를 만들고 있는지 식별하고, 왜 잘못된 디렉터리를 사용하고 있는지 근본 원인을 추적해 주세요.
이 데이터베이스 연결 문제를 이미 4번이나 고치려 했습니다. 매번 새로운 문제가 드러납니다. 이런 패턴을 계속하지 않도록 막고, 단순 버그가 아니라 근본적인 아키텍처 문제인지 질문하도록 도와주세요.
모범 사례
- 수정 시도 전에 항상 이슈를 일관되게 재현한다
- 호출 스택을 거꾸로 따라가 데이터 흐름의 원천을 찾는다
- 여러 레이어에 검증을 추가해 버그가 구조적으로 불가능하게 만든다
피하기
- 근본 원인을 이해하지 않은 채 빠른 수정만 적용하기
- 실제 조건을 기다리지 않고 임의의 타임아웃 사용하기
- 여러 번 실패한 뒤에도 기본 전제를 의심하지 않고 계속 수정하기