transcribe

transcribe — A sharp, opinionated audio pipeline that knows when to talk back

The transcribe skill doesn't just hand you a microphone and walk away. It arrives with a clear philosophy: transcription is a deterministic, repeatable operation best handled by a bundled CLI, not ad‑hoc API calls. That opinion alone makes it worth a close look. In the cli-and-api cluster, where many skills treat the terminal as an afterthought, transcribe elevates the CLI to a first‑class artifact. It pairs naturally with skills like summarize (which expects clean text input) and extract (which often starts from spoken content), but it stands apart by owning the entire input‑to‑output lifecycle.

What makes the skill sharp is the way it carves decision boundaries. The SKILL.md doesn't just say “transcribe audio”; it defines exactly when to reach for gpt-4o-mini-transcribe (fast, no‑frills text) versus gpt-4o-transcribe-diarize (speaker labels, known‑speaker hints). It even warns that prompting is unsupported for the diarization model — a rare and valuable constraint that prevents wasted iterations. The output conventions (output/transcribe/<job-id>/) and the explicit --out-dir flag show someone has thought about how this skill will be used in batch or repeated runs.

Test observations ground the praise. The install-and-auth test passed cleanly: the openai package installs without friction, and the CLI catches a missing or invalid OPENAI_API_KEY gracefully. That’s the kind of robustness you want before you commit to a multi‑file transcription session. The rate-limit-handling test was only partial — the CLI does not implement backoff, so a 429 from OpenAI would surface as a raw HTTP error. That’s the one place where the skill’s opinionated simplicity becomes a liability: it assumes the network and the API will cooperate.

The three failed tests (list-or-read, write-or-mutate, and the partial rate‑limit) trace back to a single missing piece: no test audio file is provided, and the skill does not include a read‑only “list available files” operation. That’s a gap, but it’s a gap in the test harness, not in the skill’s design. The skill itself is self‑contained — it defines dependencies, environment variables, a CLI entrypoint, and output conventions. The lack of a built‑in test fixture is notable because it forces you to bring your own audio, which can slow down initial evaluation.

Where I’d reach for this skill: any project where you need to process a known set of audio files with consistent, repeatable output — meeting transcriptions, interview archives, or lecture notes. The diarization support with known‑speaker references is especially strong for post‑production workflows where you already have speaker samples. I would not reach for it in a streaming or real‑time context, nor in an environment where rate limits are a daily concern (unless you add your own retry wrapper). For a clean, scriptable audio‑to‑text pipeline with crisp decision rules, transcribe earns its place on the shelf.

Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-07-27.

Overall: partial. 0 tests passed, 1 partial, 3 failed; key blocker: no test audio file or API key provided, and the skill lacks built-in rate-limit handling.

Inferred dependencies: python>=3.10, openai, uv (optional), OPENAI_API_KEY.