debugging-and-error-recovery

debugging-and-error-recovery skill 개요

debugging-and-error-recovery skill은 추측 없이 실패 원인을 진단하는 체계적인 방식입니다. 실패하는 테스트, 깨진 빌드, 예상 밖의 런타임 동작, 잡음이 많은 로그, 변경 후에만 나타나는 회귀 문제를 겪는 개발자와 에이전트에게 가장 잘 맞습니다. Debugging을 위해 debugging-and-error-recovery skill이 필요하다면, 목표는 단순히 “에러를 고치는 것”이 아니라 증거를 보존하고, 문제를 재현하고, 추가 변경 전에 근본 원인을 찾는 데 있습니다.

이 skill은 어떤 상황에 쓰는가

이 skill은 실패는 분명하지만 원인은 불명확할 때 가장 유용합니다. 문제를 해결하지 않은 채 기능을 계속 배포하지 말라는, 일종의 stop-the-line 사고방식을 강하게 밀어줍니다. 그래서 테스트 중심 워크플로우, 장애 초기 대응, 그리고 작은 실수가 뒤이어 잘못된 실패를 연쇄적으로 만들어낼 수 있는 모든 저장소에 잘 맞습니다.

누가 설치해야 하는가

에이전트와 함께 코드를 자주 디버깅하면서, 즉흥적인 프롬프트가 아니라 반복 가능한 절차를 원한다면 debugging-and-error-recovery를 설치하는 것이 좋습니다. 특히 로그, 실패한 CI, 버그 리포트를 실제 수정 계획으로 넘겨야 하는 팀에 유용합니다.

무엇이 다른가

핵심 가치는 규율입니다. 먼저 재현하고, 증거를 보존하고, 순서대로 진단한 뒤, 수정 사항을 검증하고 재발을 막습니다. 첫 시도가 실패했을 때 에이전트가 어떻게 행동해야 하는지까지 알려주기 때문에, 단순히 “이 에러를 디버깅해줘”라는 일반 프롬프트보다 훨씬 실행에 바로 옮기기 좋습니다.

debugging-and-error-recovery skill 사용 방법

skill을 설치하고 불러오기

repo manager에서 debugging-and-error-recovery 설치 흐름을 사용한 뒤, 먼저 SKILL.md를 읽으세요. 이 저장소에는 보조 스크립트나 지원 폴더가 없어서, 이 skill은 의도적으로 가볍고 큰 툴체인보다 하나의 분명한 프로세스에 집중하도록 설계되어 있습니다.

막연한 버그를 쓸 수 있는 프롬프트로 바꾸기

debugging-and-error-recovery 사용은 처음에 세 가지를 주면 가장 잘 작동합니다: 증상, 증거, 경계 조건입니다. 예를 들어 “앱 좀 고쳐줘” 대신 “커밋 abc123 이후 user-auth.spec.ts에서 npm test가 실패합니다. 스택 트레이스, 기대 동작, 마지막으로 정상 작동한 실행 결과는 이렇습니다.”처럼 말하세요. 이렇게 하면 skill이 가설을 지어내기보다 재현과 분류에 필요한 맥락을 충분히 얻을 수 있습니다.

최상의 결과를 위한 추천 워크플로우

먼저 에이전트에게 코드를 바꾸기 전에 증거를 보존하고 문제를 재현하라고 요청하세요. 그다음 triage 단계를 순서대로 진행하게 합니다: 재현, 범위 축소, 최근 변경 사항 확인, 근본 원인 식별, 최소 수정, 검증. 이 워크플로우가 중요한 이유는 이 skill이 기능 확장이나 광범위한 리팩터링이 아니라 debugging-and-error-recovery에 최적화되어 있기 때문입니다.

먼저 읽어야 할 저장소 파일

이 repo에서 가장 먼저 읽을 파일은 SKILL.md입니다. 추가 참고 자료, 규칙, 스크립트가 없기 때문에 도입은 단순하지만, 동시에 프로젝트별 제약, 명령, 환경 정보는 프롬프트에 직접 넣어야 합니다.

debugging-and-error-recovery skill FAQ

일반적인 디버깅 프롬프트보다 나은가?

대체로 그렇습니다. 특히 일관성이 필요할 때는 더 그렇습니다. 일반 프롬프트도 수정을 요청할 수는 있지만, debugging-and-error-recovery는 중단, 증거 보존, 재현, 순차적 진단, 검증이라는 프로세스를 추가합니다. 덕분에 실제 문제를 가려버리기 쉬운 “빠른 수정” 행동을 줄일 수 있습니다.

언제 사용하지 말아야 하나?

추상적인 아키텍처 작업, 기능 기획, 또는 관찰 가능한 실패가 없는 작업에는 쓰지 마세요. 에러를 복구하는 상황이 아니라 설계 대안을 탐색하는 중이라면, debugging-and-error-recovery 가이드는 너무 제약이 많을 가능성이 큽니다.

초보자에게도 적합한가?

네, 절차가 명확하기 때문입니다. 초보자는 무엇을 수집해야 하고 어떤 순서로 조사해야 하는지 skill이 직접 알려준다는 점에서 이점을 얻습니다. 다만 초보자라도 막연한 도움 요청이 아니라 실제 증상을 제시해야 한다는 점은 같습니다.

일반적인 에이전트 워크플로우와 잘 맞는가?

네. 로그, 테스트, diff, 실행 가능한 환경에 접근할 수 있는 에이전트와 특히 잘 맞습니다. 반대로 증거를 살펴보거나 변경 사항을 검증할 수 없다면 덜 유용합니다. 복구 루프 자체가 피드백에 의존하기 때문입니다.

debugging-and-error-recovery skill 개선 방법

실패 입력을 더 구체적으로 제공하기

debugging-and-error-recovery 결과를 가장 잘 개선하는 방법은 정확한 실패 형태, 실패를 유발한 명령, 기대 결과, 실제 결과, 그리고 최근 변경 사항을 함께 넣는 것입니다. 예를 들어 “pnpm test가 zod를 업그레이드한 뒤 Linux에서만 실패합니다. diff와 스택 트레이스는 다음과 같습니다.”처럼 쓰면 검색 범위가 즉시 좁아집니다.

skill이 활용할 수 있는 맥락을 보존하기

로그, 스크린샷, 재현 절차, 환경 정보, 그리고 정상 동작하던 기준 상태를 포함하세요. 이 skill은 아무 설명도 없는 상태에서 시작하기보다 “이전”과 “이후”를 비교할 수 있을 때 더 잘 작동합니다. 버그가 간헐적이라면 그 점도 분명히 적고, 무엇 때문에 재발 가능성이 높아지는지도 설명하세요.

최소 수정과 검증을 요청하기

강한 debugging-and-error-recovery 사용 프롬프트는 가장 작고 안전한 수정과 함께 검증 계획이나 테스트 업데이트를 요청해야 합니다. 이렇게 하면 과도한 수정으로 흐르는 것을 막을 수 있고, 안정성을 중시하는 팀에 더 적합한 결과가 나옵니다.

첫 시도 이후에는 반복해서 다듬기

첫 번째 시도가 결론에 이르지 못했다면, 다음으로 좋은 증거를 넣어 프롬프트를 더 구체화하세요: 더 좁혀진 재현 단계, 더 정밀한 스택 트레이스, 또는 의심되는 정확한 파일 경로 등입니다. debugging-and-error-recovery skill은 같은 증상을 되풀이하는 것보다, 반복할수록 불확실성을 하나씩 없앨 때 가장 크게 좋아집니다.