write-realtime-audio-code

Write Real-Time Audio Code

Use the host contract and a stated communication protocol to make callback-reachable code safe, bounded, and compatible.

When to Use

Apply this skill to an audio callback and all of its reachable code, including audio-to-UI paths, audio-related atomics and lifetimes, real-time verification, plugin parameters and state, event timing, smoothing, numerical behavior, and host-independent cores.

Do not activate it only because a change has a queue, an atomic, DSP mathematics, GUI code, server concurrency, or offline processing. Shared code remains in scope when a real-time callback reaches it. Check a host-specific offline-rendering contract before treating that mode as non-real-time.

Core Constraints

An audio callback has bounded work only in the context of its host contract. Inspect transitive callees, notifications, payload copies, and final destruction. Prove that shared-memory access, state publication, storage reuse, aliases, and required output samples are legal. Preserve released identities, automation meaning, and host transitions. A race detector gives evidence about exercised access patterns; it does not measure deadline compliance.

Read the Callback Contract First

Record these facts before choosing an implementation or review conclusion:

• The host API, lifecycle phase, symbolic thread, and any render workers.
• Buffer layouts, sample formats, aliases, lifetimes, legal block sizes, and required output behavior.
• Pending-event and process-status obligations, including reset, flush, and deactivation.
• Whether processing is real-time or an explicitly supported offline mode.

Use the downstream project's existing conventions to record relevant entry points and boundaries. Do not require a new thread annotation on every function.

Workflow

1. Establish whether the request is a review, plan, or authorized implementation. In review and plan modes, produce findings or proposed checks without editing the downstream project, installing tools, running mutation experiments, committing, publishing, or automatically invoking companion skills that perform such actions. Existing authorization governs implementation and experiment actions; do not ask again for actions already authorized.
2. Map the changed callback call graph, lifecycle, shared storage, and host-facing transitions.
3. Read the essential checklist, then select the detailed references that answer the remaining questions.
4. Record protocol assumptions, source and toolchain scope, capacity and work bounds, and failure policies.
5. For authorized implementation or experiments, use an instrument and a positive control suited to the claim. For a review, distinguish observed evidence from proposed checks.
6. Report what remains unverified, including paths, hosts, workers, loading arrangements, and tools that were not exercised.