Facilitator guide: Build a Safe Text-to-Speech Skill

Labs reference: Facilitator guide: Build a Safe Text-to-Speech Skill.

Suggested session: 105 minutes: 15-minute boundary and plan review, 20-minute secret setup and dry-run tests, 30-minute implementation, 15-minute small live acceptance test, 15-minute listening and audition-site brief, and 10-minute cloning-idea debrief.

Preparation

Confirm that the group understands this is a local learning project, not a shared production account. Ask learners to create their own provider account only if they want the live finish; provide an observer or mock path for learners without an account, budget, or comfort level. Do not collect API keys, ask learners to paste them into chat, or create a communal .env file.

Have the planning worksheet, secrets checklist, and prompt recipes available in accessible text. Confirm the current provider documentation separately before the session; provider models, names, quotas, and billing can change. Prepare a fictional short script and a pre-generated example MP3 for learners who cannot perform live synthesis.

Facilitation priorities

  • Start with the plan. A coding agent should name its assumptions before it edits a learner project.
  • Treat keys as spend authority. A key is not a classroom handout, prompt ingredient, or troubleshooting artifact.
  • Keep the code small. A clear command, a local voice record, a provider adapter, and tests are enough.
  • Require a dry run and negative tests before the one intentional live request.
  • Treat a valid file as technical evidence only. Listening, appropriateness, disclosure, and release remain human decisions.
  • Keep the Voice Auditions chunk static and human-in-the-loop. Do not broaden the lab into a hosted service or web application.

Common difficulties

  • The agent starts coding without a plan: pause it. Ask for the command contract, failure cases, and secret boundary in plain language first.
  • A learner wants to paste a key into a prompt: stop. Use the local .env file and a runtime environment reference instead; never ask to see the value.
  • The .env ignore check is unclear: do not run a live request. Verify the repository status and ignore rule first.
  • The live request is more expensive than expected: stop after the first small sample, inspect provider spend settings, and return to the mock path.
  • The tool invents a voice name: require a stable local approved slug and a known provider voice identifier. Do not accept catalogue order as identity.
  • Audio is technically valid but unsuitable: let the listener reject it. The goal is judged output, not a successful API response.
  • Learners want to clone a voice immediately: keep the idea-note boundary. Consent, disclosure, revocation, and rights have not been reviewed in this package.

Evidence of learning

Look for a plan that names acceptance criteria, a value-free .env.example, an ignored .env, evidence of dry-run and negative cases, one small audio result or a documented mock result, a human listening note, and a static audition-site brief that excludes credentials and browser synthesis. Do not grade syntax, polished audio, or provider choice as the main evidence.

Accessibility and participation

Learners may be planner, terminal operator, test reviewer, documentation recorder, or listener. Provide a transcript for every example audio file and a non-live path using supplied mock output. Read commands and error categories aloud when useful. Avoid using color alone for status. A learner may complete the planning, testing, and review portions without creating an account, spending money, or sharing a voice.

Safety, privacy, and ethics

This is technical learning guidance, not legal, security, or financial advice. Use only authorized low-risk scripts. Do not circulate keys, voice samples, biometric material, private recordings, client text, or generated audio outside the learner’s stated purpose. A suspected key exposure means revoke or rotate the key and review where it traveled; do not attempt to conceal it by merely deleting a message or file. Voice cloning remains an idea status until a separate consent and governance review approves a limited pilot.

Provisional timing for facilitator planning

These inherited estimates are starting points for facilitation, not completion targets for learners. Refine them after observing setup, access needs, discussion, and actual participation.

  • Lab: 90–120 minutes (short: 45–60 minutes through dry run; extended: 2–3 hours including the static audition-site brief)

Source: labs/build-a-safe-text-to-speech-skill/facilitator-guide.md