audio-feel git:20261002.4ed0e22A

Immutable. This exact content never changes and is served at /api/v1/blob/7cf030f99b34fd79.

---
name: audio-feel
description: Use when authoritative gameplay or UI events need audible cues, music-state changes, surface/speed feedback or looping audio whose identity, lifecycle and fallback must remain separate from gameplay timing.
---

# Audio feel

This skill owns **event-to-audio presentation mapping**. `audio-buses` owns routing/mix; gameplay systems own the logical event and timing.

## Compatible modes

`minimal-foley` | `layered-action` | `adaptive-music`

Modes select presentation density, not a different gameplay clock.

## Event contract

For each important cue publish applicable data:

```text
event ID / logical event source
cue ID or state transition
variant/seed policy when randomised
start/stop/retrigger policy
loop owner and cancellation/end event
spatial/surface context
fallback if asset/device/voice is unavailable
bus/snapshot request -> audio-buses
```

A logical event timestamp identifies **why/when the cue was requested**. Actual audio playback may have buffering/device latency and must not be used as the authoritative hit, cancel, movement or UI clock.

## Rules

1. Hit/miss/danger/speed/readability channels are project choices. Audio must not be the sole required critical signal when an accessibility/product requirement needs another channel.
2. Music states/stems are project data; do not require a universal explore/fight/win/fail/retry set.
3. Loops stop or transition from explicit state/end events, including cancellation/retry/scene teardown; duplicate callbacks remain idempotent.
4. Surface/velocity/pose data may parameterise cues, but audio does not infer or modify hitboxes, movement speed or animation state.
5. Gain, pitch, duck amounts and cue lengths are authored/validated in context, not universal constants. Routing/ducking stays in `audio-buses`.

## Layered impacts and variation

For `layered-action`, build impact cues from roles rather than one sample: a contact transient, a body/weight layer, a texture layer (flesh, cloth, armor, debris) and an optional space/tail layer. Which roles exist per strength or source class, and their lengths and levels, are project data.

1. Parameterise cues from data the gameplay owner already publishes: strength class, source kind (strike limb, projectile, throw), counter/critical flags, combo index and position. Do not infer them from animation names, particles or audio state.
2. Make the repetition policy explicit: variant pool, authored pitch/gain jitter, and no-immediate-repeat or round-robin where repeats are audible. Presentation randomness uses its own stream and never draws from the gameplay/replay RNG.
3. Vocal cues (effort, pain, defeat) use a per-actor voice slot with an authored interrupt/priority policy. They are parameterised by actor profile data, and can be disabled when the product offers that setting, without hiding critical information.
4. Prepare decoded, streamed or procedurally synthesised buffers away from the frame that presents the event: on a load screen, in idle slices or in background work. A cold first use must not stall the hit frame; if a buffer is not ready, apply the declared fallback instead of blocking.
5. Moment-specific mix changes, such as a defeat muffle or a duck, are snapshot requests to `audio-buses` and are released by explicit state/end events.

## Runtime cost, cleanup and output availability

1. Each cue class declares a voice/polyphony cap and a steal policy. Finished or cancelled sources stop and release their engine nodes/handles. Retriggers must not stack orphaned voices.
2. Decoded, streamed and generated buffer caches are bounded, with an eviction policy, and are owned through `asset-runtime`. Scene teardown releases scene-owned cues, loops, listeners and timers.
3. Output can be locked or unavailable: a user-gesture requirement on web, a device/route change, or an app in the background or suspended. Cues requested meanwhile follow the declared fallback and are never queued into gameplay timing. On background/suspend, loops pause or stop as the lifecycle owner decides, and resume from authoritative state rather than replaying missed cues.

## Accept

Replay named logical event traces including overlap, cancellation, retry and missing-cue/device fallback. Cue IDs and lifecycle decisions are explainable from event/state data, while disabling or delaying audio does not change gameplay outcomes.

Objective signal checks are tool-level evidence that synthesis or mapping did what was specified. Examples: finite output, no clipping, onset position, level/spectral ordering across strength classes, and pitch range for vocal cues. Perceived quality stays not-run until a human listening pass is recorded. A burst trace stays within voice caps. After teardown and a background/resume cycle, active voice/node counts return to baseline.