Use when a player sends a spark.lucko.me profiler link and you need to diagnose FPS or TPS issues. Also use when the user asks about Minecraft performance problems, lag, stuttering, low FPS, or wants to analyze a Spark profile.
How this skill is triggered — by the user, by Claude, or both
Slash command
/minecraft-spark-analyzer:spark-analyzeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Fetches a Spark profiler report via JSON API, identifies performance bottlenecks, and produces actionable recommendations (settings, mods, JVM args, hardware notes).
Fetches a Spark profiler report via JSON API, identifies performance bottlenecks, and produces actionable recommendations (settings, mods, JVM args, hardware notes).
The user provides a spark.lucko.me/<id> URL. Extract the profile ID from the URL.
Fetch the lightweight metadata first to understand the system and check for obvious issues before pulling the full thread data.
https://spark.lucko.me/<id>?raw=1
Use WebFetch with the prompt: "Return the complete JSON response exactly as-is, do not summarize."
From the metadata, extract and note:
| Field | Path |
|---|---|
| Platform | metadata.platform (Fabric/Paper/etc, MC version, Spark version) |
| User | metadata.user.name |
| Duration | (endTime - metadata.startTime) / 1000 seconds |
| Heap | metadata.platformStatistics.memory.heap (used/max) |
| TPS | metadata.platformStatistics.tps (1m/5m/15m) |
| MSPT | metadata.platformStatistics.mspt (mean/median/p95/max for 1m and 5m) |
| Entities | metadata.platformStatistics.world (total + top counts) |
| CPU | metadata.systemStatistics.cpu (model, threads, process/system usage) |
| RAM | metadata.systemStatistics.memory.physical (used/total) |
| GC | metadata.systemStatistics.gc (collector name, avg time, avg frequency) |
| JVM args | metadata.systemStatistics.java.vmArgs |
| Java | metadata.systemStatistics.java (vendor, version) |
| OS | metadata.systemStatistics.os |
| Mods/plugins | metadata.sources (map of mod name to metadata) |
Quick health check from metadata alone:
references/diagnosis-patterns.md.A bundled Python script handles fetching the full profile (including thread data), parsing the call tree, computing self-time per method, attributing CPU time to mods via classSources, and producing a structured report.
python3 <skill-dir>/scripts/analyze_spark.py --fetch <spark-id>
Resolve <skill-dir> relative to this SKILL.md's directory. The script:
spark.lucko.me/<id>?raw=1&full=trueclassSources mapRead the script output carefully -- it provides the raw data. Your job is to interpret it and add the diagnosis and recommendations (Steps 3 and 4).
Read references/diagnosis-patterns.md for the full pattern catalog. Cross-reference the hotspot data against known patterns:
Important analysis principles:
Structure the report as:
## Spark Profile Analysis: <player name>
**System:** <CPU> | <RAM used/total> | <OS> | <Java version> | <GC type> | <heap>
**Minecraft:** <MC version> | <loader + version> | <mod count> mods
**Profile duration:** <seconds>s | **Sampled thread:** <thread name>
**Interactive viewer:** https://spark.lucko.me/<id>
Use the viewer to explore the flame graph, bookmark methods (Alt+click), switch between All/Flat/Sources views, and toggle between percentage and millisecond display.
### Health Summary
| Metric | Value | Absolute Time | Status |
|--------|-------|---------------|--------|
| TPS | ... | -- | OK/Warning/Bad |
| MSPT (median) | ... | ...ms per tick | OK/Warning/Bad |
| MSPT (max) | ... | ...ms for a single tick | OK/Warning/Bad |
| Heap usage | ... | -- | OK/Warning/Bad |
| System RAM | ... | -- | OK/Warning/Bad |
| GC pauses | ... | -- | OK/Warning/Bad |
> Context note on what the percentages mean in absolute time for this profile.
### Thread Breakdown
| Activity | % | Est. time per tick | Notes |
|----------|---|--------------------|-------|
| Rendering | ... | ...ms | ... |
| Client tick | ... | ...ms | ... |
| Network | ... | ...ms | ... |
| Idle/sleep | ... | ...ms | ... |
> Note: mod attribution in the Sources view may overstate a mod's direct cost if it triggers downstream vanilla processing. Drill into the viewer's Sources tab to verify.
### Top Bottlenecks
Ranked by impact, with:
- What's happening (the method/mod and what it does)
- Why it's a problem
- Specific fix recommendation
### Recommendations
Split into three sections:
#### Immediate fixes (high impact)
Numbered list of critical changes, ordered by expected impact:
1. **[Category]** Specific action -- expected benefit
#### Performance tuning (medium impact)
Numbered list of tuning changes:
1. **[Category]** Specific action -- expected benefit
#### Further diagnosis
Numbered list of follow-up profiling steps to investigate root causes:
1. **[Diagnosis]** Specific command/tool -- what it reveals
### Current JVM Args
Show the full JVM args block with inline annotations for any changes needed. This helps the user copy-paste corrected args.
Categories for recommendations: JVM Args, Video Settings, Mod Config, Add Mod, Remove Mod, Hardware, Server-side, System, Diagnosis.
Include whichever of these are relevant to the profile:
Spike-only profiling -- If the profile shows MSPT spikes (max >> median), recommend:
/sparkc profiler --only-ticks-over 100 --timeout 180
This filters normal ticks and only captures spike data, making the cause much clearer. The threshold should be between 50ms and the actual spike duration. This is the #1 technique for intermittent lag.
Tick monitoring -- For ongoing spike diagnosis:
/sparkc tickmonitor --threshold-tick 50
Alerts in chat when ticks exceed the threshold, helping correlate spikes with gameplay events.
Background profiler -- Recommend enabling in config/spark/config.json:
{ "backgroundProfiler": true }
Then use /sparkc profiler open at any time to get a live view of the last hour. No need to reproduce the issue.
GC monitoring -- If GC is suspected:
/sparkc gcmonitor
Cross-reference with tick monitor output. If spikes always coincide with GC events, the issue is memory pressure, not code. Use /sparkc tickmonitor --without-gc to separate GC-caused spikes from code-caused spikes.
Heap analysis -- If memory is high:
/sparkc heapsummary
Shows which classes consume the most heap. Look for unexpected accumulation.
Allocation profiling -- To find what creates the most objects:
/sparkc profiler start --alloc
Note: requires the async-profiler engine (Linux/macOS only). On Windows, use /sparkc heapsummary instead.
Birdflop analyzer -- Recommend pasting the profile URL into https://www.birdflop.com/resources/sparkprofile/ for automated config-level recommendations. Caveat: its suggestions are guidelines, not magic values.
npx claudepluginhub disqt/minecraft-claude-marketplace --plugin minecraft-spark-analyzerProfiles system performance to identify bottlenecks using measurement before optimization — follows Brendan Gregg's USE Method and Google pprof methodology.
Orchestrates performance profiling and optimization across languages. Diagnoses symptoms, dispatches profiling agents, and manages before/after comparisons for latency, memory, CPU, and bundle issues.
Profiles apps to identify CPU/memory bottlenecks using runtime tools: clinic.js/0x for Node.js, py-spy/cProfile for Python, Chrome DevTools/Lighthouse for frontend. For slow apps, leaks, high CPU.