Agent skill

Systematic Debugging

by MadAppGang in MadAppGang/claude-code

A skill your agent uses when debugging failures, errors, or unexpected behavior.

MITAuto-check passedDevelopment

Install Systematic Debugging

skills CLI
$ npx skills add MadAppGang/claude-code --skill systematic-debugging -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install MadAppGang/claude-code systematic-debugging --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/MadAppGang/claude-code.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dev/skills/discipline/systematic-debugging .claude/skills/systematic-debugging && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
systematic-debugging
GitHub stars
283
Token cost
~4.6k tokens
SKILL.md length
1,004 words
Files
1
Skills in repo
69
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when debugging failures, errors, or unexpected behavior.

  • Works in 8 steps: Root Cause vs. Symptom → Data Flow Tracing → Hypothesis-Driven Debugging → …
  • Debugging failures
  • SKILL.md covers When to Use, Red Flags (Violation Indicators), Key Concepts and 4-Phase Debugging Process, plus 4 more sections
  • Calls git; needs API_KEY

What it does

Systematic Debugging is an agent skill from MadAppGang/claude-code. Use when debugging failures, errors, or unexpected behavior. Covers root cause investigation, data flow tracing, hypothesis-driven debugging, and fix verification to prevent trial-and-error approaches.

Its SKILL.md is about 4.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Debugging and Root cause analysis. The repository describes itself as: claude code plugins marketplace. The licence is MIT.

When your agent uses it

  • Debugging failures
  • Unexpected behavior

Example prompts

  • “/systematic-debugging”

Requirements

  • Python 3
  • A credential in API_KEY

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Root Cause vs. Symptom
  2. Data Flow Tracing
  3. Hypothesis-Driven Debugging
  4. Fix Verification
  5. TRACE DATA FLOW
  6. IDENTIFY DIVERGENCE
  7. HYPOTHESIZE ROOT CAUSE
  8. VERIFY FIX

What it can do on your machine

Read from SKILL.md and the folder at commit 6097ad4. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • API_KEY

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Systematic Debugging loads about 4.6k tokens when it runs. Until then it costs about 56 tokens; SKILL.md has 1,004 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~56
When it runs · the whole SKILL.md, loaded when a task matches
~4.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from MadAppGang/claude-code at commit 6097ad4, republished under its MIT licence (© MadAppGang). 1,004 words, ~4,555 tokens.

Download SKILL.mdSave it as .claude/skills/systematic-debugging/SKILL.md (or your agent's skills folder).
name
systematic-debugging
description
Use when debugging failures, errors, or unexpected behavior. Covers root cause investigation, data flow tracing, hypothesis-driven debugging, and fix verification to prevent trial-and-error approaches.
keywords
debugging, root-cause, trace-data-flow, divergence, hypothesis, fix-verification, stack-trace, error-analysis, profiling, logging, TypeError, null-undefined…
created
2026-01-20
updated
2026-01-20
plugin
dev
type
discipline
difficulty
beginner

Systematic Debugging

Iron Law: "NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST"

When to Use

Use this skill when:

  • A test fails and you need to understand why
  • An error is thrown and you need to find the cause
  • A feature behaves unexpectedly
  • Performance degrades and you need to identify bottlenecks
  • Data corruption occurs and you need to trace the source
  • A bug reappears after "fixing" it

Red Flags (Violation Indicators)

Detect these patterns that indicate skipping root cause investigation:

  • Fix without understanding - "I'll just add a null check" (why is it null?)
  • Skip to solution - "Let me try wrapping this in setTimeout" (why does timing matter?)
  • Restart tools - "Let me restart the dev server" (what state is corrupted?)
  • Clear cache - "Let me clear the cache" (what cache entry is stale?)
  • Change multiple things - "Let me update these 3 files" (which one fixes it?)
  • Shouldn't cause problem - "This change shouldn't affect that" (but it does, why?)
  • Assume cause - "Must be a race condition" (what evidence supports this?)

Key Concepts

1. Root Cause vs. Symptom

Symptom: What you observe (test fails, error thrown, wrong output) Root Cause: Why it happens (null value, wrong condition, missing await)

Example:

Symptom: "TypeError: Cannot read property 'name' of undefined"
Root Cause: API returns null when user not found, but code expects object

Bad approach: Add user?.name (fixes symptom, not cause) Good approach: Add validation if (!user) throw new NotFoundError() (fixes cause)

2. Data Flow Tracing

Principle: Follow data from source to error point

Steps:

  1. Identify error location (stack trace line number)
  2. Identify data involved (variable name, object property)
  3. Trace backwards: Where does this data come from?
  4. Find divergence: Where does actual differ from expected?

Example:

Error: "Expected 'active' but got 'inactive'"
Location: user.test.ts:42 - expect(user.status).toBe('active')
Data: user.status = 'inactive'
Trace: user.status ← updateUser() ← API response ← database
Divergence: Database has status='inactive' (expected 'active')
Root Cause: Test setup didn't create user with active status
3. Hypothesis-Driven Debugging

Principle: Form hypothesis, test with evidence, refine

Process:

  1. Observe: What is the symptom? (error message, wrong output)
  2. Hypothesize: What could cause this? (list 2-3 possibilities)
  3. Predict: If hypothesis is true, what else should I see?
  4. Test: Add logging, check state, run minimal reproduction
  5. Conclude: Does evidence support hypothesis? If no, try next hypothesis

Example:

Symptom: API request times out after 30s
Hypothesis 1: Database query is slow
  Prediction: Should see long query time in logs
  Test: Add query timing logs
  Result: Queries complete in <100ms ✗ Hypothesis rejected

Hypothesis 2: Network connection is hanging
  Prediction: Should see connection delay, not query delay
  Test: Add request timing logs (connect time vs. query time)
  Result: Connection takes 31s, query never runs ✓ Hypothesis confirmed

Root Cause: Firewall blocks connection, causing timeout
4. Fix Verification

Principle: Verify fix addresses root cause, not just symptom

Checklist:

  • Test that was failing now passes
  • Test passes for the reason you expect (not coincidence)
  • Test fails if you revert the fix (confirms fix is necessary)
  • Related tests still pass (no regressions)
  • Root cause is addressed in fix (not just symptom)

4-Phase Debugging Process

Phase 1: TRACE DATA FLOW

Objective: Identify where actual diverges from expected

Steps:

  1. Read error message (what failed?)
  2. Read stack trace (where failed?)
  3. Identify data involved (what value is wrong?)
  4. Trace backwards from error to source
  5. Log intermediate values to find divergence point

Example (TypeScript):

typescript
// Error: "Expected user email, got undefined"
// Stack trace: user-service.ts:42

// Phase 1: Trace data flow
console.log('1. API response:', response);           // { data: { user: {...} } }
console.log('2. Extracted user:', response.data);     // { user: {...} }
console.log('3. User object:', response.data.user);   // { id: 1, name: 'Alice' }
console.log('4. Email field:', response.data.user.email); // undefined

// Divergence found: response.data.user has no email field
Phase 2: IDENTIFY DIVERGENCE

Objective: Determine why actual differs from expected

Questions:

  • What is the expected value? (from spec, test, documentation)
  • What is the actual value? (from logs, debugger, state inspection)
  • Where does the divergence occur? (which function, which line)
  • What changed recently? (git diff, recent commits)

Example (Python):

python
# Expected: parse_csv() returns list of dicts with 'email' key
# Actual: parse_csv() returns list of dicts without 'email' key

# Check input CSV file
with open('users.csv') as f:
    print(f.readline())  # id,name,phone  ← Missing 'email' column!

# Divergence: CSV file format changed, missing 'email' column
Phase 3: HYPOTHESIZE ROOT CAUSE

Objective: Form testable hypothesis about why divergence occurred

Hypothesis Template:

"I believe [divergence] occurs because [root cause].
If this is true, I should see [evidence].
I can test this by [action]."

Example (Go):

go
// Divergence: user.Email is empty string when fetched from cache

// Hypothesis 1: Cache serialization drops empty fields
// Evidence: Other empty fields (phone, address) also missing
// Test: Check cached JSON structure
// Result: {"id":1,"name":"Alice"} ← Empty fields missing ✓

// Root Cause: JSON serialization omits empty fields (omitempty tag)
Phase 4: VERIFY FIX

Objective: Confirm fix addresses root cause

Verification Steps:

  1. Write test that reproduces the bug (fails before fix)
  2. Apply fix
  3. Run test (should pass)
  4. Explain why fix works (addresses root cause)
  5. Run regression tests (no side effects)

Example (TypeScript):

typescript
// Root Cause: JSON serialization omits fields with undefined values

// Before fix:
JSON.stringify({ id: 1, email: undefined }) // {"id":1}

// Fix: Filter out undefined before serialization
const filtered = Object.fromEntries(
  Object.entries(user).filter(([_, v]) => v !== undefined)
);

// Verification:
expect(filtered).toEqual({ id: 1 }); // ✓ Correct behavior
expect(JSON.stringify(filtered)).toBe('{"id":1}'); // ✓ Serialized correctly

Debugging Strategies by Problem Type

Test Fails

Strategy: Identify assertion, trace data, find divergence

typescript
// Test fails: expect(result).toBe(5)
test('calculates total', () => {
  const result = calculateTotal([1, 2, 2]);
  console.log('Input:', [1, 2, 2]);        // Input data
  console.log('Expected:', 5);              // Expected result
  console.log('Actual:', result);           // Actual result (6)
  console.log('Divergence:', result - 5);   // Difference (1)
  expect(result).toBe(5);
});

// Trace: calculateTotal() sums array incorrectly
// Root Cause: Off-by-one error in loop (includes index 0 twice)
Performance Slow

Strategy: Profile execution, identify bottleneck

python
import time

def slow_function():
    start = time.time()

    # Phase 1: Identify slow section
    data = fetch_data()  # 0.1s
    print(f"Fetch: {time.time() - start:.2f}s")

    processed = process_data(data)  # 5.2s ← Bottleneck!
    print(f"Process: {time.time() - start:.2f}s")

    save_data(processed)  # 0.05s
    print(f"Save: {time.time() - start:.2f}s")

# Root Cause: process_data() has O(n²) algorithm
Data Corruption

Strategy: Trace data mutations, find unexpected write

go
// Symptom: User email changes unexpectedly

// Phase 1: Add logging to all mutation points
func UpdateUser(user *User) {
    log.Printf("Before: %+v", user)
    user.Email = normalizeEmail(user.Email)
    log.Printf("After normalize: %+v", user)
    db.Save(user)
    log.Printf("After save: %+v", user)
}

// Logs show: Email changes in normalizeEmail()
// Root Cause: normalizeEmail() lowercases domain incorrectly
Error Thrown

Strategy: Read stack trace, identify throw location, trace backwards

typescript
// Error: "TypeError: Cannot read property 'length' of null"
// Stack trace:
//   at validateInput (validator.ts:12)
//   at handleSubmit (form.ts:45)
//   at onClick (button.tsx:8)

// Phase 1: Find throw location (validator.ts:12)
function validateInput(input: string) {
  if (input.length < 3) {  // ← Line 12, input is null
    throw new Error('Too short');
  }
}

// Phase 2: Trace backwards (form.ts:45)
function handleSubmit() {
  const input = getInputValue();  // Returns null when field empty
  validateInput(input);  // ← Passes null to validateInput
}

// Root Cause: getInputValue() returns null, but validateInput expects string
// Fix: Add null check or change return type to empty string
Feature Broken

Strategy: Identify last working state, compare changes

bash
# Find last working commit
git bisect start
git bisect bad HEAD           # Current state (broken)
git bisect good v1.2.0        # Last known working version

# Git bisect identifies commit abc123 as first bad commit
git show abc123               # Shows changes

# Root Cause: Commit abc123 changed API response format

Common Root Causes

Show full SKILL.md (407 more words)Show less
Type Issues
  • Null/undefined: Value is null when code expects object
  • String vs. number: "42" treated as string, not number
  • Array vs. object: Iterating object as array
  • Promise vs. value: Forgot to await async function
Async Issues
  • Race condition: Two async operations modify same state
  • Promise not awaited: Code continues before async completes
  • Callback hell: Nested callbacks lose error context
  • Event ordering: Events fire in unexpected order
Data Issues
  • Validation failed: Input doesn't match expected format
  • Format changed: API response structure changed
  • Stale cache: Cached data is outdated
  • Encoding mismatch: UTF-8 vs. ASCII, JSON vs. string
Logic Issues
  • Wrong condition: if (x > 5) should be if (x >= 5)
  • Early return: Function returns before reaching correct code
  • Off-by-one: Loop iterates n-1 or n+1 times
  • Short-circuit: && or || causes early exit
Environment Issues
  • Env var not set: Missing API_KEY environment variable
  • Service not running: Database or API server is down
  • Version mismatch: Dependency version incompatibility
  • Permission denied: File or directory not accessible

Examples

Example 1: React Test Failure (TypeScript)

Symptom:

typescript
// Test fails: "Expected button to be disabled"
test('disables submit when invalid', () => {
  render(<Form />);
  const button = screen.getByRole('button');
  expect(button).toBeDisabled();  // ✗ Fails, button is enabled
});

Phase 1: Trace Data Flow

typescript
// Add logging to Form component
function Form() {
  const [isValid, setIsValid] = useState(false);
  console.log('isValid:', isValid);  // false (expected)

  return (
    <button disabled={!isValid}>Submit</button>
    // disabled={!false} → disabled={true} → Button should be disabled
  );
}

Phase 2: Identify Divergence

typescript
// Check actual DOM state
const button = screen.getByRole('button');
console.log('Disabled attribute:', button.disabled);  // false (actual)
console.log('Button HTML:', button.outerHTML);
// <button>Submit</button> ← Missing 'disabled' attribute!

Phase 3: Hypothesize Root Cause

typescript
// Hypothesis: disabled={!isValid} is not setting attribute
// Evidence: Check if React is updating DOM correctly
// Test: Add explicit disabled={true} to verify React works

return <button disabled={true}>Submit</button>;
// Result: Button is NOW disabled ✓
// Conclusion: disabled={!isValid} expression is wrong

Phase 4: Verify Fix

typescript
// Root Cause: !isValid evaluates to true, but disabled expects boolean
// Wait... that IS boolean. Let me re-check the initial state.

// Re-trace: Where is isValid initialized?
const [isValid, setIsValid] = useState(false);  // ✓ Correct

// Check component rendering
console.log('Rendering with isValid:', isValid);
// Logs: "Rendering with isValid: undefined" ← FOUND IT!

// Root Cause: useState(false) runs AFTER first render in test
// Fix: Set initial state before render (or use initialProps)
test('disables submit when invalid', () => {
  render(<Form initialValid={false} />);  // ✓ Now works
});
Example 2: Python API Timeout

Symptom:

python
# API request times out after 30 seconds
response = requests.get('https://api.example.com/users')
# Raises: requests.exceptions.Timeout

Phase 1: Trace Data Flow

python
import time

start = time.time()
try:
    response = requests.get('https://api.example.com/users', timeout=30)
    print(f"Request took: {time.time() - start:.2f}s")
except requests.exceptions.Timeout:
    print(f"Timeout after: {time.time() - start:.2f}s")  # 30.01s

Phase 2: Identify Divergence

python
# Expected: Request completes in <1s (normal API response time)
# Actual: Request times out at 30s
# Divergence: Something delays request for 30+ seconds

# Hypothesis: Network issue, DNS resolution, or connection hang
# Test: Add connection timing
response = requests.get(
    'https://api.example.com/users',
    timeout=(5, 30)  # (connect timeout, read timeout)
)
# Result: Raises timeout after 5s ← Connection timeout!

Phase 3: Hypothesize Root Cause

python
# Hypothesis: DNS resolution fails or connection refused
# Test: Try IP address instead of domain
response = requests.get('http://192.168.1.100/users')
# Result: Works! ✓

# Root Cause: DNS resolution for api.example.com fails
# Verification: Check DNS
import socket
socket.gethostbyname('api.example.com')  # Raises: gaierror (DNS failure)

Phase 4: Verify Fix

python
# Fix: Use IP address or fix DNS configuration
# Updated code:
API_HOST = os.getenv('API_HOST', '192.168.1.100')
response = requests.get(f'http://{API_HOST}/users')

# Verification:
assert response.status_code == 200  # ✓ Works
assert response.elapsed.total_seconds() < 1  # ✓ Fast
Example 3: Go Data Corruption

Symptom:

go
// User email is corrupted after update
user := User{ID: 1, Email: "Alice@Example.com"}
UpdateUser(&user)
fmt.Println(user.Email)  // Prints: "alice@example.com" (unexpected lowercase)

Phase 1: Trace Data Flow

go
func UpdateUser(user *User) {
    log.Printf("Before: %+v", user)  // Email: "Alice@Example.com"

    user.Email = normalizeEmail(user.Email)
    log.Printf("After normalize: %+v", user)  // Email: "alice@example.com"

    db.Save(user)
    log.Printf("After save: %+v", user)  // Email: "alice@example.com"
}

// Divergence: normalizeEmail() changes case

Phase 2: Identify Divergence

go
// Expected: Email preserves original case
// Actual: Email is lowercased
// Divergence: normalizeEmail() function

func normalizeEmail(email string) string {
    return strings.ToLower(email)  // ← Root cause!
}

Phase 3: Hypothesize Root Cause

go
// Hypothesis: normalizeEmail() should only lowercase domain, not entire email
// Expected behavior: Alice@Example.com → Alice@example.com
// Test: Check email RFC standards

// Verification: Email local part (before @) is case-sensitive
// Email domain (after @) is case-insensitive
// Root Cause: normalizeEmail() lowercases entire email, should only lowercase domain

Phase 4: Verify Fix

go
// Fix: Only lowercase domain part
func normalizeEmail(email string) string {
    parts := strings.Split(email, "@")
    if len(parts) != 2 {
        return email  // Invalid email, return as-is
    }
    return parts[0] + "@" + strings.ToLower(parts[1])
}

// Verification:
assert.Equal(t, "Alice@example.com", normalizeEmail("Alice@Example.com"))
assert.Equal(t, "alice@example.com", normalizeEmail("alice@EXAMPLE.COM"))

Integration with Other Skills

With verification-before-completion

After debugging and fixing, use verification-before-completion to confirm:

  • Test that was failing now passes (evidence: test output)
  • Root cause is addressed in fix (evidence: code review)
  • No regressions introduced (evidence: full test suite passes)
With test-driven-development

When debugging reveals a bug:

  1. Write test that reproduces the bug (RED phase)
  2. Debug to find root cause (this skill)
  3. Implement fix (GREEN phase)
  4. Refactor if needed (REFACTOR phase)
With agent-coordination-discipline

For complex debugging requiring multiple investigations:

  • Use agent delegation when debugging spans multiple services
  • Use claudish CLI for external debugging expertise
  • Define clear success criteria: "Find root cause of timeout"

Enforcement Checklist

Before marking debugging task complete:

  • Root cause identified (not just symptom)
  • Data flow traced from source to error
  • Hypothesis tested with evidence
  • Fix verified to address root cause
  • Test added to prevent regression
  • Related tests still pass (no side effects)
  • Can explain WHY fix works (not just THAT it works)

If any checkbox is unchecked, continue debugging. Do not apply fix until root cause is understood.

© MadAppGang, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/dev/skills/discipline/systematic-debugging of MadAppGang/claude-code.

Open the folder on GitHubat commit 6097ad4

Compare with similar skills

Systematic Debugging next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Systematic Debugging compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Systematic Debugging this skillMadAppGang/claude-code283—~4.6kAutomated safety check: PassMIT
OpenLogi macOS Permissions TriageAprilNEA/OpenLogi23k—~2.5kAutomated safety check: NotesApache-2.0
Bug Finder for daisyUIsaadeghi/daisyui43k—~2.3kAutomated safety check: PassMIT
Root Cause Debugginggarrytan/gstack136k—~1.4kAutomated safety check: PassMIT
Graph-Based Bug Tracingtirth8205/code-review-graph32k1 repos~287Automated safety check: PassMIT
Systematic DebuggingChrisWiles/claude-code-showcase6.1k3 repos~1.2kAutomated safety check: PassNone

Similar skills

  • Decides whether an OpenLogi device problem on macOS is a privacy-permission (TCC) problem, using agent log lines, and says which identity needs which grant.

    23k GitHub stars~2.5k tokensUpdated 4 days ago
    DevelopmentAuto-check: notes
  • Bug Finder for daisyUI

    saadeghi/daisyui

    Investigates suspected bugs in the daisyUI monorepo through read-only analysis, then writes a decision-ready fix plan in tmp/bugs without changing any product code.

    43k GitHub stars~2.3k tokensUpdated 8 days ago
    DevelopmentAuto-check passed
  • Root Cause Debugging

    garrytan/gstack

    Investigates bugs, errors and stack traces in phases and requires a root-cause hypothesis to be confirmed before any fix is written.

    136k GitHub stars~1.4k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Graph-Based Bug Tracing

    tirth8205/code-review-graph

    Traces a bug through a code knowledge graph, following callers, callees and execution flow before opening source files, within a small token budget.

    32k GitHub starsUsed in 1 repo~287 tokens
    DevelopmentAuto-check passed
  • Systematic Debugging

    ChrisWiles/claude-code-showcase

    Applies a four-phase debugging routine that finds the root cause of a bug or failing test before any fix is written.

    6.1k GitHub starsUsed in 3 repos~1.2k tokens
    DevelopmentAuto-check passed
  • Debugging and Error Recovery

    addyosmani/agent-skills

    Applies a stop-the-line rule and a step-by-step triage when tests fail, builds break or something stops working, aiming at the root cause instead of guesses.

    102k GitHub starsUsed in 1 repo~2.6k tokens
    DevelopmentAuto-check passed

More from MadAppGang/claude-code

All 69 skills in this repo
  • API Spec Analyzer

    MadAppGang/claude-code

    Analyzes API documentation from OpenAPI specs to provide TypeScript interfaces, request/response formats, and implementation guidance.

    283 GitHub starsUsed in 1 repo~2.7k tokens
    Auto-check passed
  • Content Brief

    MadAppGang/claude-code

    Content brief template and creation methodology for SEO-optimized content.

    283 GitHub starsUsed in 1 repo~959 tokens
    Auto-check passed
  • Context Detection

    MadAppGang/claude-code

    A skill your agent uses when detecting project technology stack from files/configs/directory structure, auto-loading framework-specific skills, or analyzing multi-stack fullstack projects (e.g…

    283 GitHub stars~5.4k tokensUpdated 6 mo ago
    Auto-check passed
  • Content Optimizer

    MadAppGang/claude-code

    On-page SEO optimization techniques including keyword density, meta tags, heading structure, and readability.

    283 GitHub starsUsed in 1 repo~694 tokens
    Auto-check passed
  • Keyword Cluster Builder

    MadAppGang/claude-code

    Techniques for expanding seed keywords and clustering by topic and intent.

    283 GitHub starsUsed in 1 repo~674 tokens
    Auto-check passed
  • Serp Analysis

    MadAppGang/claude-code

    SERP analysis techniques for intent classification, feature identification, and competitive intelligence.

    283 GitHub starsUsed in 1 repo~1k tokens
    Auto-check passed

Categories

Questions about Systematic Debugging

What does Systematic Debugging do?

A skill your agent uses when debugging failures, errors, or unexpected behavior. Systematic Debugging is an agent skill from MadAppGang/claude-code. Use when debugging failures, errors, or unexpected behavior.

When should I use Systematic Debugging?

Systematic Debugging fits situations like: debugging failures; unexpected behavior.

How do I install Systematic Debugging in Claude Code?

Run `npx skills add MadAppGang/claude-code --skill systematic-debugging -a claude-code`. Or copy the skill folder (plugins/dev/skills/discipline/systematic-debugging in MadAppGang/claude-code) into .claude/skills/systematic-debugging in your project. Claude Code loads it when a task matches its description.

How do I install Systematic Debugging in Codex?

Run `npx skills add MadAppGang/claude-code --skill systematic-debugging -a codex`. Or copy the skill folder (plugins/dev/skills/discipline/systematic-debugging in MadAppGang/claude-code) into .agents/skills/systematic-debugging in your project. Codex loads it when a task matches its description.

Can I use Systematic Debugging in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add MadAppGang/claude-code --skill systematic-debugging -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/systematic-debugging, .gemini/skills/systematic-debugging, .github/skills/systematic-debugging and .opencode/skills/systematic-debugging in your project.

What does Systematic Debugging need to run?

Going by SKILL.md and its folder, Systematic Debugging needs the command-line tools its instructions call (git) and credentials named API_KEY. Our summary lists: Python 3; A credential in API_KEY.

Does Systematic Debugging access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Systematic Debugging safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Systematic Debugging use?

Systematic Debugging is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Systematic Debugging use?

About 4.6k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Systematic Debugging?

Skills that share tags, products or a category with Systematic Debugging: OpenLogi macOS Permissions Triage (AprilNEA/OpenLogi, 23k stars), Bug Finder for daisyUI (saadeghi/daisyui, 43k stars), Root Cause Debugging (garrytan/gstack, 136k stars) and Graph-Based Bug Tracing (tirth8205/code-review-graph, 32k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Systematic Debugging?

MadAppGang (a GitHub organization) maintains it in MadAppGang/claude-code, which has 283 GitHub stars. The repository holds 69 skills in this directory. The repository was last updated on March 15, 2026.

Source: MadAppGang/claude-code on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.