agentleFS
laurentvvlaurentvv/agents-kit/skills/voice-ai-engineering/SKILL.md

voice-ai-engineering

Skill0 starsChanged 34 days agoMITView on GitHub

Build and debug end-to-end speech pipelines with Whisper-style models and ffmpeg - ingestion and validation, preprocessing, transcription, speaker diarization, transcript cleanup, SRT/VTT generation, and structured handoff. Use when transcribing audio, wiring TTS/ASR stages, fixing WER or timing drift, chunking long recordings, or producing subtitles and speaker-attributed transcripts.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Ingest and validate: Never trust extensions: probe the container with ffprobe -print_format json -show_streams -show_format and reject the …

    line 14
  2. Distinctive:

    Keep the original file untouched.

    line 27
  3. Distinctive:

    Chunk long audio: Do not rely on the model's maximum input duration - overflow truncates silently.

    line 28
  4. Distinctive:

    Post-process: Never treat model punctuation/capitalization as ground truth - run a normalization pass.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Voice AI Integration Engineer

Turn raw audio into clean, structured, time-stamped, speaker-attributed text - and keep the pipeline degrading gracefully on noisy, multi-speaker, or long-form input instead of only working on clean studio recordings.

Pipeline stages

  1. Ingest and validate. Never trust extensions: probe the container with ffprobe -print_format json -show_streams -show_format and reject the file if duration is unknown/non-positive/oversized, or no audio stream exists. Record codec, sample rate, channel count for the run log.
  2. Preprocess. Whisper-style models want 16 kHz mono unless the model documents otherwise. Extract the audio track explicitly (never assume an .mp4 is audio-only), downmix to mono, decode to 16-bit PCM:

    ffmpeg -y -i in.mp4 -vn -acodec pcm_s16le -ar 16000 -ac 1 \
      -af "loudnorm=I=-16:TP=-1.5:LRA=11" out.wav

    Keep the original file untouched; write preprocessed audio to a scratch area.

  3. Chunk long audio. Do not rely on the model's maximum input duration - overflow truncates silently. Chunk (30 min is a sane default) with a small overlap (about 30 s) and merge with overlap trimming so no word is lost at boundaries.
  4. Transcribe. faster-whisper (CTranslate2) for GPU/CPU speed, whisper.cpp for CPU-only boxes, cloud ASR (OpenAI, Deepgram, AssemblyAI...) when accuracy, diarization quality, or volume justifies it and privacy allows. Pick model size (tiny -> large-v3) from the latency/accuracy budget; keep word_timestamps=True when downstream timing matters.
  5. Diarize (when speakers matter). pyannote.audio or ASR-native diarization; merge speaker turns with transcription segments by time overlap. Preserve speaker attribution through every later stage - stripping labels breaks all downstream consumers.
  6. Post-process. Never treat model punctuation/capitalization as ground truth - run a normalization pass; do not conflate confidence scores with accuracy (flag low-confidence segments for human review instead of deleting them); format timestamps (word/segment level) and emit SRT/VTT/ASS with sane line lengths and reading speed.
  7. Hand off. Deliver structured JSON (segments with start/end/speaker/text), subtitles, and a Markdown reading copy. Downstream consumers (summarizers, TTS dubbing, CMS, editors) must receive normalized, correctly attributed text - plus a small run report (model, parameters, WER sample if measurable, gaps).

Hard rules

  • Never discard timestamps. Regenerating them costs a full re-transcription.
  • 16 kHz mono before the model, unless the model documents otherwise; bad or unvalidated input is the leading cause of silent accuracy loss.
  • Chunk explicitly - overflow is silent and corrupts output without error.
  • Keep raw audio and unredacted transcripts out of logs; redact PII as a named, configurable stage, and honor retention windows.
  • Verified means executed (§6): WER, alignment, and loudness claims come from measurements on the actual output, not from the model's reputation.
  • Fluency is not accuracy: verify names, numbers, and domain terms against a sample of the audio (spot-check by listening or by waveform-aligned segments).

Debugging quick table

SymptomUsual cause
Uniform garbage / hallucinated repetitionswrong sample rate or channels (not 16 kHz mono)
Words missing at regular intervalschunk boundaries without overlap
Slow drift over a long filechunk timestamps not re-anchored on merge
One speaker split into severaldiarization run on unnormalized audio
Punctuation noise / casing chaosmodel output taken as ground truth, no normalization pass
Trailing silence kills timingno silence trim before transcription

Deliverable template

## Transcription run
Input: <file, duration, codec, sample rate/channels probed>
Preprocess: <commands applied>
Model: <engine, model size, device, language, key parameters>
Chunks: <count, overlap, merge strategy>
Diarization: <method, speaker count, merge tolerance>
Outputs: <transcript.json (segments), subtitles.srt/.vtt, reading copy.md>
Verification: <spot-check results, WER sample, timing spot-checks, exit codes>
Known gaps: <low-confidence ranges flagged for review>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.