I Gave Claude Seven Personalities and Pointed Them at the SDLC

The first LiveCaster experiment proved that Claude Code's /loop command works as a cron-style backbone for live voice narration. One scenario. One persona. One voice. Ken Squier calling an AI model race.

That worked. So I did what any reasonable person would do: I gave it six more personalities and told each one to narrate a different phase of the software development lifecycle.

A rodeo announcer for code reviews. A mission control operator for production deploys. A war room coordinator for incident response. A pair programmer narrating a solo app build. And a two-person broadcast booth for CI pipeline races, complete with a technical anchor and an excitable field correspondent speaking through different TTS voices.

Watch the demo on YouTube.

Hypothesis

I expected a YAML-driven configuration layer to make the stateless-cron architecture generalize. Swap the YAML, swap the entire narration experience, without changing the core announcer slash command.

The variable I was really testing: does the LLM actually follow persona instructions well enough to produce distinct commentary across wildly different scenarios? Or does everything flatten into generic "sports announcer narrates a process" regardless of what the persona field says?

Setup

The Stack

Claude LiveCaster: the open-source slash command toolkit from the first experiment
Cursor: wrote the simulation engine and all 7 YAML scenario configs
Kokoro TTS: local text-to-speech, 8 voices across 7 scenarios
Python 3.9+: data-driven simulation script (scripts/simulate.py)

What Changed

The core announcer command (/livecaster-announce) reads livecaster.yaml from the project root each iteration. The first experiment hardcoded everything. This time I made the config do the heavy lifting.

Each scenario YAML file defines:

Contestants (who or what is competing, or solo subject)
Tasks (the work items being processed, with scenario-appropriate names)
Persona (multi-sentence prompt describing the announcer's character and style)
Voice (which Kokoro TTS voice to use, and at what speed)
Error messages (scenario-specific failures like "MERGE CONFLICT: 4 files conflict with main" or "ROLLBACK CONSIDERED: anomaly detected in checkout flow")

The simulation script (simulate.py) got a --scenario flag. Pass it a YAML path and it generates log output using that scenario's contestants, tasks, timing, and error profiles. Backward compatible. No flag means original defaults.

The Seven Scenarios

Races (multi-contestant):

Scenario	What Competes	Persona	Voice
AI Model Race	6 AI models (Claude, GPT, Gemini)	NASCAR race announcer	am_michael
Full-Stack Sprint	6 tech stacks (React, Next.js, SvelteKit, Remix, Nuxt, Astro)	Agile sprint commentator	am_adam
Pipeline Wars	6 microservice CI pipelines	Dual-voice broadcast (anchor + correspondent)	bf_emma + af_bella
Code Review Roundup	5 pull requests	Rodeo announcer	af_sky

Solo narrations (single process):

Scenario	What Happens	Persona	Voice
App Build Journey	Building a Next.js SaaS app from scratch	Encouraging pair programmer	af_heart
Deploy Day	Production deployment from staging to full rollout	Mission control operator	am_adam
Incident Response	P1 production incident from alert to resolution	War room coordinator	bf_isabella

Dual-Voice Mode

Pipeline Wars introduced a second TTS voice. Instead of a single voice key in the YAML, it uses a voices list:

yaml
voices:
  - role: "anchor"
    voice: "bf_emma"
    speed: 0.9
  - role: "correspondent"
    voice: "af_bella"
    speed: 0.95

The announcer detects this list, generates labeled commentary ([ANCHOR] / [CORRESPONDENT]), and speaks each section with the assigned voice. The anchor delivers measured factual updates. The correspondent reacts emotionally to failures and celebrates green builds.

Variables

Changed: The simulation scenario YAML (persona, contestants, tasks, voice, errors)
Controlled: Core slash commands, TTS pipeline, /loop scheduling, filesystem-backed state pattern

Results

Metric	Outcome
Scenarios that ran end-to-end	7 of 7
Distinct commentary styles observed	7 of 7 (each felt different)
Dual-voice label parsing	Consistent across all Pipeline Wars runs
Changes required to core announcer	Zero structural changes
Simulation engine backward compatibility	Maintained (no `--scenario` flag = original defaults)
Unique Kokoro TTS voices used	8 across 7 scenarios
Total lines added (PR #2)	~1,200 (7 YAMLs, updated simulate.py, updated slash commands)

Persona Fidelity Was the Surprise

I honestly expected the persona instructions to be a suggestion the LLM would half-follow. The opposite happened.

The rodeo announcer for Code Review Roundup actually used rodeo metaphors. "feat/auth-overhaul is trying to hang on through a nasty merge conflict" is exactly the kind of thing a rodeo commentator would say about a bronc ride. The war room coordinator for Incident Response stayed procedural and urgent without tipping into panic. "Root cause confirmed. Connection leak in the ORM layer. Hotfix is in staging now. Lets see if this holds." That reads like a real incident channel update.

The mission control persona for Deploy Day was my favorite. Treated canary percentage increases like orbital stage separations. "Canary at 25 percent. All systems nominal. Proceeding to 50." You could close your eyes and picture Houston.

Dual-Voice Actually Worked

I expected the labeled output to be brittle. It wasn't. The announcer consistently generated [ANCHOR] and [CORRESPONDENT] labels, and the text extraction held across every run I tested. The anchor stayed measured. The correspondent stayed excitable. The contrast made Pipeline Wars the most entertaining scenario of the seven.

Having two distinct TTS voices alternate added something I didn't anticipate: rhythm. The switch between bf_emma's BBC-anchor delivery and af_bella's animated correspondent created a cadence that single-voice scenarios don't have.

Solo Narrations Needed Different Thinking

Races have a built-in narrative: who's ahead, who's falling behind, lead changes. Solo narrations have none of that. There's one contestant progressing through tasks sequentially.

The personas handled this by shifting from competition to progression. The pair programmer in App Build Journey tracked milestones: "Auth is in place, the dashboard is looking great. Now we are wiring up Stripe." The mission control operator in Deploy Day built tension through the canary ramp. The war room coordinator in Incident Response tracked investigation phases: triage, diagnosis, mitigation, recovery.

The leaderboard command in the YAML adapts too. Races count completed tasks per contestant. Solo narrations show the last 8 completed steps instead. Same command template, different shell pipeline.

Takeaway

The persona YAML field is the real primitive. Not the voice. Not the simulation engine. Not the cron scheduling.

In the first experiment, I found that /loop with filesystem-backed state is a reliable architecture for Claude Code automations. This experiment found something built on top of that: a short natural-language persona prompt, embedded in YAML and read fresh each /loop iteration, is enough to produce genuinely distinct narration styles from the same code path.

That's the pattern worth paying attention to. You can ship a single announcer command and make it sound like seven completely different tools by swapping a config file. The architecture doesn't care whether it's narrating a CI pipeline race, a production deploy, or a P1 incident. It reads the persona, it reads the log, it speaks.

This maps to something bigger than voice announcing. Any recurring Claude Code automation that needs contextual awareness (code review bots, monitoring narrators, build commentators) can use the same trick: define the persona in config, let the slash command read it each iteration, and the LLM adapts.

What's Next

The seven scenarios cover a lot of SDLC ground, but they're all running on synthetic log data generated by the simulation script. Every task completes. Every error is scripted. The narration is convincing, but it's narrating a simulation.

Things I want to test:

Real CI pipeline narration: Point LiveCaster at an actual CircleCI pipeline log instead of synthetic data. Does the commentary hold up when the data is messy and unpredictable?
Custom scenario authoring: How fast can someone who's never seen LiveCaster create their own scenario YAML? The format is simple, but I haven't tested it with anyone else.
Longer dual-voice runs: Pipeline Wars worked in short simulations. What happens with a 30-minute dual-voice broadcast? Does the LLM maintain persona separation, or do the voices start to bleed together?
Three-voice mode: The architecture supports N voices in the voices list. An anchor, a color commentator, and a sideline reporter? This might be absurd. I want to try it anyway.

The open-source repo is here. Clone it, run /livecaster-simulate with-announcer, and pick a scenario. The whole thing runs locally, no API keys beyond Claude Code itself.

Ship it. 🎙️

This experiment was conducted as part of the Loop Lab program at CircleCI. It is a follow-up to /loop Gave Claude a Heartbeat. I Gave It a Microphone. The code lives at CircleCI-Research/claude-livecaster. Full demo: YouTube. PR: #2.