Conversation
There was a problem hiding this comment.
Pull request overview
Adds an AGENTS.md guidance document intended for development agents working in the LiveKit C++ Client SDK repo, summarizing architecture, build flow, coding conventions, dependencies, testing, and pitfalls.
Changes:
- Introduces
AGENTS.mdwith project architecture notes and key internal/public types. - Documents recommended build and packaging commands, plus dependency/tooling expectations.
- Captures coding conventions (logging, public API boundaries, error handling) and testing guidance.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ## Build | ||
|
|
||
| Use `./build.sh` — always. Do not invoke CMake directly. | ||
|
|
There was a problem hiding this comment.
The guidance says to use ./build.sh “always” and to not invoke CMake directly, but the repo also provides build.cmd for Windows (and the build guide describes both). Please clarify this instruction (e.g., “use build scripts: build.sh (Linux/macOS) / build.cmd (Windows)”, and when direct CMake use is acceptable).
There was a problem hiding this comment.
@copilot apply changes based on this feedback
| Adhere to the formatting rules if TODO: @alan | ||
|
|
There was a problem hiding this comment.
The Formatting section is currently a placeholder (“TODO: @alan”), which leaves agents without actionable guidance. Replace with concrete formatting instructions (e.g., clang-format invocation/config) or remove the section until it’s defined.
| Adhere to the formatting rules if TODO: @alan | |
| - Match the style of the surrounding code and keep formatting changes limited to the files you touch. | |
| - Use consistent indentation, spacing, and brace style with nearby C++ headers, sources, CMake files, and Markdown. | |
| - Keep `#include` ordering and whitespace consistent with the existing file rather than reformatting unrelated code. | |
| - If the repository or your editor provides formatting configuration, run it before submitting changes; otherwise prefer minimal, manual formatting-only edits. |
| When making larger scale changes, check with the developer before committing to architecture changes involving changes to the `client-sdk-rust/` submodule. | ||
|
|
||
| ### Directory Layout | ||
|
|
||
| | Path | Description | | ||
| |------|-------------| | ||
| | `include/livekit/` | Public API headers (what SDK consumers include) | | ||
| | `src/` | Implementation files and internal-only headers (`ffi_client.h`, `lk_log.h`, etc.) | | ||
| | `src/tests/` | Google Test integration and stress tests | | ||
| | `examples/` | In-tree example applications | | ||
| | `bridge/` | **Deprecated** C-style bridge layer — do not add new functionality | | ||
| | `client-sdk-rust/` | Git submodule — **read-only, never modify** | | ||
| | `client-sdk-rust/livekit-ffi/protocol/*.proto` | FFI contract (protobuf definitions, read-only reference) | |
There was a problem hiding this comment.
The document says client-sdk-rust/ is “read-only, never modify”, but also advises checking with a developer before “committing to … changes involving changes” to that submodule. Consider clarifying the intended workflow (e.g., submodule bumps are allowed via updating the pointer, but no direct edits inside the submodule).
There was a problem hiding this comment.
@copilot apply changes based on this feedback
| When adding new client facing functionality, add benchmarking to understand the limiations of the new functionality. | ||
|
|
||
| ## Formatting | ||
| Adhere to the formatting rules if TODO: @alan |
There was a problem hiding this comment.
@alan-george-lk i wonder what the best way t provide this is. My reading on Agents.md leads me to believe we should just put code snippets directly inline. Does clang-tidy provide a list or would it be reasonable to ask cursor:
"Write me an AGENTS.md ## Formatting section which has code examples to be followed for clang-tidy cpp formatting" (or a better prompt)
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Overview
An AGENTS.MD file for guiding cursor on development inside the project
Key points
Any other points?