MemoryLens — Memory Profiling Skill

Prerequisites

This skill requires the memorylens MCP server tools (ensure_dotmemory, list_processes, snapshot, compare_snapshots, analyze, get_rules).

Check if ensure_dotmemory is available as an MCP tool. If not, this skill is inert — inform the user to install the memorylens plugin.

When to Use

• On demand: User requests memory analysis (/memorylens)
• During debugging: When systematic-debugging identifies symptoms like high memory usage, OutOfMemoryException, slow GC, or growing memory over time
• During brainstorming: When designing performance-sensitive features that involve caching, event systems, or long-lived objects

Announce Line

"MemoryLens activated. I'll profile your application's memory and suggest concrete fixes."

Workflow

Step 1: Ensure tooling

Call ensure_dotmemory. If it fails, stop and report the error.

Step 2: Identify target

Ask the user what to profile:

• Running process: Call list_processes and let user pick
• Launch command: User provides a dotnet run command or similar
• Both: Attach to running OR launch — user's choice

Step 3: Choose profiling mode

Based on the user's ask:

• "How does my memory look?" → Single snapshot
• "Is there a leak?" / "What changed?" → compare_snapshots
• Unclear → Ask: "Do you want a single snapshot of current state, or a before/after comparison to detect growth?"

Step 4: Capture

Execute snapshot or compare_snapshots with the target parameters.

Step 5: Analyze

Call analyze with the returned snapshotId. If user has a .memorylens.json, pass the rulesPath.

Step 6: Apply fixes

For each finding with a suggestion:

1. Present the finding (rule, severity, description, evidence)
2. Show the suggested code change
3. Ask user for approval
4. Apply via Edit tool

Order: critical findings first, then high, medium, low.

Step 7: Summary

After all findings are addressed, present a summary:

• Total findings by severity
• Fixes applied
• Remaining items (if user skipped any)

Integration with systematic-debugging

When invoked from systematic-debugging, skip step 2 questioning — the debugger already knows the target process. Use the process context from the debugging session.

Memory smell indicators (trigger MemoryLens from debugging):

• OutOfMemoryException
• "high memory" or "memory leak" in user description
• GC pressure symptoms (frequent gen2 collections)
• Process memory growing over time

Integration with brainstorming

When brainstorming features involving:

• Event systems → Reference ML001 (event handler leaks)
• Caching → Reference ML002 (static collection growth), ML005 (gen2 retention)
• IDisposable → Reference ML003, ML009
• Large data → Reference ML004 (LOH fragmentation), ML008 (array resizing)

Use rule knowledge to inform design questions and approach proposals.

Red Flags

1. Profiling IDE or tooling processes — Never. list_processes excludes them, but if a user asks to attach to devenv/rider/Code, refuse and explain why.
2. Running compare_snapshots with very long waits — Warn if waitAfter > 60000ms. Long profiling sessions have overhead.
3. Applying suggestions without user approval — Always present and ask. Memory fixes can change behavior.