Back to list
aiskillstore

flow-debugging

by aiskillstore

Security-audited skills for Claude, Codex & Claude Code. One-click install, quality verified.

102🍴 3📅 Jan 23, 2026

SKILL.md


name: flow-debugging description: "4-phase systematic debugging for flow-fix. NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST."

Flow Debugging - Systematic Debugging Method

The Iron Law

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

Bug fixing is not a guessing game. Systematic debugging = faster fixes + fewer regressions.

The 4-Phase Process

Phase 1: ROOT CAUSE INVESTIGATION (NO FIXES YET)
    ↓
Phase 2: PATTERN ANALYSIS
    ↓
Phase 3: HYPOTHESIS AND TESTING
    ↓
Phase 4: IMPLEMENTATION (TDD)

Phase 1: Root Cause Investigation

Iron Law: In this phase, NO FIX CODE ALLOWED.

Step 1: Read Error Completely
  - Don't skip any details
  - Record: error type, message, stack trace
  - Record: when it happens, frequency, impact

Step 2: Stable Reproduction
  - Find reliable reproduction steps
  - Record: inputs, environment, preconditions
  - If can't reproduce → gather more information

Step 3: Check Recent Changes
  - git log --oneline -20
  - git diff HEAD~5
  - Ask: What changed? When did it start failing?

Step 4: Trace Data Flow Backwards
  - Start from error point
  - Trace upstream
  - Find where data goes wrong

Output: Root cause hypothesis (evidence-based, not a guess)

Phase 2: Pattern Analysis

Step 1: Find Working Examples
  - Where does similar functionality work?
  - Compare: working vs broken

Step 2: Compare with Reference
  - What does official documentation say?
  - How do other projects do it?
  - What's different?

Step 3: Identify Patterns
  - Is this a known bug pattern?
  - Search: error message + framework name

Output: Confirmed or refined root cause hypothesis

Phase 3: Hypothesis and Testing

Step 1: Form Single Hypothesis
  - "The problem is because X"
  - Hypothesis must be verifiable

Step 2: Test One Variable at a Time
  - Change only one factor
  - Observe result
  - Record: what changed, what happened

Step 3: 3+ Failed Fixes → STOP
  - If 3+ fix attempts fail
  - Stop and question architecture
  - Problem may be deeper than thought

Red Flag: If you're "trying this, trying that", you're guessing, not debugging.

Phase 4: Implementation (TDD)

Prerequisite: Phases 1-3 complete, root cause confirmed

Step 1: Write Failing Test First
  - Test must reproduce the bug
  - Run test, confirm it fails
  - This is your "red light"

Step 2: Implement Single Fix
  - Fix only the root cause
  - Don't "while I'm here" other things
  - Minimal change

Step 3: Verify
  - Run test, confirm it passes
  - Run related tests, confirm no regression
  - Manual verify original issue resolved

Rationalization Prevention

ExcuseReality
"I know where the problem is"Prove it. Investigate first.
"Quick fix"Quick fix = quick regression. Systematic debug.
"No time for tests"No tests = don't know if really fixed.
"Small change"Small changes can introduce big bugs. Test it.
"Fix first, investigate later"Fixing without understanding = guessing.
"Let me try this""Trying" is not debugging. Form hypothesis, verify it.
"It's obvious"Nothing is obvious. Prove with evidence.
"I've seen this before"Every bug is unique. Investigate this one.

Red Flags - STOP

If you find yourself:

  • Fixing without reproduction
  • "Trying this, trying that"
  • 3+ failed fix attempts
  • Saying "fixed" without tests
  • Changing many files for one bug

STOP. Go back to Phase 1. Investigate root cause.

Debug Output Template

# Bug Analysis - ${BUG_ID}

## Phase 1: Root Cause Investigation

### Error Details
- Type: [error type]
- Message: [error message]
- Stack: [key stack frames]

### Reproduction
- Steps: [1, 2, 3...]
- Frequency: [always/sometimes/rare]
- Environment: [conditions]

### Recent Changes
- [relevant commits]

### Data Flow Analysis
- [where data goes wrong]

### Root Cause Hypothesis
[Evidence-based hypothesis]

## Phase 2: Pattern Analysis

### Working Example
[Where similar code works]

### Comparison
[Difference between working and broken]

### Confirmed Root Cause
[Refined hypothesis]

## Phase 3: Hypothesis Testing

### Hypothesis
[Single testable hypothesis]

### Test Results
| Change | Result |
|--------|--------|
| [change 1] | [result] |

## Phase 4: Implementation

### Failing Test
[Test code that reproduces bug]

### Fix
[Minimal fix code]

### Verification
- [ ] Test passes
- [ ] No regression
- [ ] Manual verification

Integration with flow-fix

This skill is the core methodology for /flow-fix command:

/flow-fix phases:
  阶段 1: Root Cause Investigation → This skill Phase 1
  阶段 2: Pattern Analysis & Planning → This skill Phase 2
  阶段 3: 修复执行 (TDD) → This skill Phase 3-4
  阶段 4: 验证与发布 → verification-before-completion

Cross-Reference


[PROTOCOL]: 变更时更新此头部,然后检查 CLAUDE.md

Score

Total Score

60/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

+5
最近の活動

1ヶ月以内に更新

+10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon