Memory Leak Detection & Analysis

I'll help you detect, analyze, and fix memory leaks across your application stack.

Arguments: $ARGUMENTS - runtime environment (node/python/browser) or specific files

Token Optimization

This skill uses efficient patterns to minimize token consumption during memory leak detection and analysis.

Optimization Strategies

1. Runtime Detection Caching (Saves 700 tokens per invocation)

Cache detected runtime environment and profiling tools:

CACHE_FILE=".claude/cache/memory-leak/runtime.json"
CACHE_TTL=86400  # 24 hours

mkdir -p .claude/cache/memory-leak

if [ -f "$CACHE_FILE" ]; then
    CACHE_AGE=$(($(date +%s) - $(stat -c %Y "$CACHE_FILE" 2>/dev/null || stat -f %m "$CACHE_FILE" 2>/dev/null)))

    if [ $CACHE_AGE -lt $CACHE_TTL ]; then
        # Use cached runtime info
        RUNTIME=$(jq -r '.runtime' "$CACHE_FILE")
        VERSION=$(jq -r '.version' "$CACHE_FILE")
        PROFILING_TOOLS=$(jq -r '.profiling_tools' "$CACHE_FILE")

        echo "Using cached runtime: $RUNTIME $VERSION"
        echo "Profiling tools: $PROFILING_TOOLS"

        SKIP_DETECTION="true"
    fi
fi

Savings: 700 tokens (no repeated package.json reads, no npm list checks)

2. Early Exit for No Leak Pattern (Saves 90%)

Quick memory pattern check before full profiling:

# Quick check: Is memory growing abnormally?
if [ -f "memory-leak/state.json" ]; then
    LAST_RSS=$(jq -r '.last_snapshot.rss_mb' memory-leak/state.json)
    CURRENT_RSS=$(ps -o rss= -p $APP_PID | awk '{print $1/1024}')

    GROWTH_PERCENT=$(echo "scale=2; ($CURRENT_RSS - $LAST_RSS) / $LAST_RSS * 100" | bc)

    # Early exit if growth < 10%
    if (( $(echo "$GROWTH_PERCENT < 10" | bc -l) )); then
        echo "✓ Memory usage stable (${GROWTH_PERCENT}% growth)"
        echo "  Last: ${LAST_RSS}MB, Current: ${CURRENT_RSS}MB"
        echo ""
        echo "No significant memory leak detected"
        echo "Use --force for full profiling"
        exit 0
    fi
fi

Savings: 90% when memory stable (skip profiling: 3,000 → 300 tokens)

3. Sample-Based Snapshot Analysis (Saves 85%)

Analyze only key metrics from heap snapshots, not full dump:

# Efficient: Extract summary from heap snapshot (not full analysis)
analyze_heap_snapshot() {
    local snapshot_file="$1"

    # Parse JSON for key metrics only (efficient)
    SNAPSHOT_SIZE=$(jq '.snapshot.meta.total_size' "$snapshot_file")
    NODE_COUNT=$(jq '.snapshot.node_count' "$snapshot_file")
    EDGE_COUNT=$(jq '.snapshot.edge_count' "$snapshot_file")

    # Find top 5 largest object types (not all types)
    TOP_TYPES=$(jq -r '.nodes | group_by(.type) |
        map({type: .[0].type, total: map(.self_size) | add}) |
        sort_by(.total) | reverse | .[0:5] |
        .[] | "\(.type): \(.total)"' "$snapshot_file")

    echo "Heap Snapshot Summary:"
    echo "  Size: $(numfmt --to=iec $SNAPSHOT_SIZE)"
    echo "  Nodes: $NODE_COUNT"
    echo "  Edges: $EDGE_COUNT"
    echo ""
    echo "Top 5 Object Types:"
    echo "$TOP_TYPES"

    echo ""
    echo "Use --detailed for full heap analysis"
}

Savings: 85% (summary metrics vs full heap dump: 5,000 → 750 tokens)

4. Bash-Based Memory Monitoring (Saves 75%)

Use ps and top for memory tracking instead of full profilers:

# Quick memory check (no profiler needed)
quick_memory_check() {
    local pid="$1"

    # Current memory usage (instant)
    RSS=$(ps -o rss=,vsz= -p $pid | awk '{print $1/1024, $2/1024}')
    RSS_MB=$(echo "$RSS" | cut -d' ' -f1)
    VSZ_MB=$(echo "$RSS" | cut -d' ' -f2)

    # Memory trend (from previous runs)
    if [ -f "memory-leak/trend.log" ]; then
        INITIAL_RSS=$(head -1 memory-leak/trend.log | cut -d',' -f2)
        GROWTH=$(echo "scale=2; $RSS_MB - $INITIAL_RSS" | bc)
        GROWTH_PCT=$(echo "scale=2; $GROWTH / $INITIAL_RSS * 100" | bc)

        echo "Memory Status:"
        echo "  Current: ${RSS_MB}MB RSS, ${VSZ_MB}MB VSZ"
        echo "  Initial: ${INITIAL_RSS}MB"
        echo "  Growth: +${GROWTH}MB (${GROWTH_PCT}%)"
    else
        echo "Memory Status: ${RSS_MB}MB RSS, ${VSZ_MB}MB VSZ"
        echo "  (First measurement - baseline established)"
    fi

    # Append to trend log
    echo "$(date +%s),$RSS_MB,$VSZ_MB" >> memory-leak/trend.log
}

Savings: 75% vs full profiler (ps/top vs heap snapshot: 2,000 → 500 tokens)

5. Grep-Based Code Scanning (Saves 90%)

Scan for common leak patterns without reading files:

# Efficient: Grep for leak patterns
scan_leak_patterns() {
    echo "Scanning for common memory leak patterns..."

    local issues=0

    # Event listeners without cleanup
    if grep -q -r "addEventListener\|on(" --include="*.{js,ts}" src/ 2>/dev/null; then
        if ! grep -q "removeEventListener\|off(" --include="*.{js,ts}" src/ 2>/dev/null; then
            echo "⚠️  Event listeners detected without cleanup"
            issues=$((issues + 1))
        fi
    fi

    # Timers without clearInterval/clearTimeout
    if grep -q -r "setInterval\|setTimeout" --include="*.{js,ts}" src/ 2>/dev/null; then
        CLEAR_COUNT=$(grep -c "clearInterval\|clearTimeout" --include="*.{js,ts}" src/ 2>/dev/null)
        if [ "$CLEAR_COUNT" -lt 2 ]; then
            echo "⚠️  Timers without cleanup detected"
            issues=$((issues + 1))
        fi
    fi

    # Global caches without limits
    if grep -q -r "new Map()\|new Set()\|\[\].*cache" --include="*.{js,ts}" src/ 2>/dev/null; then
        echo "💡 Caches detected - verify size limits and TTL"
        issues=$((issues + 1))
    fi

    echo ""
    echo "Potential leak patterns: $issues"
}

Savings: 90% vs reading all source files (Grep returns matches only)

6. Snapshot Comparison (Only When Needed) (Saves 80%)

Compare snapshots only if multiple exist:

if [ $(ls memory-leak/snapshots/*.heapsnapshot 2>/dev/null | wc -l) -ge 2 ]; then
    echo "Multiple snapshots available for comparison"

    # Compare only latest 2 (not all)
    LATEST=$(ls -t memory-leak/snapshots/*.heapsnapshot | head -1)
    PREVIOUS=$(ls -t memory-leak/snapshots/*.heapsnapshot | head -2 | tail -1)

    # Extract key metrics only (not full diff)
    LATEST_SIZE=$(jq '.snapshot.meta.total_size' "$LATEST")
    PREV_SIZE=$(jq '.snapshot.meta.total_size' "$PREVIOUS")
    GROWTH=$((LATEST_SIZE - PREV_SIZE))

    echo "Snapshot comparison:"
    echo "  Previous: $(numfmt --to=iec $PREV_SIZE)"
    echo "  Latest: $(numfmt --to=iec $LATEST_SIZE)"
    echo "  Growth: $(numfmt --to=iec $GROWTH)"

else
    echo "Single snapshot - take another for comparison"
    echo "  Run app for 5-10 minutes, then run skill again"
fi

Savings: 80% (compare 2 snapshots vs all historical data)

7. Progressive Disclosure for Reports (Saves 70%)

Default to summary, provide detailed analysis on demand:

DETAIL_LEVEL="${DETAIL_LEVEL:-summary}"

case "$DETAIL_LEVEL" in
    summary)
        # Quick summary (400 tokens)
        echo "Memory: ${RSS_MB}MB, Growth: ${GROWTH_PCT}%"
        echo "Potential issues: $ISSUE_COUNT"
        echo ""
        echo "Use --detailed for full analysis"
        ;;

    detailed)
        # Medium detail (1,500 tokens)
        show_memory_trend
        show_leak_patterns
        show_top_allocations
        ;;

    full)
        # Complete analysis (3,000 tokens)
        show_full_heap_analysis
        show_all_leak_patterns
        show_fix_recommendations
        ;;
esac

Savings: 70% for default runs (400 vs 1,500-3,000 tokens)

Cache Invalidation

Caches are invalidated when:

• Runtime environment changes (new Node/Python version)
• 24 hours elapsed (time-based for tool detection)
• User runs --clear-cache flag
• New profiling tools installed

Real-World Token Usage

Typical memory leak workflow:

1. Initial detection: 1,200-2,000 tokens

   • Runtime detection: 400 tokens
   • Quick memory check: 200 tokens
   • Code pattern scan: 400 tokens
   • Recommendations: 400 tokens

2. Cached environment: 400-800 tokens

   • Cached runtime: 100 tokens (85% savings)
   • Quick memory check: 200 tokens
   • Trend analysis: 300 tokens

3. Stable memory (no leak): 200-400 tokens

   • Early exit: 200 tokens (90% savings)
   • Summary only: 100 tokens

4. Heap snapshot analysis: 800-1,500 tokens

   • Snapshot summary: 400 tokens
   • Top 5 object types: 300 tokens
   • Comparison (if available): 400 tokens

5. Full leak analysis: 2,000-3,000 tokens

   • Only when explicitly requested with --full flag

Average usage distribution:

• 50% of runs: Stable memory, early exit (200-400 tokens) ✅ Most common
• 30% of runs: Cached quick check (400-800 tokens)
• 15% of runs: Snapshot analysis (800-1,500 tokens)
• 5% of runs: Full leak investigation (2,000-3,000 tokens)

Expected token range: 200-2,000 tokens (50% reduction from 400-4,000 baseline)

Progressive Disclosure

Three levels of detail:

1. Default (summary): Memory status + quick scan

   claude "/memory-leak"
   # Shows: current memory, growth %, potential issues
   # Tokens: 400-800
   

2. Detailed (medium): Trend + pattern analysis

   claude "/memory-leak --detailed"
   # Shows: memory trend, leak patterns, top allocations
   # Tokens: 1,200-1,500
   

3. Full (exhaustive): Complete heap analysis

   claude "/memory-leak --full"
   # Shows: full heap dump analysis, all patterns, comprehensive fixes
   # Tokens: 2,000-3,000
   

Implementation Notes

Key patterns applied:

• ✅ Runtime detection caching (700 token savings)
• ✅ Early exit for stable memory (90% reduction)
• ✅ Sample-based snapshot analysis (85% savings)
• ✅ Bash-based memory monitoring (75% savings)
• ✅ Grep-based code scanning (90% savings)
• ✅ Minimal snapshot comparison (80% savings)
• ✅ Progressive disclosure (70% savings on default)

Cache locations:

• .claude/cache/memory-leak/runtime.json - Runtime environment and tools
• memory-leak/trend.log - Memory usage timeline (project-specific)
• memory-leak/state.json - Last profiling state (project-specific)

Flags:

• --force - Force full profiling even if memory stable
• --detailed - Medium detail level (trend + patterns)
• --full - Complete heap analysis
• --clear-cache - Force cache invalidation
• --snapshot - Take new heap snapshot

Runtime-specific:

• Node.js: V8 heap snapshots, process.memoryUsage()
• Python: tracemalloc, memory_profiler
• Browser: Chrome DevTools memory profiler

Session Intelligence

I'll maintain memory profiling sessions for tracking leaks over time:

Session Files (in current project directory):

• memory-leak/profile.md - Memory analysis and findings
• memory-leak/state.json - Profiling data and progress
• memory-leak/snapshots/ - Heap snapshots and memory dumps

IMPORTANT: Session files are stored in a memory-leak folder in your current project root

Auto-Detection:

• If session exists: Compare with previous profiles
• If no session: Perform initial memory analysis
• Commands: resume, analyze, compare, new

Phase 1: Runtime Detection & Setup

Extended Thinking for Memory Analysis

For complex memory leak scenarios, I'll use extended thinking to understand patterns:

Triggers for Extended Analysis:

• Long-running server applications
• Real-time data processing systems
• Browser applications with complex state
• Applications with significant memory growth over time

I'll automatically detect your runtime environment:

Node.js Detection:

# Check for Node.js project
if [ -f "package.json" ]; then
    echo "Node.js project detected"
    node_version=$(node --version 2>/dev/null)
    if [ $? -eq 0 ]; then
        echo "Node.js $node_version available"
        # Check for profiling tools
        npm list --depth=0 | grep -E "(heapdump|clinic|memwatch|node-inspect)"
    fi
fi

Python Detection:

# Check for Python project
if [ -f "requirements.txt" ] || [ -f "setup.py" ] || [ -f "pyproject.toml" ]; then
    echo "Python project detected"
    python_version=$(python3 --version 2>/dev/null)
    if [ $? -eq 0 ]; then
        echo "$python_version available"
        # Check for profiling modules
        python3 -c "import tracemalloc, memory_profiler" 2>/dev/null
        if [ $? -eq 0 ]; then
            echo "Memory profiling modules available"
        fi
    fi
fi

Browser Detection:

# Check for frontend project
if [ -f "package.json" ]; then
    if grep -qE "(react|vue|angular|svelte)" package.json; then
        echo "Frontend framework detected"
        echo "Browser memory profiling available via Chrome DevTools"
    fi
fi

Phase 2: Memory Profiling Setup

Based on detected environment, I'll configure appropriate profiling:

Node.js Memory Profiling

Built-in Inspector:

// Enable heap profiling
node --inspect --expose-gc your-app.js

// Programmatic heap snapshot
const v8 = require('v8');
const fs = require('fs');

function takeHeapSnapshot(filename) {
    const snapshotStream = v8.writeHeapSnapshot();
    console.log(`Heap snapshot written to ${snapshotStream}`);
    return snapshotStream;
}

// Take snapshots at intervals
setInterval(() => {
    takeHeapSnapshot(`memory-leak/snapshots/heap-${Date.now()}.heapsnapshot`);
}, 60000);

Heapdump Integration:

const heapdump = require('heapdump');
const path = require('path');

// Trigger on signal
process.on('SIGUSR2', () => {
    const filename = path.join(
        'memory-leak/snapshots',
        `heap-${Date.now()}.heapsnapshot`
    );
    heapdump.writeSnapshot(filename, (err, filepath) => {
        if (err) console.error(err);
        else console.log(`Heap snapshot written to ${filepath}`);
    });
});

Memory Usage Monitoring:

function monitorMemory() {
    const usage = process.memoryUsage();
    return {
        timestamp: new Date().toISOString(),
        rss: Math.round(usage.rss / 1024 / 1024) + ' MB',
        heapTotal: Math.round(usage.heapTotal / 1024 / 1024) + ' MB',
        heapUsed: Math.round(usage.heapUsed / 1024 / 1024) + ' MB',
        external: Math.round(usage.external / 1024 / 1024) + ' MB',
        arrayBuffers: Math.round(usage.arrayBuffers / 1024 / 1024) + ' MB'
    };
}

// Log memory every minute
setInterval(() => {
    console.log('Memory usage:', JSON.stringify(monitorMemory()));
}, 60000);

Python Memory Profiling

tracemalloc (Built-in):

import tracemalloc
import linecache

def start_memory_tracking():
    tracemalloc.start()

def take_memory_snapshot():
    snapshot = tracemalloc.take_snapshot()
    top_stats = snapshot.statistics('lineno')

    print("[ Top 10 memory consuming lines ]")
    for stat in top_stats[:10]:
        print(stat)

    return snapshot

def compare_snapshots(snapshot1, snapshot2):
    top_stats = snapshot2.compare_to(snapshot1, 'lineno')

    print("[ Top 10 memory growth areas ]")
    for stat in top_stats[:10]:
        print(stat)

memory_profiler:

from memory_profiler import profile

@profile
def potentially_leaky_function():
    # Function to analyze
    pass

# Run with: python -m memory_profiler your_script.py

objgraph for Reference Tracking:

import objgraph
import gc

def analyze_object_growth():
    # Show most common types
    objgraph.show_most_common_types()

    # Track object growth
    objgraph.show_growth()

    # Find reference chains keeping objects alive
    roots = objgraph.get_leaking_objects()
    print(f"Found {len(roots)} potentially leaked objects")

Browser Memory Profiling

Chrome DevTools Integration: I'll guide you through browser memory analysis:

1. Heap Snapshot Workflow:

   • Take snapshot before action
   • Perform suspected leaky operation
   • Take snapshot after action
   • Compare snapshots for retained objects

2. Allocation Timeline:

   • Record allocation timeline
   • Perform operations
   • Identify object allocations that weren't freed

3. Memory Panel Analysis:

   • Monitor memory usage in real-time
   • Identify memory spikes and growth trends
   • Track garbage collection effectiveness

Common Browser Leak Patterns:

// Pattern 1: Event listener leaks
class LeakyComponent {
    constructor() {
        // BAD: Never removed
        window.addEventListener('resize', this.handleResize);
    }

    // FIX: Cleanup in destroy
    destroy() {
        window.removeEventListener('resize', this.handleResize);
    }
}

// Pattern 2: Timer leaks
function leakyFunction() {
    // BAD: Interval never cleared
    setInterval(() => {
        console.log('Running...');
    }, 1000);
}

// Pattern 3: Detached DOM nodes
let cache = [];
function cacheElement() {
    // BAD: Keeps DOM nodes in memory after removal
    cache.push(document.getElementById('temp'));
}

Phase 3: Leak Detection Analysis

I'll analyze memory patterns to identify leaks:

Detection Strategies:

1. Heap Growth Analysis:

   • Monitor heap size over time
   • Identify continuous growth without GC recovery
   • Compare heap snapshots

2. Retained Object Analysis:

   • Find objects that should be garbage collected
   • Trace retention paths
   • Identify unexpected references

3. Circular Reference Detection:

   • Scan for circular reference patterns
   • Check for manual cleanup requirements
   • Suggest WeakMap/WeakRef solutions

4. Event Listener Auditing:

   • Count active event listeners
   • Match add/remove pairs
   • Find orphaned listeners

Analysis Output:

# Memory Leak Analysis Report

## Executive Summary
- **Environment**: Node.js 20.10.0
- **Analysis Duration**: 30 minutes
- **Leak Detected**: YES
- **Severity**: HIGH
- **Memory Growth**: 45 MB/hour

## Leak Sources Identified

### 1. Event Listener Accumulation
- **Location**: `src/services/WebSocketService.js:45`
- **Issue**: Socket event listeners not removed on disconnect
- **Impact**: ~2 MB per connection
- **Retention Path**: `EventEmitter -> handler -> closure -> largeDataBuffer`

### 2. Cache Without Limits
- **Location**: `src/cache/ResponseCache.js:23`
- **Issue**: Unbounded in-memory cache
- **Impact**: ~15 MB/hour growth
- **Retention Path**: `Map -> CacheEntry -> responseBody`

### 3. Circular References
- **Location**: `src/models/User.js:67`
- **Issue**: Parent-child circular references
- **Impact**: Prevents GC, accumulates 5 MB/hour
- **Retention Path**: `User -> friends[] -> User`

## Recommendations
[Detailed fix recommendations...]

Phase 4: Integration with Performance Profiling

Cross-Skill Integration:

# When memory leaks impact performance
/memory-leak analyze    # Detect memory issues
/performance-profile    # Check CPU/runtime impact

I'll coordinate analysis across both dimensions:

• Memory leaks causing GC pressure
• Performance degradation from memory churn
• Optimization opportunities from profiling data

Phase 5: Leak Remediation

I'll help fix identified leaks systematically:

Fix Pattern 1: Proper Cleanup

// BEFORE: Leak
class Component {
    constructor() {
        this.timer = setInterval(this.update, 1000);
        window.addEventListener('resize', this.handleResize);
    }
}

// AFTER: Fixed
class Component {
    constructor() {
        this.timer = setInterval(this.update, 1000);
        this.handleResize = this.handleResize.bind(this);
        window.addEventListener('resize', this.handleResize);
    }

    destroy() {
        clearInterval(this.timer);
        window.removeEventListener('resize', this.handleResize);
        this.timer = null;
    }
}

Fix Pattern 2: Bounded Caches

// BEFORE: Unbounded
const cache = new Map();

function cacheResponse(key, data) {
    cache.set(key, data);
}

// AFTER: LRU Cache with limits
class LRUCache {
    constructor(maxSize = 100) {
        this.cache = new Map();
        this.maxSize = maxSize;
    }

    set(key, value) {
        if (this.cache.size >= this.maxSize) {
            const firstKey = this.cache.keys().next().value;
            this.cache.delete(firstKey);
        }
        this.cache.set(key, value);
    }
}

Fix Pattern 3: WeakRef for Circular References

// BEFORE: Strong circular reference
class User {
    constructor(name) {
        this.name = name;
        this.friends = [];
    }

    addFriend(user) {
        this.friends.push(user);
        user.friends.push(this); // Circular reference
    }
}

// AFTER: WeakRef to break cycle
class User {
    constructor(name) {
        this.name = name;
        this.friends = [];
    }

    addFriend(user) {
        this.friends.push(new WeakRef(user));
        user.friends.push(new WeakRef(this));
    }

    getFriends() {
        return this.friends
            .map(ref => ref.deref())
            .filter(friend => friend !== undefined);
    }
}

Fix Pattern 4: Cleanup in Python

# BEFORE: Leak
class DataProcessor:
    def __init__(self):
        self.cache = {}
        self.connections = []

    def process(self, data):
        self.cache[data.id] = data  # Never cleaned

# AFTER: Context manager and cleanup
class DataProcessor:
    def __init__(self, max_cache_size=1000):
        self.cache = {}
        self.connections = []
        self.max_cache_size = max_cache_size

    def process(self, data):
        if len(self.cache) >= self.max_cache_size:
            # Remove oldest
            oldest_key = next(iter(self.cache))
            del self.cache[oldest_key]

        self.cache[data.id] = data

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.cleanup()

    def cleanup(self):
        self.cache.clear()
        for conn in self.connections:
            conn.close()
        self.connections.clear()

Phase 6: Verification & Monitoring

After applying fixes, I'll verify the leak is resolved:

Verification Process:

1. Take baseline memory snapshot
2. Run application under load
3. Monitor memory growth over time
4. Compare with pre-fix behavior
5. Validate no new leaks introduced

Long-term Monitoring Setup:

// Production memory monitoring
const monitoring = {
    interval: 300000, // 5 minutes
    threshold: 500 * 1024 * 1024, // 500 MB

    start() {
        setInterval(() => {
            const usage = process.memoryUsage();

            if (usage.heapUsed > this.threshold) {
                console.warn('Memory threshold exceeded', {
                    heapUsed: Math.round(usage.heapUsed / 1024 / 1024) + ' MB',
                    timestamp: new Date().toISOString()
                });

                // Optional: trigger alert or heap dump
            }
        }, this.interval);
    }
};

Context Continuity

Session Resume: When you return and run /memory-leak or /memory-leak resume:

• Load previous analysis and snapshots
• Compare current memory with baseline
• Show trend analysis
• Continue from last checkpoint

Progress Example:

RESUMING MEMORY LEAK ANALYSIS
├── Initial heap size: 125 MB
├── Current heap size: 180 MB
├── Growth rate: 9 MB/hour
├── Leaks fixed: 2 of 4
├── Next: Circular reference in User model

Comparing heap snapshots...

Practical Examples

Start Analysis:

/memory-leak                    # Auto-detect runtime
/memory-leak node               # Node.js specific
/memory-leak python             # Python specific
/memory-leak browser            # Browser guidance
/memory-leak src/services/      # Analyze specific path

Session Control:

/memory-leak resume      # Continue analysis
/memory-leak analyze     # Run new profiling
/memory-leak compare     # Compare snapshots
/memory-leak status      # Check current state

Safety Guarantees

Protection Measures:

• Git checkpoint before fixes
• Non-invasive profiling
• No production impact from analysis
• Snapshot data stays local

Important: I will NEVER:

• Profile production without permission
• Modify profiling in way that impacts performance
• Expose sensitive data in snapshots
• Add AI attribution to commits

Skill Integration

When appropriate for memory issues:

• /performance-profile - Cross-reference with CPU usage
• /test - Verify fixes don't break functionality
• /review - Code review for leak patterns
• /commit - Safe commit of memory fixes

Profiling Tools Reference

Node.js:

• Built-in: --inspect, --expose-gc, v8.writeHeapSnapshot()
• heapdump: Heap snapshot on demand
• clinic: Comprehensive profiling suite
• memwatch-next: Memory leak detection
• node-inspect: Interactive debugging

Python:

• Built-in: tracemalloc, gc module
• memory_profiler: Line-by-line profiling
• objgraph: Object reference tracking
• pympler: Advanced memory analysis
• guppy3: Heap analysis

Browser:

• Chrome DevTools Memory Panel
• Firefox Developer Tools Memory Tool
• Heap snapshots
• Allocation timeline
• Performance monitor

Token Budget Optimization

To stay within 3,500-5,500 token budget:

• Focus analysis on detected issues only
• Use compact reporting format
• Defer detailed profiling to manual review
• Provide actionable fixes over theory
• Batch similar leak patterns

What I'll Actually Do

1. Detect runtime - Auto-identify Node.js/Python/Browser
2. Profile systematically - Use appropriate tools for platform
3. Identify leaks - Extended thinking for complex patterns
4. Provide fixes - Concrete code changes
5. Verify resolution - Confirm leaks eliminated
6. Monitor ongoing - Setup long-term tracking

I'll help you eliminate memory leaks and establish monitoring to prevent future issues.

Credits:

• Inspired by Node.js profiling best practices
• Chrome DevTools Memory Profiling Guide
• Python memory_profiler documentation
• obra/superpowers debugging methodology
• Production memory leak patterns from real-world applications