
Debug
- 488 installs
- 3.9k repo stars
- Updated January 26, 2026
- parcadei/continuous-claude-v3
debug is a Claude Code skill from parcadei/continuous-claude-v3 that systematically investigates issues by examining logs, database state, and git history for developers debugging manual tests or agent loops without edit
About
debug is a parcadei/continuous-claude-v3 read-only investigation skill for bootstrapping debugging sessions during manual testing or implementation. When invoked with a plan or ticket file, debug examines logs, database state, and git history to understand what went wrong without modifying source files—preserving the primary agent window context. Developers reach for debug when encountering error messages, unexpected behavior during feature testing, or agent loop failures that need structured root-cause analysis. The skill asks targeted questions about expected versus actual behavior, then investigates system state to narrow the failure surface before proposing fixes in a separate editing session.
- Continuous self-debug loop for Claude agent runs
- Automatically detects and corrects reasoning errors
- Reduces token waste from repeated failed attempts
- Works across frontend, backend, and workflow tasks
- Hard-gate: invoke only after first failure is observed
Debug by the numbers
- 488 all-time installs (skills.sh)
- +2 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #90 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill debugAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 488 |
|---|---|
| repo stars | ★ 3.9k |
| Last updated | January 26, 2026 |
| Repository | parcadei/continuous-claude-v3 ↗ |
How do you debug test failures using logs and git history?
Get Claude to systematically debug its own outputs and agent loops without manual prompting each time.
Who is it for?
Developers mid-implementation who need a read-only debugging session examining logs, DB state, and git history before applying fixes.
Skip if: Automated CI test runners or production incident response requiring on-call paging and live traffic mitigation.
When should I use this skill?
A developer reports a test failure, unexpected behavior, error messages, or asks to investigate logs, database state, or git history read-only.
What you get
Root-cause analysis report, log excerpts, database state findings, and git history timeline of relevant changes.
- Root-cause analysis
- Log excerpts
- Git timeline findings
Files
Debug
You are tasked with helping debug issues during manual testing or implementation. This command allows you to investigate problems by examining logs, database state, and git history without editing files. Think of this as a way to bootstrap a debugging session without using the primary window's context.
Initial Response
When invoked WITH a plan/ticket file:
I'll help debug issues with [file name]. Let me understand the current state.
What specific problem are you encountering?
- What were you trying to test/implement?
- What went wrong?
- Any error messages?
I'll investigate the logs, database, and git state to help figure out what's happening.When invoked WITHOUT parameters:
I'll help debug your current issue.
Please describe what's going wrong:
- What are you working on?
- What specific problem occurred?
- When did it last work?
I can investigate logs, database state, and recent changes to help identify the issue.Environment Information
You have access to these key locations and tools:
Logs:
- Application logs (check project-specific locations)
- Common locations:
./logs/,~/.local/share/{app}/,/var/log/
Database (if applicable):
- SQLite databases can be queried with
sqlite3 - Check project config for database locations
Git State:
- Check current branch, recent commits, uncommitted changes
- Similar to how
commitanddescribe_prcommands work
Service Status:
- Check running processes:
ps aux | grep {service} - Check listening ports:
lsof -i :{port}
Process Steps
Step 1: Understand the Problem
After the user describes the issue:
1. Read any provided context (plan or ticket file):
- Understand what they're implementing/testing
- Note which phase or step they're on
- Identify expected vs actual behavior
2. Quick state check:
- Current git branch and recent commits
- Any uncommitted changes
- When the issue started occurring
Step 2: Investigate the Issue
Spawn parallel Task agents for efficient investigation:
Task 1 - Check Recent Logs:
Find and analyze the most recent logs for errors:
1. Find latest logs: ls -t ./logs/*.log | head -1 (or project-specific location)
2. Search for errors, warnings, or issues around the problem timeframe
3. Note the working directory if shown
4. Look for stack traces or repeated errors
Return: Key errors/warnings with timestampsTask 2 - Database State (if applicable):
Check the current database state:
1. Locate database file (check project config)
2. Connect: sqlite3 {database_path}
3. Check schema: .tables and .schema for relevant tables
4. Query recent data based on the issue
5. Look for stuck states or anomalies
Return: Relevant database findingsTask 3 - Git and File State:
Understand what changed recently:
1. Check git status and current branch
2. Look at recent commits: git log --oneline -10
3. Check uncommitted changes: git diff
4. Verify expected files exist
5. Look for any file permission issues
Return: Git state and any file issuesStep 3: Present Findings
Based on the investigation, present a focused debug report:
## Debug Report
### What's Wrong
[Clear statement of the issue based on evidence]
### Evidence Found
**From Logs**:
- [Error/warning with timestamp]
- [Pattern or repeated issue]
**From Database** (if applicable):-- Relevant query and result [Finding from database]
**From Git/Files**:
- [Recent changes that might be related]
- [File state issues]
### Root Cause
[Most likely explanation based on evidence]
### Next Steps
1. **Try This First**:[Specific command or action]
2. **If That Doesn't Work**:
- Restart relevant services
- Check browser console for frontend errors
- Run with debug flags enabled
### Can't Access?
Some issues might be outside my reach:
- Browser console errors (F12 in browser)
- MCP server internal state
- System-level issues
Would you like me to investigate something specific further?Important Notes
- Focus on manual testing scenarios - This is for debugging during implementation
- Always require problem description - Can't debug without knowing what's wrong
- Read files completely - No limit/offset when reading context
- Think like `commit` or `describe_pr` - Understand git state and changes
- Guide back to user - Some issues (browser console, MCP internals) are outside reach
- No file editing - Pure investigation only
Quick Reference
Find Latest Logs:
ls -t ./logs/*.log | head -1
# Or check project-specific log locationsDatabase Queries (SQLite):
sqlite3 {database_path} ".tables"
sqlite3 {database_path} ".schema {table}"
sqlite3 {database_path} "SELECT * FROM {table} ORDER BY created_at DESC LIMIT 5;"Service Check:
ps aux | grep {service_name}
lsof -i :{port}Git State:
git status
git log --oneline -10
git diffRemember: This command helps you investigate without burning the primary window's context. Perfect for when you hit an issue during manual testing and need to dig into logs, database, or git state.
Related skills
How it compares
Use debug for read-only log and git investigation during manual testing rather than automated test generation or code editing fixes.
FAQ
Does debug modify source files?
debug from parcadei/continuous-claude-v3 performs read-only investigation of logs, database state, and git history without editing files, so developers can bootstrap diagnosis in a separate context window.
What inputs does debug accept?
debug accepts an optional plan or ticket file to scope investigation, then asks about the expected behavior, actual failure, and error messages before examining logs, database records, and git commits.