livepilot-mix-engine — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited livepilot-mix-engine (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The mix engine runs an iterative critic loop: analyze, plan, execute, measure, evaluate, keep or undo. Every mix change is measured before and after. Nothing stays unless it scores better than the original.
Do not treat the full loop as the default for vague requests like "make it better", "more character", "more alive", "punchier", "warmer", or "more interesting". Those are usually sound-design or creative-direction requests. Start from analyzer character (sonic_character, get_spectral_shape, get_novelty, get_onsets, get_mel_spectrum) and prefer source, instrument, device-chain, envelope, filter, saturation, modulation, and transient-shape decisions before generic level changes.
Use set_track_volume, set_track_pan, and broad send-level balancing only when the user explicitly asks for balance/level/pan/send work, or when analyzer evidence shows a safety/translation problem such as clipping, headroom collapse, mono collapse, or a severe masking issue. Producers can adjust simple loudness by ear quickly; LivePilot's value is in hearing spectral character and choosing a smarter musical intervention.
For normal work, cap mix-engine action to one high-value move plus a short verdict. Enter the repeated full loop only for explicit requests like "deep mix pass", "mastering prep", "fix all mix issues", or an exact target such as LUFS/headroom/mono compatibility.
Follow these steps in order. Do not skip the evaluation step.
Call analyze_mix or get_mix_issues to build a MixState and run all critics against the current session. The response contains an issues array, each with a critic, severity, track_index, and evidence dict.
If the M4L analyzer bridge is absent, critics fall back to role-based heuristics only (track names, device chains, volume/pan positions). Inform the user that spectral analysis is unavailable and recommendations are less precise.
For detailed frequency collision data, call get_masking_report. For a quick status overview without the full critic pass, call get_mix_summary.
Pick the highest-severity issue from the issues array. Call plan_mix_move with the issue data. The planner returns the smallest intervention that addresses the problem — a single parameter change, not a chain of edits.
Read the move object: it contains move_type, target_track, target_device, target_parameter, target_value, and rationale. Consult the move vocabulary in references/mix-moves.md for parameter ranges.
Take a measurement snapshot before executing anything:
get_master_spectrum — save the 9-band spectral data (sub_low → air)get_master_rms — save the RMS and peak valuesOptionally call get_mix_snapshot if you need per-track volume/pan/send state for the evaluation.
Execute the planned move. Use the appropriate tool for the move type:
set_device_parameter for EQ cuts/boosts, compressor thresholds, saturation drivesset_track_volume for gain stagingset_track_pan for stereo placementset_track_send for bus routing levelstoggle_device for bypassing/enabling processorsbatch_set_parameters when the move requires multiple related parameter changes on the same deviceExecute exactly one move. Do not chain multiple interventions before measuring.
Repeat the same measurements from Step 3:
get_master_spectrum — save the post-change spectral dataget_master_rms — save the post-change RMS and peak valuesCall evaluate_mix_move with the before and after snapshots:
evaluate_mix_move(
before_snapshot: { spectrum: [...], rms: float, peak: float },
after_snapshot: { spectrum: [...], rms: float, peak: float },
targets: { ... }, # what the move aimed to improve
protect: { ... } # what must not get worse
)Read the response: keep_change (bool), score (0.0-1.0), improvements (list), regressions (list), explanation (string).
If keep_change is false, call undo() immediately. Tell the user what was tried and why it was reverted, citing the regressions list.
If keep_change is true, report the improvement to the user with the score and explanation.
If the move scored above 0.7 and the user confirms satisfaction, call memory_learn(name="...", type="mix_template", qualities={"summary": "..."}, payload={...}) to save the technique for future recall.
Return to Step 1 and re-analyze only when the user requested a deep/full mix pass. Otherwise stop after the first measured high-value intervention and report the remaining optional issues as suggestions. Avoid spending a turn on small volume-balancing loops unless they are the requested task.
Not every request needs the full loop:
get_mix_summary for a one-shot status report with no changesget_masking_report for detailed per-pair frequency collision dataget_mix_issues for the critic list without executing any fixesSix critics run during analysis. See references/mix-critics.md for thresholds and evidence format:
The planner draws from six move types. See references/mix-moves.md for parameter ranges:
The mix engine works in two modes:
Call get_capability_state to check which mode is active before starting the loop.
Beyond get_master_spectrum / get_master_rms / get_detected_key, the analyzer domain exposes six more measurements that give finer evidence than the 9-band spectrum alone. Use them when the standard snapshot is too coarse for the move you are evaluating:
get_detected_key alone.All six are bridge-dependent — they return helpful errors if the analyzer is not on master. They do not replace the before/after snapshot pattern; they enrich what "snapshot" means when the move warrants it.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.