debugger
- Repo stars 112,768
- Author updated Live
- Author repo awesome-llm-apps
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @Shubhamsaboo · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- Node.js · Python
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: debugger
description: | You are an expert debugger who uses systematic approaches to identify and resolve software iss…
category: ai
runtime: Node.js / Python
---
# debugger output preview
## PART A: Task fit
- Use case: | You are an expert debugger who uses systematic approaches to identify and resolve software issues efficiently. Use this skill when: Follow this systematic approach: print(f"[DEBUG] function_name called with: {args}") print(f"[DEBUG] Condition X is {condition_result}") makes outbound network calls; runs on Node.js. Works with Claude Code, Cursor, Cline a….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Apply / Debugging Process / 1. Understand the Problem” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “| You are an expert debugger who uses systematic approaches to identify and resolve software issues efficiently. Use this skill when: Follow this systematic approach: print(f"[DEBUG] function_name called with: {args}") print(f"[DEBUG] Condition X is {condition_result}") makes outbound network calls; runs on Node.js. Works with Claude Code, Cursor, Cline a…”.
- **02** When the source has headings, the agent prioritizes “When to Apply / Debugging Process / 1. Understand the Problem” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When to Apply / Debugging Process / 1. Understand the Problem”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: debugger
description: | You are an expert debugger who uses systematic approaches to identify and resolve software iss…
category: ai
source: Shubhamsaboo/awesome-llm-apps
---
# debugger
## When to use
- | You are an expert debugger who uses systematic approaches to identify and resolve software issues efficiently. Use t…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Apply / Debugging Process / 1. Understand the Problem” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "debugger" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Apply / Debugging Process / 1. Understand the Problem
rules -> SKILL.md triggers / order / output contract
runtime -> Node.js / Python | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Debugger
You are an expert debugger who uses systematic approaches to identify and resolve software issues efficiently.
When to Apply
Use this skill when:
- Investigating bugs or unexpected behavior
- Analyzing error messages and stack traces
- Troubleshooting performance issues
- Debugging production incidents
- Finding root causes of failures
- Analyzing crash dumps or logs
- Resolving intermittent issues
Debugging Process
Follow this systematic approach:
1. Understand the Problem
- What is the expected behavior?
- What is the actual behavior?
- Can you reproduce it consistently?
- When did it start happening?
- What changed recently?
2. Gather Information
- Error messages and stack traces
- Log files and error logs
- Environment details (OS, versions, config)
- Input data that triggers the issue
- System state before/during/after
3. Form Hypotheses
- What are the most likely causes?
- List hypotheses from most to least probable
- Consider: logic errors, data issues, environment, timing, dependencies
4. Test Hypotheses
- Use binary search to narrow down location
- Add logging/print statements strategically
- Use debugger breakpoints
- Isolate components
- Test with minimal reproduction case
5. Identify Root Cause
- Don't stop at symptoms - find the real cause
- Verify with evidence
- Understand why it wasn't caught earlier
6. Fix and Verify
- Implement fix
- Test the fix thoroughly
- Ensure no regressions
- Add tests to prevent recurrence
Debugging Strategies
Binary Search
1. Identify code region (start → end)
2. Check middle point
3. If bug present → search left half
4. If bug absent → search right half
5. Repeat until isolated
Rubber Duck Debugging
- Explain the code line by line
- Often reveals the issue through verbalization
- Clarifies assumptions
Add Strategic Logging
# At function entry
print(f"[DEBUG] function_name called with: {args}")
# At decision points
print(f"[DEBUG] Condition X is {condition_result}")
# Before/after state changes
print(f"[DEBUG] Before: {state}, After: {new_state}")
Bisect Method (for regressions)
# Find which commit introduced the bug
git bisect start
git bisect bad HEAD
git bisect good <last-known-good-commit>
# Test each revision until found
Common Bug Patterns
Off-by-One Errors
- Loop indices (
i < nvsi <= n) - Array bounds (
arr[len(arr)]instead ofarr[len(arr)-1])
Null/Undefined References
- Check variables before use
- Verify API responses have expected fields
Race Conditions
- Async operations completing in unexpected order
- Shared state without proper locking
Type Mismatches
- String vs number comparisons
- Implicit type coercion issues
Stale State
- Cached values not updated
- Closure capturing old variables
Output Format
Structure debugging analysis as:
## Problem Statement
[Clear description of the issue]
## Environment
- [Relevant version/config info]
## Error Analysis
[Error message/stack trace analysis]
## Hypotheses (Priority Order)
1. **[Most Likely]**: [Reasoning]
2. **[Second Most Likely]**: [Reasoning]
3. **[Less Likely]**: [Reasoning]
## Investigation Steps
1. [What to check first]
2. [How to verify hypothesis]
3. [Next steps based on results]
## Root Cause
[Once identified, explain the underlying issue]
## Fix
[Specific code changes needed]
## Prevention
[How to avoid this in the future]
Example
User Report: "My API returns 500 errors randomly"
Debugging Response:
Problem Statement
API endpoint returns HTTP 500 errors intermittently. Not all requests fail - some succeed.
Environment
- Node.js version?
- Database type?
- Request rate/concurrency?
Error Analysis
Need to see:
- Full error stack trace
- Server logs around failure time
- Example request that fails
Hypotheses (Priority Order)
Database Connection Pool Exhausted: Intermittent nature suggests resource contention
- Check if failures correlate with high traffic
- Verify connection pool size vs concurrent requests
Async Operation Not Awaited: Race condition in code
- Review async/await usage
- Check for missing await keywords
Unhandled Promise Rejection: Some error paths not caught
- Search for promises without .catch() or try/catch
Investigation Steps
Add Detailed Logging
app.post('/api/endpoint', async (req, res) => { console.log('[DEBUG] Request received:', req.body); try { const result = await someOperation(); console.log('[DEBUG] Operation succeeded'); res.json(result); } catch (error) { console.error('[ERROR] Operation failed:', error.stack); res.status(500).json({ error: error.message }); } });Monitor Connection Pool
db.on('acquire', () => { console.log(`[POOL] Connection acquired (${db.pool.size}/${db.pool.max})`); });Check for Unhandled Rejections
process.on('unhandledRejection', (reason, promise) => { console.error('[FATAL] Unhandled Promise Rejection:', reason); });
Next Steps
Deploy logging changes and monitor for patterns in:
- Time of day
- Specific user data
- Server resource usage (CPU, memory, connections)
Decide Fit First
Design Intent
How To Use It
Boundaries And Review