{"owner":"GetStream","repo":"Vision-Agents","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\n## Project overview\n\nPython monorepo managed with **uv workspaces**.\nThe core framework lives in `agents-core/` and plugins live in `plugins/` (37+ packages).\nPython >= 3.10, 3.12 recommended.\n\n## Commands\n\nAll commands use `uv`. Never use `python -m`. If you run into dependency issues, stop and ask.\n\n```bash\n# Full check (ruff + mypy + unit tests)\nuv run --no-sync dev.py check\n\n# Unit tests only (--no-sync avoids uv panic in sandboxed environments)\nuv run --no-sync pytest -m \"not integration\"\n\n# Integration tests (needs .env secrets)\nuv run --no-sync pytest -m \"integration\"\n\n# Lint & format\nuv run --no-sync ruff check .\nuv run --no-sync ruff format .\n\n# Type check\nuv run --no-sync mypy\n```\n\n## Testing\n\n- Framework: pytest. Never mock.\n- `@pytest.mark.asyncio` is not needed (asyncio_mode = auto).\n- Integration tests use `@pytest.mark.integration`.\n- NEVER adjust `sys.path`.\n- Keep unit-tests for the class under the same test class. Do not spread them around different test classes. For example, tests for `Agent` must be inside `TestAgent`, etc.\n- ALWAYS test behavior, not calling a path.\n- Use pytest.fixture for test setup, not helper methods\n- NEVER observe method calls in tests; assert on outputs and state.\n\n## Python rules\n\n- Never use `from __future__ import annotations`.\n- Prefer specific exceptions if they are known. If the exception type is not clear, it is ok to use `except Exception as e`.\n- Avoid `getattr`, `hasattr`, `delattr`, `setattr`; prefer normal attribute access.\n- Docstrings: Google style, keep them short.\n- Do not use section comments like `# -- some section --`\n- Prefer `logger.exception()` when logging an error with a traceback instead of `logger.error(\"Error: {exc}\")`\n- Do not use local imports, import at the top of the module\n- Avoid `# type: ignore` comments.\n- Avoid using `Any` type.\n- When adding code to an existing file, follow the patterns already established in that file (e.g. error handling style, import guards, naming).\n\n## Code style\n\n### Imports:\n\n- ordered as: stdlib, third-party, local package, relative. Use `TYPE_CHECKING` guard for imports only needed by type annotations.\n- Never import from private modules (`_foo`) outside of the package's own `__init__.py`. Use the public re-export (e.g. `from vision_agents.testing import TestResponse`, not\n  `from vision_agents.testing._run_result import TestResponse`).\n\n### Naming:\n\n- private attributes and methods use a leading underscore (`_sessions`, `_warmup_agent`). Public API is plain snake_case.\n\n### Type annotations:\n\n- use them everywhere. Modern syntax: `X | Y` unions, `dict[str, T]` generics, full `Callable` signatures, `Optional` for nullable params.\n\n### Logging:\n\nmodule-level `logger = logging.getLogger(__name__)`. Use `debug` for lifecycle, `info` for notable events, `error` for failures without a traceback,\n`exception` for errors with traceback.\n\n- In hot paths (audio processing, event handling), guard debug logging behind `if logger.isEnabledFor(logging.DEBUG):` to avoid formatting overhead when debug is disabled.\n\n### Constructor validation:\n\n- raise `ValueError` with a descriptive message for invalid args. Prefer custom domain exceptions over generic ones.\n\n### Async patterns:\n\n- async-first lifecycle methods (`start`/`stop`). Support `__aenter__`/`__aexit__` for context manager usage.\n- Use `asyncio.Lock`, `asyncio.Task`, `asyncio.gather` for concurrency.\n- Clean up resources in `finally` blocks.\n\n### Method order:\n\n- `__init__`, public lifecycle methods, properties, public feature methods, private helpers, dunder methods.\n\n### Other\n\n- Smallest possible diff. Prefer deleting code over adding it.\n- Don't add error handling, logging, validation, comments, abstractions, config options, or \"future-proofing\" I didn't\n  ask for.\n- Match the style and abstraction level of surrounding code. Don't introduce new patterns or helpers unless asked.\n- Fix root causes, not symptoms. No try/except to swallow bugs.\n- Change only what I asked for. Don't refactor adjacent code — ask first.\n- Do not remove valid comments when editing/refactoring code.\n\n## Plugins\n\n- In every `plugins/*/pyproject.toml`, the wheel target must be `packages = [\"vision_agents\"]`. Listing `\".\"` pulls `tests/`, `README.md`, `example/`, etc. into the published wheel.\n- Each plugin must keep `readme = \"README.md\"` in `[project]` and a `README.md` next to its `pyproject.toml` so PyPI renders a description page.\n\n## Token efficiency\n\n- When making multiple related changes to the same file, combine them into fewer Edit calls with enough surrounding context, rather than one edit per change.\n- Run tests with Bash directly. Only use subagents for test runs when you need to do other work in parallel.\n- Only use TodoWrite for tasks with 5+ steps. Don't update it after every individual edit.\n\n## Changelog\n\n- Lives in `CHANGELOG.md` at the repo root.\n- Organised by version heading (`# v0.4.0`), then sections: **Breaking Changes**, **New Features**, **Bug Fixes**.\n- Only include user-facing changes (public API breaks, features, fixes). Skip docs-only and CI-only commits.\n- Reference PR numbers inline, e.g. `(#374)`.\n- To generate: `git log <last-tag>..HEAD --oneline --no-merges`, then classify each commit.\n"},"files":{"CLAUDE.md":"# CLAUDE.md\n\n## Project overview\n\nPython monorepo managed with **uv workspaces**.\nThe core framework lives in `agents-core/` and plugins live in `plugins/` (37+ packages).\nPython >= 3.10, 3.12 recommended.\n\n## Commands\n\nAll commands use `uv`. Never use `python -m`. If you run into dependency issues, stop and ask.\n\n```bash\n# Full check (ruff + mypy + unit tests)\nuv run --no-sync dev.py check\n\n# Unit tests only (--no-sync avoids uv panic in sandboxed environments)\nuv run --no-sync pytest -m \"not integration\"\n\n# Integration tests (needs .env secrets)\nuv run --no-sync pytest -m \"integration\"\n\n# Lint & format\nuv run --no-sync ruff check .\nuv run --no-sync ruff format .\n\n# Type check\nuv run --no-sync mypy\n```\n\n## Testing\n\n- Framework: pytest. Never mock.\n- `@pytest.mark.asyncio` is not needed (asyncio_mode = auto).\n- Integration tests use `@pytest.mark.integration`.\n- NEVER adjust `sys.path`.\n- Keep unit-tests for the class under the same test class. Do not spread them around different test classes. For example, tests for `Agent` must be inside `TestAgent`, etc.\n- ALWAYS test behavior, not calling a path.\n- Use pytest.fixture for test setup, not helper methods\n- NEVER observe method calls in tests; assert on outputs and state.\n\n## Python rules\n\n- Never use `from __future__ import annotations`.\n- Prefer specific exceptions if they are known. If the exception type is not clear, it is ok to use `except Exception as e`.\n- Avoid `getattr`, `hasattr`, `delattr`, `setattr`; prefer normal attribute access.\n- Docstrings: Google style, keep them short.\n- Do not use section comments like `# -- some section --`\n- Prefer `logger.exception()` when logging an error with a traceback instead of `logger.error(\"Error: {exc}\")`\n- Do not use local imports, import at the top of the module\n- Avoid `# type: ignore` comments.\n- Avoid using `Any` type.\n- When adding code to an existing file, follow the patterns already established in that file (e.g. error handling style, import guards, naming).\n\n## Code style\n\n### Imports:\n\n- ordered as: stdlib, third-party, local package, relative. Use `TYPE_CHECKING` guard for imports only needed by type annotations.\n- Never import from private modules (`_foo`) outside of the package's own `__init__.py`. Use the public re-export (e.g. `from vision_agents.testing import TestResponse`, not\n  `from vision_agents.testing._run_result import TestResponse`).\n\n### Naming:\n\n- private attributes and methods use a leading underscore (`_sessions`, `_warmup_agent`). Public API is plain snake_case.\n\n### Type annotations:\n\n- use them everywhere. Modern syntax: `X | Y` unions, `dict[str, T]` generics, full `Callable` signatures, `Optional` for nullable params.\n\n### Logging:\n\nmodule-level `logger = logging.getLogger(__name__)`. Use `debug` for lifecycle, `info` for notable events, `error` for failures without a traceback,\n`exception` for errors with traceback.\n\n- In hot paths (audio processing, event handling), guard debug logging behind `if logger.isEnabledFor(logging.DEBUG):` to avoid formatting overhead when debug is disabled.\n\n### Constructor validation:\n\n- raise `ValueError` with a descriptive message for invalid args. Prefer custom domain exceptions over generic ones.\n\n### Async patterns:\n\n- async-first lifecycle methods (`start`/`stop`). Support `__aenter__`/`__aexit__` for context manager usage.\n- Use `asyncio.Lock`, `asyncio.Task`, `asyncio.gather` for concurrency.\n- Clean up resources in `finally` blocks.\n\n### Method order:\n\n- `__init__`, public lifecycle methods, properties, public feature methods, private helpers, dunder methods.\n\n### Other\n\n- Smallest possible diff. Prefer deleting code over adding it.\n- Don't add error handling, logging, validation, comments, abstractions, config options, or \"future-proofing\" I didn't\n  ask for.\n- Match the style and abstraction level of surrounding code. Don't introduce new patterns or helpers unless asked.\n- Fix root causes, not symptoms. No try/except to swallow bugs.\n- Change only what I asked for. Don't refactor adjacent code — ask first.\n- Do not remove valid comments when editing/refactoring code.\n\n## Plugins\n\n- In every `plugins/*/pyproject.toml`, the wheel target must be `packages = [\"vision_agents\"]`. Listing `\".\"` pulls `tests/`, `README.md`, `example/`, etc. into the published wheel.\n- Each plugin must keep `readme = \"README.md\"` in `[project]` and a `README.md` next to its `pyproject.toml` so PyPI renders a description page.\n\n## Token efficiency\n\n- When making multiple related changes to the same file, combine them into fewer Edit calls with enough surrounding context, rather than one edit per change.\n- Run tests with Bash directly. Only use subagents for test runs when you need to do other work in parallel.\n- Only use TodoWrite for tasks with 5+ steps. Don't update it after every individual edit.\n\n## Changelog\n\n- Lives in `CHANGELOG.md` at the repo root.\n- Organised by version heading (`# v0.4.0`), then sections: **Breaking Changes**, **New Features**, **Bug Fixes**.\n- Only include user-facing changes (public API breaks, features, fixes). Skip docs-only and CI-only commits.\n- Reference PR numbers inline, e.g. `(#374)`.\n- To generate: `git log <last-tag>..HEAD --oneline --no-merges`, then classify each commit.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\n## Project overview\n\nPython monorepo managed with **uv workspaces**.\nThe core framework lives in `agents-core/` and plugins live in `plugins/` (37+ packages).\nPython >= 3.10, 3.12 recommended.\n\n## Commands\n\nAll commands use `uv`. Never use `python -m`. If you run into dependency issues, stop and ask.\n\n```bash\n# Full check (ruff + mypy + unit tests)\nuv run --no-sync dev.py check\n\n# Unit tests only (--no-sync avoids uv panic in sandboxed environments)\nuv run --no-sync pytest -m \"not integration\"\n\n# Integration tests (needs .env secrets)\nuv run --no-sync pytest -m \"integration\"\n\n# Lint & format\nuv run --no-sync ruff check .\nuv run --no-sync ruff format .\n\n# Type check\nuv run --no-sync mypy\n```\n\n## Testing\n\n- Framework: pytest. Never mock.\n- `@pytest.mark.asyncio` is not needed (asyncio_mode = auto).\n- Integration tests use `@pytest.mark.integration`.\n- NEVER adjust `sys.path`.\n- Keep unit-tests for the class under the same test class. Do not spread them around different test classes. For example, tests for `Agent` must be inside `TestAgent`, etc.\n- ALWAYS test behavior, not calling a path.\n- Use pytest.fixture for test setup, not helper methods\n- NEVER observe method calls in tests; assert on outputs and state.\n\n## Python rules\n\n- Never use `from __future__ import annotations`.\n- Prefer specific exceptions if they are known. If the exception type is not clear, it is ok to use `except Exception as e`.\n- Avoid `getattr`, `hasattr`, `delattr`, `setattr`; prefer normal attribute access.\n- Docstrings: Google style, keep them short.\n- Do not use section comments like `# -- some section --`\n- Prefer `logger.exception()` when logging an error with a traceback instead of `logger.error(\"Error: {exc}\")`\n- Do not use local imports, import at the top of the module\n- Avoid `# type: ignore` comments.\n- Avoid using `Any` type.\n- When adding code to an existing file, follow the patterns already established in that file (e.g. error handling style, import guards, naming).\n\n## Code style\n\n### Imports:\n\n- ordered as: stdlib, third-party, local package, relative. Use `TYPE_CHECKING` guard for imports only needed by type annotations.\n- Never import from private modules (`_foo`) outside of the package's own `__init__.py`. Use the public re-export (e.g. `from vision_agents.testing import TestResponse`, not\n  `from vision_agents.testing._run_result import TestResponse`).\n\n### Naming:\n\n- private attributes and methods use a leading underscore (`_sessions`, `_warmup_agent`). Public API is plain snake_case.\n\n### Type annotations:\n\n- use them everywhere. Modern syntax: `X | Y` unions, `dict[str, T]` generics, full `Callable` signatures, `Optional` for nullable params.\n\n### Logging:\n\nmodule-level `logger = logging.getLogger(__name__)`. Use `debug` for lifecycle, `info` for notable events, `error` for failures without a traceback,\n`exception` for errors with traceback.\n\n- In hot paths (audio processing, event handling), guard debug logging behind `if logger.isEnabledFor(logging.DEBUG):` to avoid formatting overhead when debug is disabled.\n\n### Constructor validation:\n\n- raise `ValueError` with a descriptive message for invalid args. Prefer custom domain exceptions over generic ones.\n\n### Async patterns:\n\n- async-first lifecycle methods (`start`/`stop`). Support `__aenter__`/`__aexit__` for context manager usage.\n- Use `asyncio.Lock`, `asyncio.Task`, `asyncio.gather` for concurrency.\n- Clean up resources in `finally` blocks.\n\n### Method order:\n\n- `__init__`, public lifecycle methods, properties, public feature methods, private helpers, dunder methods.\n\n### Other\n\n- Smallest possible diff. Prefer deleting code over adding it.\n- Don't add error handling, logging, validation, comments, abstractions, config options, or \"future-proofing\" I didn't\n  ask for.\n- Match the style and abstraction level of surrounding code. Don't introduce new patterns or helpers unless asked.\n- Fix root causes, not symptoms. No try/except to swallow bugs.\n- Change only what I asked for. Don't refactor adjacent code — ask first.\n- Do not remove valid comments when editing/refactoring code.\n\n## Plugins\n\n- In every `plugins/*/pyproject.toml`, the wheel target must be `packages = [\"vision_agents\"]`. Listing `\".\"` pulls `tests/`, `README.md`, `example/`, etc. into the published wheel.\n- Each plugin must keep `readme = \"README.md\"` in `[project]` and a `README.md` next to its `pyproject.toml` so PyPI renders a description page.\n\n## Token efficiency\n\n- When making multiple related changes to the same file, combine them into fewer Edit calls with enough surrounding context, rather than one edit per change.\n- Run tests with Bash directly. Only use subagents for test runs when you need to do other work in parallel.\n- Only use TodoWrite for tasks with 5+ steps. Don't update it after every individual edit.\n\n## Changelog\n\n- Lives in `CHANGELOG.md` at the repo root.\n- Organised by version heading (`# v0.4.0`), then sections: **Breaking Changes**, **New Features**, **Bug Fixes**.\n- Only include user-facing changes (public API breaks, features, fixes). Skip docs-only and CI-only commits.\n- Reference PR numbers inline, e.g. `(#374)`.\n- To generate: `git log <last-tag>..HEAD --oneline --no-merges`, then classify each commit.\n","category":"root","tokens":1314}]}