debug-like-expert

The skill emphasizes treating code you wrote with MORE skepticism than unfamiliar code, as cognitive biases about "how it should work" can blind you to actual implementation errors. Use scientific method to systematically identify root causes rather than applying quick fixes.

<context_scan> Run on every invocation to detect domain-specific debugging expertise:

# What files are we debugging?
echo "FILE_TYPES:"
find . -maxdepth 2 -type f 2>/dev/null | grep -E '\.(py|js|jsx|ts|tsx|rs|swift|c|cpp|go|java)$' | head -10

# Check for domain indicators
[ -f "package.json" ] && echo "DETECTED: JavaScript/Node project"
[ -f "Cargo.toml" ] && echo "DETECTED: Rust project"
[ -f "setup.py" ] || [ -f "pyproject.toml" ] && echo "DETECTED: Python project"
[ -f "*.xcodeproj" ] || [ -f "Package.swift" ] && echo "DETECTED: Swift/macOS project"
[ -f "go.mod" ] && echo "DETECTED: Go project"

# Scan for available domain expertise
echo "EXPERTISE_SKILLS:"
ls ~/.claude/skills/expertise/ 2>/dev/null | head -5

Present findings before starting investigation. </context_scan>

<domain_expertise> Domain-specific expertise lives in ~/.claude/skills/expertise/

Domain skills contain comprehensive knowledge including debugging, testing, performance, and common pitfalls. Before investigation, determine if domain expertise should be loaded.

<scan_domains>

ls ~/.claude/skills/expertise/ 2>/dev/null

This reveals available domain expertise (e.g., macos-apps, iphone-apps, python-games, unity-games).

If no expertise skills found: Proceed without domain expertise (graceful degradation). The skill works fine with general debugging methodology. </scan_domains>

<inference_rules> If user's description or codebase contains domain keywords, INFER the domain:

If domain inferred, confirm:

Detected: [domain] issue → expertise/[skill-name]
Load this debugging expertise? (Y / see other options / none)

</inference_rules>

<no_inference> If no domain obvious, present options:

What type of project are you debugging?

Available domain expertise:
1. macos-apps - macOS Swift (SwiftUI, AppKit, debugging, testing)
2. iphone-apps - iOS Swift (UIKit, debugging, performance)
3. python-games - Python games (Pygame, physics, performance)
4. unity-games - Unity (C#, debugging, optimization)
[... any others found in build/]

N. None - proceed with general debugging methodology
C. Create domain expertise for this domain

Select:

</no_inference>

<load_domain> When domain selected, READ all references from that skill:

cat ~/.claude/skills/expertise/[domain]/references/*.md 2>/dev/null

This loads comprehensive domain knowledge BEFORE investigation:

• Common issues and error patterns
• Domain-specific debugging tools and techniques
• Testing and verification approaches
• Performance profiling and optimization
• Known pitfalls and anti-patterns
• Platform-specific considerations

Announce: "Loaded [domain] expertise. Investigating with domain-specific context."

If domain skill not found: Inform user and offer to proceed with general methodology or create the expertise. </load_domain>

<when_to_load> Domain expertise should be loaded BEFORE investigation when domain is known.

Domain expertise is NOT needed for:

• Pure logic bugs (domain-agnostic)
• Generic algorithm issues
• When user explicitly says "skip domain context" </when_to_load> </domain_expertise>