Systematic Debugging
Debug by narrowing the problem, testing hypotheses, and proving root cause.
Core Rule
Do not stack random fixes.
Understand the failure shape first, then test one hypothesis at a time.
Workflow
- Define the symptom clearly.
- Reproduce it with the smallest possible test.
- Separate likely layers:
- input/data
- local script or command
- dependency/runtime
- network/external service
- site-specific anti-bot or auth
- Test one layer at a time.
- Confirm root cause with a minimal proof.
- Apply the smallest fix.
- Re-test the original symptom.
Useful Patterns
Compare working vs failing path
If one URL, command, or mode works and another fails, compare them directly.
Reduce scope
Use:
- smaller inputs
- a simpler command
- a known-good site/page
- a dry-run mode
- help/version commands
Distinguish tool failure from target failure
Examples:
- browser tool works, but website blocks automation
- API client works, but credentials are missing
- script syntax is fine, but runtime dependency is absent
Reporting Style
Explain in 3 parts:
- symptom
- confirmed cause
- fix or next blocker
Example:
- "툴 자체는 살아 있고, 쿠팡이 anti-bot으로 막는 게 원인이었어. 그래서 브리지 세션 재사용 쪽으로 우회했어."
Avoid
- trying many fixes without learning anything
- changing multiple variables at once
- declaring a root cause without proof
- saying something is broken when only one target site is blocking it
Practical Examples
Example: Site works on one page but not another
- Symptom: google.com opens, search results fail
- Likely split: tool works, target flow is blocked or challenged
Example: Skill installed but command missing
- Symptom: folder exists, CLI not found
- Likely split: skill docs installed, runtime dependency missing
Example: API tool returns auth error
- Symptom: command exists, request fails
- Likely split: client is healthy, credentials/config are missing or invalid