I Did Not Need an Audio Factory. I Needed One Safe Voiceover Command.

Draft for team review. This article is not approved for external posting.

The first time I asked an AI coding tool to help with text-to-speech, I was tempted by the usual shortcut: “Make it work.” A voice, some text, an MP3—how hard could it be?

That is exactly the moment to slow down.

An API key is not just a bit of configuration. It is authority to use an account, potentially spend money, and send text to a third-party service. A convincing audio file is not a release decision. The useful first project is smaller: make one voiceover command whose boundaries are clear enough for a person to inspect.

Start with an agreement, not code

Before a coding agent changes a file, write down what the tool is for. Mine might be: “Create a 10–20 second voiceover from an approved voice and an original script.” That is enough.

Then make the command explicit:

voiceover --voice <approved-slug> (--text <text> | --text-file <path>) --out <path>.mp3 [--force] [--dry-run]

The shape matters. It makes a person choose a voice, supply one clear text source, and name where the output will go. It also gives the tool useful reasons to refuse: an unknown voice, missing text, conflicting text inputs, no output path, or an accidental overwrite.

Treat the key as a boundary

The safest beginner pattern is not exotic. Keep the real provider key in a local ignored .env file. Keep a value-free .env.example in the project so another contributor knows the variable name, but never sees the value.

The key should not appear in code, prompts, logs, screenshots, receipts, exported pages, or browser JavaScript. If a key escapes that boundary, the right next move is not embarrassment or concealment. It is rotation or revocation.

Learn from failure before a live request

Before paying for an audio request, test the command’s failure paths. Ask it to run without an output file. Give it both a text string and a text file. Name a voice that is not approved. Try to overwrite a file without the deliberate override. Confirm that it fails plainly and without revealing the credential.

This is not bureaucracy. It is how you find out whether the tool has a useful contract or merely happens to work on its happiest path.

Make one small recording, then listen like a human

With a spending alert in place, synthesize a short original, fictional, public-domain, or otherwise authorized script. Listen from beginning to end. Keep a secret-free record of the selected voice, provider/model label, duration, output name, and your assessment.

The listening note matters because no provider can decide whether the delivery fits the audience, whether the script is accurate, whether a caption or transcript is required, or whether the output should be used at all.

Keep the next idea in the right lane

Once a small command works, it is natural to imagine a voice-audition site, a library of clips, or voice cloning. Those are different projects with different risks.

A static audition page can compare pre-generated clips and help a human make a documented choice. It should not contain provider credentials or generate audio in a browser. Voice cloning raises consent, disclosure, impersonation, retention, revocation, and rights questions that deserve their own decision before a learner ever uploads a sample.

The practical lesson is simple: start with the smallest skill that makes its authority visible. Let the MP3 be evidence that a request completed—not proof that the system is finished or that a human has approved what comes next.

Review needs: current provider details, secrets-practice, accessibility, learner-pilot evidence, and an editor’s review before publication.

---

Source: labs/build-a-safe-text-to-speech-skill/companions/article-medium-draft.md