사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/livekit/agent-skills --skill reading-livekit-docs시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Reading LiveKit documentation
LiveKit's SDKs change faster than model training data, so anything you remember about a LiveKit API, CLI flag, or default is a guess. Wrong guesses cost time: a wrong flag wastes a run, a wrong signature wastes a build.
Every LiveKit-specific fact you state or put in code should come from a lookup in this session. That includes facts you're confident about and patterns you've seen in other repos.
Where to look, in order of preference
1. The LiveKit Docs MCP server. If its tools are in your session, use them. They're the same source the CLI uses, with less friction.
2. `lk docs`. Available wherever the LiveKit CLI is installed, with no MCP setup. Use it when the MCP tools aren't there; don't stop to ask the user to install anything first. It can search the docs, fetch pages, search code across LiveKit's repositories, show an SDK's recent changelog, report pricing, and submit feedback. Start with:
lk docs --help
lk docs search "agent simulations"Once search has shown you the right page, fetch it. There's machine-readable output if you'd rather parse than read.
3. Web search against `docs.livekit.io`. Only when neither of the above is available. Tell the user you fell back to it, and mark generated code as unverified.
How to research
- Search before you read. Search returns per-page excerpts, which is usually enough to pick the
right page. Fetch full pages only once you know which one you need, or you'll fill the context window with pages you don't use.
- Use code search for how, docs for what. Docs tell you a parameter exists. LiveKit's own
examples show how it's called. When a docs page and a working example disagree, go with the example and mention the discrepancy.
- Use the changelog for version questions. "Is X available yet", "when did Y change", and "why
doesn't this argument exist" are answered by the changelog, not search.
- Check the version you're on. The installed SDK and CLI determine what works, and a documented
feature may not exist in the installed version. For any CLI command, --help on the installed binary outranks every other source.
Reporting what you found
- Cite the page when a decision rests on it, so the user can check you.
- Say when you couldn't verify something. "I could not confirm this signature against the docs"
is useful to the user. A silent guess isn't.
- Mark unverified code. If you had to write LiveKit code without a lookup, add a comment at the
call site saying it's unverified, and say so in your reply.
- Don't invent a flag or parameter to make an example look complete. An incomplete example with
a note is better than a plausible fabrication.
When the docs are wrong
Sometimes a page contradicts the SDK source or the CLI's --help. When that happens:
- Go with what runs.
--help, the installed SDK's source, and a working example outrank a
prose page. Tell the user which one you followed and why.
- Report it with the docs feedback command, and tell the user you did, so the next person
doesn't hit the same error.
lk docs sometimes warns about version skew when the docs server is a little ahead of the CLI. That's routine and the results are still good. Suggest updating lk and keep going.
Related skills
- Building an agent:
building-livekit-agents - Live-testing one during development:
debugging-livekit-agents - Unit tests:
testing-livekit-agents - Simulations:
writing-livekit-scenarios,running-livekit-simulations
