스킬 systematic-debugging

🔍

systematic-debugging

Name: systematic-debugging
Author: Cygnusfear

안전 ⚡ 스크립트 포함📁 파일 시스템 액세스

Apply systematic debugging for any bug

또한 다음에서 사용할 수 있습니다: Cycleaddict,DMJGilbert,Doyajin174,obra,Asmayaseen,DYAI2025,ChrisWiles,davila7,CodingCossack

Random fixes waste time and create new bugs. This skill provides a four-phase methodology to find root cause before attempting any fix. It prevents symptom-level patching and ensures lasting solutions.

지원: Claude Codex Code(CC)

📊 70 적절함

스킬 ZIP 다운로드

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

토글을 켜고 사용 시작

테스트해 보기

"systematic-debugging" 사용 중입니다. Test fails with 'Expected status completed but received pending'

예상 결과:

Phase 1 - Root Cause: Trace when status gets set versus when we check it
Phase 2 - Pattern: Find working tests that verify status updates
Phase 3 - Hypothesis: Perhaps async operation not awaited before assertion
Phase 4 - Implementation: Add waitFor condition to detect actual state change

"systematic-debugging" 사용 중입니다. File created in wrong directory during tests

예상 결과:

Phase 1 - Root Cause: Use find-polluter.sh to identify which test creates the file
Phase 2 - Pattern: Compare with tests that run clean
Phase 3 - Hypothesis: Empty path variable resolves to cwd
Phase 4 - Implementation: Add validation layer that refuses operation outside tmpdir

"systematic-debugging" 사용 중입니다. Environment secrets not reaching build layer

예상 결과:

Phase 1 - Evidence: Log env vars at each layer (workflow, build, signing)
Phase 2 - Pattern: Find where propagation breaks down
Phase 3 - Hypothesis: Layer transition strips environment
Phase 4 - Implementation: Add defense-in-depth check at each layer boundary

보안 감사

안전

v5 • 1/17/2026

This is a legitimate debugging methodology skill containing only documentation and code examples. All 138 static findings are FALSE POSITIVES. The flagged patterns are markdown documentation showing example debugging commands, shell variable expansion, environment checks, and standard filesystem operations - all used for legitimate debugging documentation purposes. No malicious code or intent present.

스캔된 파일

1,489

분석된 줄 수

발견 사항

총 감사 수

위험 요인

⚡ 스크립트 포함 (1)

find-polluter.sh:1-64

📁 파일 시스템 액세스 (1)

condition-based-waiting-example.ts:1-159

감사자: claude 감사 이력 보기 →

품질 점수

아키텍처

100

유지보수성

콘텐츠

커뮤니티

100

보안

사양 준수

만들 수 있는 것

Fix test failures properly

Stop adding sleep statements. Trace why tests fail at the source for permanent fixes.

Avoid symptom-level patching

Follow documented process instead of guessing fixes when encountering unexpected behavior.

Trace complex call stacks

Find where invalid data originates in multi-component systems with proven tracing techniques.

이 프롬프트를 사용해 보세요

Basic bug investigation

Load skills/debugging/systematic-debugging and help me investigate this test failure. The test expects X but received Y.

Multi-layer system debugging

Use the root cause tracing technique to trace this bug backward through the call chain. The error appears at line N.

Flaky test pattern

Apply the condition-based waiting pattern to replace arbitrary timeouts in this test file.

Prevent symptom fixing

Check my work against the systematic debugging process. Have I actually found the root cause?

모범 사례

Always complete Phase 1 (root cause) before proposing any fix, even under time pressure
Trace backward through the call chain to find where bad data originated, not where it manifests
Add validation at every layer data passes through to make bugs structurally impossible

피하기

Adding sleep statements instead of waiting for actual conditions
Fixing where the error appears instead of tracing to the source
Proposing multiple fixes at once to 'get more coverage'

자주 묻는 질문

Can I skip to the fix if the issue seems obvious?

No. The skill mandates Phase 1 completion before any fix. Simple bugs have root causes too. Systematic is faster than thrashing.

What if I do not understand the codebase well enough to trace root cause?

Say 'I do not understand X' rather than guessing. Ask for help or research more. The skill explicitly values honesty over pretense.

How do I handle production emergencies with this skill?

The skill acknowledges pressure but requires investigation first. Quick fixes mask issues that recur. Systematic debugging handles emergencies faster than symptom whack-a-mole.

When should I use condition-based waiting?

Replace arbitrary sleep or timeout calls with polling for the actual condition. This eliminates flaky tests that pass on fast machines but fail in CI.

What if three fixes have already failed?

Stop and question the architecture. Three failed fixes often indicate a structural problem, not a symptom to patch. Discuss with your human partner.

How is this different from test-driven development?

TDD writes tests before code. This skill investigates bugs when they occur. Both require understanding root cause but serve different phases of development.