Agent skill
flow-debugging
4-phase systematic debugging for flow-fix. NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
Install this agent skill to your Project
npx add-skill https://github.com/aiskillstore/marketplace/tree/main/skills/dimon94/flow-debugging
SKILL.md
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
| Excuse | Reality |
|---|---|
| "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
- flow-fix.md - Bug fix command
- flow-tdd/SKILL.md - TDD enforcement
- verification-before-completion - Verification skill
[PROTOCOL]: 变更时更新此头部,然后检查 CLAUDE.md
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
perigon-backend
Perigon ASP.NET Core + EF Core + Aspire conventions
perigon-agent
Pointers for Copilot/agents to apply Perigon conventions
perigon-angular
Angular 21+ standalone/Material/signal conventions for Perigon WebApp
fastapi-mastery
Comprehensive FastAPI development skill covering REST API creation, routing, request/response handling, validation, authentication, database integration, middleware, and deployment. Use when working with FastAPI projects, building APIs, implementing CRUD operations, setting up authentication/authorization, integrating databases (SQL/NoSQL), adding middleware, handling WebSockets, or deploying FastAPI applications. Triggered by requests involving .py files with FastAPI code, API endpoint creation, Pydantic models, or FastAPI-specific features.
context7-efficient
Token-efficient library documentation fetcher using Context7 MCP with 86.8% token savings through intelligent shell pipeline filtering. Fetches code examples, API references, and best practices for JavaScript, Python, Go, Rust, and other libraries. Use when users ask about library documentation, need code examples, want API usage patterns, are learning a new framework, need syntax reference, or troubleshooting with library-specific information. Triggers include questions like "Show me React hooks", "How do I use Prisma", "What's the Next.js routing syntax", or any request for library/framework documentation.
browser-use
Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction.
Didn't find tool you were looking for?