원클릭으로 Manus에서 모든 스킬 실행

시작하기

systematic-debugging

스타2

포크0

업데이트2026년 2월 8일 12:30

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

maslennikov-ig

maslennikov-ig/MC-2

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Systematic Debugging

Core principle: ALWAYS find root cause before attempting fixes.

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

The Four Phases

Phase 1: Root Cause Investigation

BEFORE attempting ANY fix:

Read Error Messages Carefully - Stack traces, line numbers, error codes
Reproduce Consistently - Exact steps, every time?
Check Recent Changes - Git diff, new deps, config changes
Gather Evidence in Multi-Component Systems - Log data at each component boundary, run once, analyze WHERE it breaks

Phase 2: Pattern Analysis

Find Working Examples - Similar working code in same codebase
Compare Against References - Read reference implementation COMPLETELY
Identify Differences - List every difference, however small

Phase 3: Hypothesis and Testing

Form Single Hypothesis - "I think X is the root cause because Y"
Test Minimally - SMALLEST possible change, one variable at a time
Verify Before Continuing - Didn't work? Form NEW hypothesis, don't stack fixes

Phase 4: Implementation

Create Failing Test Case - MUST have before fixing
Implement Single Fix - ONE change at a time, no "while I'm here" improvements
Verify Fix - Test passes? No other tests broken?
If 3+ Fixes Failed - STOP. Question the architecture, discuss with human partner

Red Flags - STOP and Return to Phase 1

"Quick fix for now, investigate later"
"Just try changing X and see if it works"
"I don't fully understand but this might work"
Proposing solutions before tracing data flow
Each fix reveals new problem in different place

Quick Reference

Phase	Key Activity	Success Criteria
1. Root Cause	Read errors, reproduce, check changes	Understand WHAT and WHY
2. Pattern	Find working examples, compare	Identify differences
3. Hypothesis	Form theory, test minimally	Confirmed or new hypothesis
4. Implementation	Create test, fix, verify	Bug resolved, tests pass

이 저장소의 다른 Skills

같은 저장소

process-issues

maslennikov-ig/MC-2

Process GitHub Issues - fetch open issues, read comments, analyze suggestions, find similar, create Beads tasks, propose fix plan

2026-06-122

process-logs

maslennikov-ig/MC-2

Process error logs from admin panel - fetch new errors, analyze, create tasks, fix, and mark resolved. Checks Axiom/Pino if DB entries are filtered.

2026-06-122

hallmark

maslennikov-ig/MC-2

Anti-AI-slop design skill for greenfield pages, audits, redesigns, and design extraction from URLs or screenshots. Use when the user asks to build a new app or landing page, wants to redesign something, invokes Hallmark by name, or uses audit/redesign/study.

2026-05-262

job-description

maslennikov-ig/MC-2

Generate comprehensive role guides (job descriptions on steroids) for any position. Multi-phase workflow with web research, adaptive questions, 26 content blocks based on Netflix/Amazon/Toyota/Spotify/Bridgewater best practices, and course brief generation. Use /job-description to create a role guide.

2026-03-222

cleanup-health-inline

maslennikov-ig/MC-2

Inline orchestration workflow for dead code detection and removal with Beads integration. Provides step-by-step phases for dead-code-hunter detection, priority-based cleanup with dead-code-remover, and verification cycles.

2026-02-082

deps-health-inline

maslennikov-ig/MC-2

Inline orchestration workflow for dependency audit and updates with Beads integration. Provides step-by-step phases for dependency-auditor detection, priority-based updates with dependency-updater, and verification cycles.

2026-02-082

name	systematic-debugging
description	Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Systematic Debugging

Core principle: ALWAYS find root cause before attempting fixes.

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

The Four Phases

Phase 1: Root Cause Investigation

BEFORE attempting ANY fix:

Read Error Messages Carefully - Stack traces, line numbers, error codes
Reproduce Consistently - Exact steps, every time?
Check Recent Changes - Git diff, new deps, config changes
Gather Evidence in Multi-Component Systems - Log data at each component boundary, run once, analyze WHERE it breaks

Phase 2: Pattern Analysis

Find Working Examples - Similar working code in same codebase
Compare Against References - Read reference implementation COMPLETELY
Identify Differences - List every difference, however small

Phase 3: Hypothesis and Testing

Form Single Hypothesis - "I think X is the root cause because Y"
Test Minimally - SMALLEST possible change, one variable at a time
Verify Before Continuing - Didn't work? Form NEW hypothesis, don't stack fixes

Phase 4: Implementation

Create Failing Test Case - MUST have before fixing
Implement Single Fix - ONE change at a time, no "while I'm here" improvements
Verify Fix - Test passes? No other tests broken?
If 3+ Fixes Failed - STOP. Question the architecture, discuss with human partner

Red Flags - STOP and Return to Phase 1

"Quick fix for now, investigate later"
"Just try changing X and see if it works"
"I don't fully understand but this might work"
Proposing solutions before tracing data flow
Each fix reveals new problem in different place

Quick Reference

Phase	Key Activity	Success Criteria
1. Root Cause	Read errors, reproduce, check changes	Understand WHAT and WHY
2. Pattern	Find working examples, compare	Identify differences
3. Hypothesis	Form theory, test minimally	Confirmed or new hypothesis
4. Implementation	Create test, fix, verify	Bug resolved, tests pass