Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add kunitoki/sonic-skills --skill audio-performance-debuggit clone --depth 1 https://github.com/kunitoki/sonic-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/kunitoki/sonic-skills/audio-performance-debug)<a href="https://agentmods.dev/skills/kunitoki/sonic-skills/audio-performance-debug"><img src="https://agentmods.dev/badge/skills/kunitoki/sonic-skills/audio-performance-debug/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kunitoki/sonic-skills/audio-performance-debug"><img src="https://agentmods.dev/badge/skills/kunitoki/sonic-skills/audio-performance-debug.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00099 | $0.01037 |
| Opus 5.5 | $0.00040 | $0.00415 |
| Sonnet 5.5 | $0.00020 | $0.00207 |
| Haiku 4.5 | $0.00010 | $0.00104 |
Grade A, and why
audio-performance-debug scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Audio Performance Debug
Audio performance requires good worst-case complexity, not average-case — the audio thread fires on a hard deadline every buffer, regardless of what else is happening.
Step 1 — Identify the symptom
Measure before guessing. Different symptoms point to different root causes.
| Symptom | Measurement approach |
|---|---|
| Consistent high CPU average | CPU meter in DAW; perf stat / Instruments Time Profiler |
| Sporadic xruns / dropouts | Host xrun log; correlate with system events (GC, network, page fault) |
| CPU spikes on note-on | Profile with many simultaneous note-on events; watch for allocation spikes |
| Latency reporting wrong | Log getLatencySamples() before and after prepareToPlay at varying buffer sizes |
| Gets worse with more voices | Profile with 1 vs 8 vs 32 voices; O(N²) shows quadratic growth |
| Memory bandwidth pressure | perf mem / VTune memory bandwidth counter; cache miss rate |
Step 2 — Locate the hotspot
- Build a release (optimized) binary before profiling — debug builds are not representative.
- Use a reproducible test case: fixed buffer size, fixed voice count, looped audio.
- Attach a profiler to the audio thread specifically, not the whole process.
- Identify the top-3 hottest functions by exclusive CPU time, not inclusive.
- Check whether the spike is periodic (every N buffers → container rehash or GC) or random (OS jitter, page fault).
| Platform | Profiler | Notes |
|---|---|---|
| macOS | Instruments — Time Profiler | Filter to audio I/O thread; use "hide system libraries" to focus on your code |
| macOS | Instruments — Allocations | Catch allocations on the audio thread during a session |
| Linux | perf record -g + perf report |
--call-graph dwarf for C++ templates; perf stat for cache miss ratio |
| Windows | VTune Profiler — Hotspots | Use "Platform Profiler" preset; filter to realtime thread |
| Cross-platform | Tracy | Frame-level instrumentation; zero-cost when disabled; shows per-buffer timing |
| JUCE | juce::PerformanceCounter |
Inline timer around suspect blocks; logs to console |
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 63 lines · 99 tokens per session scan A 259cd476f47f
audio-performance-debug is a skill published in the GitHub repository kunitoki/sonic-skills (22 stars, last pushed 4mo ago), licensed Unlicense. It adds 99 tokens to every session and 1,037 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
triage-issue
Verify an issue, persisted audit finding, or unresolved review finding against current code, classify it, and write only the contracted forge/ledger outcome. Supports independent batches and an immediate-fix review-finding route. Triggers: "triage-issue", "triage issue N", "triage this finding", "is this trigger met".
chrome-devtools-axi
Use the chrome-devtools-axi CLI to operate Chrome or investigate live page behavior. Default for ad hoc browsing, forms, rendered extraction, screenshots, DOM/CSS, console/network failures, responsive behavior, and performance or memory questions. Excludes static-only fetching, direct-MCP-only requests, explicitly…
project-platform-diagnose
Diagnostic project overlay for environment-dependent build, install, startup, CI, container, headless, terminal, or runtime failures. Not for ordinary logic bugs or known release packaging changes.
spark-engineer
Use when writing Spark jobs, debugging performance issues, or configuring cluster settings for Apache Spark applications, distributed data processing pipelines, or big data workloads. Invoke to write DataFrame transformations, optimize Spark SQL queries, implement RDD pipelines, tune shuffle operations, configure…
debugging-wizard
Parses error messages, traces execution flow through stack traces, correlates log entries to identify failure points, and applies systematic hypothesis-driven methodology to isolate and resolve bugs. Use when investigating errors, analyzing stack traces, finding root causes of unexpected behavior, troubleshooting…
reproduce-and-fix-issues
Reproduce triaged Slack bugs through a configured app-control adapter, verify existing fixes, and open a bounded draft pull request only after before-and-after proof. Use only from the configured Benny repro automation.