1. Read this entire skill document - Do not skip sections even if MCP is available
2. Ensure LiveKit Cloud project is connected - You need

   LIVEKIT_URL

   ,

   LIVEKIT_API_KEY

   , and

   LIVEKIT_API_SECRET

   from your Cloud project
3. Set up documentation access - Use MCP if available, otherwise use web search
4. Plan to write tests - Every agent implementation MUST include tests (see testing section below)
5. Verify all APIs against live docs - Never rely on model memory for LiveKit APIs

• Managed infrastructure (no servers to deploy)
• LiveKit Inference for AI models (no separate API keys needed)
• Built-in noise cancellation, turn detection, and other voice features
• Simple credential management

1. Sign up at cloud.livekit.io if you haven't already
2. Create a project (or use an existing one)
3. Get your credentials from the project settings:

   • LIVEKIT_URL

     - Your project's WebSocket URL (e.g.,

     wss://your-project.livekit.cloud

     )

   • LIVEKIT_API_KEY

     - API key for authentication

   • LIVEKIT_API_SECRET

     - API secret for authentication
4. Set these as environment variables (typically in

   .env.local

   ):

LIVEKIT_URL=wss://your-project.livekit.cloud
LIVEKIT_API_KEY=your-api-key
LIVEKIT_API_SECRET=your-api-secret

• No separate API keys to manage for each AI provider
• Billing consolidated through your LiveKit Cloud account
• Optimized for voice AI workloads

• Never assume API signatures, method names, or configuration options from memory
• Never guess SDK behavior or default values
• Always verify against live documentation before writing code
• Always cite the documentation source when implementing features

livekit-docs

• Search documentation before implementing any feature
• Verify API signatures and method parameters
• Look up configuration options and their valid values
• Find working examples for the specific task at hand

1. Inform the user immediately that documentation cannot be verified in real-time
2. Use web search to fetch current documentation from docs.livekit.io
3. Explicitly mark all LiveKit-specific code with a comment like

   # UNVERIFIED: Please check docs.livekit.io for current API

4. State clearly when you cannot verify something: "I cannot verify this API signature against current documentation"
5. Recommend the user verify against https://docs.livekit.io before using the code

• Minimize LLM context size to reduce inference time
• Avoid unnecessary tool calls during active conversation
• Prefer streaming responses over batch responses
• Design for the unhappy path (network delays, API timeouts)

• Include only tools relevant to the current conversation phase
• Keep system prompts focused and concise
• Remove tools and context that aren't actively needed

• Long responses frustrate users—keep outputs concise
• Users cannot scroll back—ensure clarity on first delivery
• Interruptions are normal—design for graceful handling
• Silence feels broken—acknowledge processing when needed

• Tools for every possible action (bloated tool list)
• Instructions for every conversation phase (bloated context)
• State management for all scenarios (complexity)

• Separate distinct conversation phases (greeting → intake → resolution)
• Isolate specialized capabilities (general support → billing specialist)
• Manage context boundaries (each agent has only what it needs)

• Discrete operations that don't require full agent capabilities
• Situations where a focused prompt outperforms a general-purpose agent
• Reducing context when only a specific capability is needed

1. Create a

   tests/

   directory if one doesn't exist
2. Write at least one test before considering the implementation complete
3. Test the core behavior the user requested
4. Run the tests to verify they pass

project/
├── agent.py (or src/agent.py)
└── tests/
    └── test_agent.py

1. Define what the agent should do in specific scenarios
2. Write test cases that verify this behavior
3. Implement the feature
4. Iterate until tests pass

• Basic conversation flow: Agent responds appropriately to a greeting
• Tool invocation (if tools exist): Tools are called with correct parameters
• Error handling: Agent handles unexpected input gracefully

• Tool invocation: Does the agent call the right tools with correct parameters?
• Response quality: Does the agent produce appropriate responses for given inputs?
• Workflow transitions: Do handoffs and tasks trigger correctly?
• Edge cases: How does the agent handle unexpected input, interruptions, silence?

search: "livekit agents testing"

• Simulated user input
• Verification of agent responses
• Tool call assertions
• Workflow transition testing

• Prompt changes silently break behavior
• Tool descriptions affect when tools are called
• Model updates change response patterns

"I've built the agent without tests as requested. I strongly recommend adding tests before deploying to production. Voice agents are difficult to verify manually and tests prevent silent regressions."

• API method signatures and parameters
• Configuration options and their valid values
• SDK version-specific features or changes
• Deployment and infrastructure setup
• Model provider integration details
• CLI commands and flags

• Architectural approach and design principles
• Workflow structure decisions
• Testing strategy
• Common pitfalls to avoid

1. Use LiveKit Cloud + LiveKit Inference as the foundation—it's the fastest path to production
2. Verify everything against live documentation—never trust model memory
3. Minimize latency at every architectural decision point
4. Structure workflows using handoffs and tasks to manage complexity
5. Test behavior before and after changes—never ship without tests
6. Keep context minimal—only include what's needed for the current phase