Build a Safe Text-to-Speech Skill
Use a coding agent as a planning and implementation partner to make one small, reviewable text-to-speech skill. The learner defines the tool's boundary before code exists, protects a personal provider credential, tests failure paths before a live request, and keeps a human responsible for the audio that is used.
Related labs
Try the idea in practice
Relationships
Connect it to the learning map
Primary track: Agentic Coding
Helpful preparation: Prompting Is the Door, Not the Destination
Share and review
Help improve the module
Purpose
Use a coding agent as a planning and implementation partner to make one small, reviewable text-to-speech skill. The learner defines the tool’s boundary before code exists, protects a personal provider credential, tests failure paths before a live request, and keeps a human responsible for the audio that is used.
This is not a vendor tour or an invitation to automate publishing. Speechify is the v1 reference provider because it is an existing, tested workspace path; the command contract should remain portable enough to change providers later.
What learners can do
By the end, a learner can:
- Turn a practical voiceover need into a small, testable skill plan.
- Ask Codex, Claude Code, or another coding agent to explain assumptions before implementation.
- Keep an API credential out of source, prompts, logs, screenshots, exports, and static websites.
- Run dry-run and negative tests before one short, budgeted live synthesis test.
- Choose a voice deliberately, inspect the audio, and retain a secret-free generation record.
- Explain why voice selection and voice cloning require different human review boundaries.
The staged path
1. Create the skill
The learner writes and reviews a plan before asking an agent to edit files. The plan names the purpose, command-line contract, voice-selection rule, text-input rule, output ownership, provider adapter, budget limit, secret boundary, failure behavior, and tests.
The first implementation uses an explicit command shape:
voiceover --voice <approved-slug> (--text <text> | --text-file <path>) --out <path>.mp3 [--force] [--dry-run]The command must reject missing or conflicting text inputs, an unknown voice, a missing output path, an existing output without --force, and an absent credential. It must not print a credential.
2. Use the skill
The learner generates one practical, low-risk voiceover with an explicitly selected voice and an explicit output path. They listen for clarity and fit, retain a short recipe and a secret-free receipt, and decide whether the output is usable. The tool can produce audio; it does not decide whether the audio is appropriate.
3. Build a human voice-audition website
The next chunk is a static comparison site with pre-generated clips. A reviewer listens, rates, notes concerns, selects candidates, and exports a Markdown or JSON decision brief. No browser-side synthesis, provider client, or credential belongs in the published site.
4. Keep voice cloning at idea status
Voice cloning is not a lab activity in this module. Before it can become one, the Lab needs a separate decision about informed consent, voice ownership and rights, disclosure, impersonation prevention, storage and retention, revocation, review, and provider terms. No learner should be asked to clone a voice in this Draft.
Secrets are a practical boundary
The recommended first-lab pattern is an ignored local .env file with the learner’s own key and a committed .env.example that contains variable names only. The key is loaded at runtime; it is never pasted into a chat, copied into a skill, or committed.
| Situation | Appropriate pattern | What never changes |
|---|---|---|
| One learner on one machine | Ignored local .env plus value-free .env.example |
Do not share, commit, log, or screenshot the key. |
| Portable team workflow | SOPS + age encrypted secret file with just-in-time injection | Keep the decryption identity outside Git and limit who can use it. |
| Deployment or CI | The hosting or CI platform’s secret store injects the value only for the required job/service | Never send the secret to a browser bundle or static output. |
Each learner uses their own provider account, sets a low spending limit or alert before the live test, and treats accidental exposure as a rotation/revocation event—not as something to hide or repair by deleting a chat message.
Primary lab
Boundaries and status
Use only original, public-domain, fictional, or otherwise authorized short scripts. Do not place personal, client, medical, legal, financial, or confidential material in a provider test. Do not distribute a shared class API key. A valid MP3 proves only that a request completed; human listening and review decide whether it may be used.
This is a complete Draft package. It needs a learner pilot, a secrets-practice review, accessibility review, and confirmation that the provider-specific steps remain current before becoming learner-available.
Review status
- Package lifecycle: Draft
- Learner availability: Drafting
- Review needs: Complete Draft package; needs learning-design, secrets-practice, accessibility, and learner-pilot review
Source: modules/build-a-safe-text-to-speech-skill/module.md