一键在 Manus 中运行任何 Skill

开始使用

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 仓库查看创作者相关仓库

下载

在 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