집
구조화된 디버깅 세션 — 재현, 분리, 진단 및 수정하기. 오류 메시지나 스택 트레이스를 통해 시작할 수 있습니다. 예를 들어, “스테이징 환경에서는 작동하지만 프로덕션 환경에서는 안 됩니다”, “배포 후에 문제가 발생했습니다”, 또는 예상과 다른 동작이 나타나고 그 원인이 명확하지 않을 때 사용할 수 있습니다.
...모든 것을 확장하십시오디버깅에 대하여
디버깅 기술은 소프트웨어의 동작이 잘못되었거나, 명확하지 않거나, 역전되었을 때 사용자가 체계적인 디버깅 과정을 거칠 수 있도록 설계되었습니다. 이 기술은 오류 메시지, 스택 트레이스 또는 예상치 못한 동작이 즉시 진단할 수 없는 문제를 나타낼 때 유용합니다. 디버깅 과정을 명확한 단계로 구성함으로써, 사용자가 증상 관찰에서 근본 원인 파악에 이르기까지 체계적인 방법으로 진행할 수 있도록 돕습니다.
이 기술은 재현, 격리, 진단, 수정의 네 단계로 구성됩니다. 재현 단계에서는 예상되는 동작과 실제 동작을 명확히 하고, 문제를 재현할 수 있는 신뢰할 수 있는 단계들을 확립합니다. 격리 단계에서는 최근의 변경 사항(예: 배포, 설정 업데이트, 의존성 변경 등)을 검토하여 영향을 받은 구성 요소를 좁혀나가며, 로그와 오류 출력도 분석합니다. 진단 단계에서는 가설을 세우고 테스트하며, 실행 경로를 추적하고, 표면적인 증상이 아닌 근본 원인을 파악하는 데 중점을 둡니다. 마지막으로 수정 단계에서는 부작용을 고려하여 수정 사항을 제안하고, 역전을 방지하기 위한 예방 테스트를 권장합니다.
이 기술은 주로 개발자, DevOps 엔지니어, QA 테스터, 사이트 신뢰성 엔지니어 등이 생산 및 개발 문제를 해결할 때 유용합니다. 특히 배포 후의 문제, 환경에 따른 버그(예: 스테이징 환경과 프로덕션 환경의 차이), 최근 변경 사항 이후 발생한 설명할 수 없는 실패 등의 상황에서 매우 유용합니다. 체계적인 디버깅 구조를 따르면, 시행착오를 줄이고 문제 해결 과정의 일관성을 높일 수 있습니다.
자주 묻는 질문
이 디버깅 기술을 사용하려면 어떤 정보를 제공해야 하나요?
오류 메시지, 스택 트레이스, 예상치 못한 동작에 대한 설명, 문제를 재현하는 단계, 또는 최근의 변경 사항이나 로그와 같은 상황 정보를 제공해야 합니다. 제공하는 정보가 정확할수록 디버깅 과정이 더 효과적입니다.
이 기술을 사용하려면 외부 도구나 연결 기능이 필요한가요?
모니터링 시스템, 소스 제어, 프로젝트 추적 도구와 같은 연결 기능을 사용할 수 있지만, 제공된 정보, 로그, 상황 정보만으로도 충분히 사용할 수 있습니다.
이 기술이 적합하지 않은 문제 유형은 무엇인가요?
이 기술은 순전히 이론적인 질문이나 일반적인 설명에는 적합하지 않습니다. 구체적으로 관찰 가능한 잘못된 소프트웨어 동작을 진단하고 해결하는 데 중점을 두고 있습니다.
/debug
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Run a structured debugging session to find and fix issues systematically.
Usage
/debug $ARGUMENTSHow It Works
┌─────────────────────────────────────────────────────────────────┐│ DEBUG │├─────────────────────────────────────────────────────────────────┤│ Step 1: REPRODUCE ││ ✓ Understand the expected vs. actual behavior ││ ✓ Identify exact reproduction steps ││ ✓ Determine scope (when did it start? who is affected?) ││ ││ Step 2: ISOLATE ││ ✓ Narrow down the component, service, or code path ││ ✓ Check recent changes (deploys, config changes, dependencies) ││ ✓ Review logs and error messages ││ ││ Step 3: DIAGNOSE ││ ✓ Form hypotheses and test them ││ ✓ Trace the code path ││ ✓ Identify root cause (not just symptoms) ││ ││ Step 4: FIX ││ ✓ Propose a fix with explanation ││ ✓ Consider side effects and edge cases ││ ✓ Suggest tests to prevent regression │└─────────────────────────────────────────────────────────────────┘What I Need From You
Tell me about the problem. Any of these help:
- Error message or stack trace
- Steps to reproduce
- What changed recently
- Logs or screenshots
- Expected vs. actual behavior
Output
## Debug Report: [Issue Summary]### Reproduction- **Expected**: [What should happen]- **Actual**: [What happens instead]- **Steps**: [How to reproduce]### Root Cause[Explanation of why the bug occurs]### Fix[Code changes or configuration fixes needed]### Prevention- [Test to add]- [Guard to put in place]
If Connectors Available
If ~~monitoring is connected:
- Pull logs, error rates, and metrics around the time of the issue
- Show recent deploys and config changes that may correlate
If ~~source control is connected:
- Identify recent commits and PRs that touched affected code paths
- Check if the issue correlates with a specific change
If ~~project tracker is connected:
- Search for related bug reports or known issues
- Create a ticket for the fix once identified
Tips
- Share error messages exactly — Don't paraphrase. The exact text matters.
- Mention what changed — Recent deploys, dependency updates, and config changes are top suspects.
- Include context — "This works in staging but not prod" or "Only affects large payloads" narrows things fast.
debug 설치
스킬 파일을 다운로드하여 .claude/skills/ 디렉터리에 압축 해제하세요.
ZIP 다운로드저장소를 클론하고 스킬 파일을 프로젝트에 복사하세요.
git clone https://github.com/anthropics/knowledge-work-plugins/blob/main/engineering/skills/debug/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
복사
