Major refactoring of projman plugin architecture: Skills Extraction (17 new files): - Extracted reusable knowledge from commands and agents into skills/ - branch-security, dependency-management, git-workflow, input-detection - issue-conventions, lessons-learned, mcp-tools-reference, planning-workflow - progress-tracking, repo-validation, review-checklist, runaway-detection - setup-workflows, sprint-approval, task-sizing, test-standards, wiki-conventions Command Consolidation (17 → 12 commands): - /setup: consolidates initial-setup, project-init, project-sync (--full/--quick/--sync) - /debug: consolidates debug-report, debug-review (report/review modes) - /test: consolidates test-check, test-gen (run/gen modes) - /sprint-status: absorbs sprint-diagram via --diagram flag Architecture Cleanup: - Remove plugin-level mcp-servers/ symlinks (6 plugins) - Remove plugin README.md files (12 files, ~2000 lines) - Update all documentation to reflect new command structure - Fix documentation drift in CONFIGURATION.md, COMMANDS-CHEATSHEET.md Commands are now thin dispatchers (~20-50 lines) that reference skills. Agents reference skills for domain knowledge instead of inline content. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
4.6 KiB
description
| description |
|---|
| Diagnose issues and create reports, or investigate existing diagnostic issues |
Debug
Skills Required
- skills/mcp-tools-reference.md
- skills/lessons-learned.md
- skills/git-workflow.md
Purpose
Unified debugging command for diagnostics and issue investigation.
Invocation
/debug # Ask which mode
/debug report # Run diagnostics, create issue
/debug review # Investigate existing issues
Mode Selection
If no subcommand provided, ask user:
- Report - Run MCP tool diagnostics and create issue in marketplace
- Review - Investigate existing diagnostic issues and propose fixes
Mode: Report
Create structured issues in the marketplace repository.
Prerequisites
Project .env must have:
PROJMAN_MARKETPLACE_REPO=personal-projects/leo-claude-mktplace
Workflow
Step 0: Select Report Type
- Automated - Run MCP tool diagnostics and report failures
- User-Reported - Gather structured feedback about a problem
For User-Reported (Step 0.1)
Gather via AskUserQuestion:
- Which plugin/command was affected
- What was the goal
- What type of problem (error, missing feature, unexpected behavior, docs)
- Problem description
- Expected behavior
- Workaround (optional)
Steps 1-2: Context Gathering
- Gather project context (git remote, branch, pwd)
- Detect sprint context (active milestone)
- Read marketplace config
Steps 3-4: Diagnostic Suite (Automated Only)
Run MCP tools with explicit repo parameter:
validate_repo_orgget_labelslist_issueslist_milestonessuggest_labels
Categorize: Parameter Format, Authentication, Not Found, Network, Logic
Steps 5-6: Generate Labels and Issue
Automated: Type/Bug, Source/Diagnostic, Agent/Claude + suggested
User-Reported: Map problem type to labels
Step 7: Create Issue
Use curl (not MCP) - avoids branch protection issues
Step 8: Report to User
Show summary and link to created issue
DO NOT (Report Mode)
- Attempt to fix anything - only report
- Create issues if all automated tests pass (unless user-reported)
- Use MCP tools to create issues in marketplace - always use curl
Mode: Review
Investigate diagnostic issues and propose fixes with human approval.
Workflow with Approval Gates
Steps 1-8: Investigation
- Detect repository (git remote)
- Fetch diagnostic issues:
list_issues(labels=["Source: Diagnostic"]) - Display issue list
- User selects issue (AskUserQuestion)
- Fetch full details:
get_issue(issue_number=...) - Parse diagnostic report (failed tools, errors, hypothesis)
- Map errors to files
- Read relevant files - MANDATORY before proposing fix
Step 9: Investigation Summary
Present analysis to user.
APPROVAL GATE 1: "Does this analysis match your understanding?"
- STOP and wait for user response
Step 9.5: Search Lessons Learned
Search for related past fixes using search_lessons.
Step 10: Propose Fix
Present specific fix approach with changes and rationale.
APPROVAL GATE 2: "Proceed with this fix?"
- STOP and wait for user response
Steps 11-12: Implement
- Create feature branch (
fix/issue-N-description) - Make code changes
- Run tests
- Show diff to user
APPROVAL GATE 3: "Create PR with these changes?"
- STOP and wait for user response
Steps 13-15: Finalize
- Commit and push
- Create PR
- After user verifies fix: Close issue (REQUIRED) and capture lesson
Error-to-File Quick Reference
| Error Pattern | Check Files |
|---|---|
| "owner/repo format" | config.py, gitea_client.py |
| "404" + "orgs" | gitea_client.py |
| "401", "403" | config.py (token) |
| "No repository" | Command .md file |
DO NOT (Review Mode)
- Skip reading relevant files
- Proceed past approval gates without confirmation
- Close issues until user confirms fix works
- Commit directly to development/main
Visual Output
╔══════════════════════════════════════════════════════════════════╗
║ 📋 PROJMAN ║
║ 🔧 DEBUG ║
║ [Mode: Report | Review] ║
╚══════════════════════════════════════════════════════════════════╝