{"owner":"trycua","repo":"cua","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2811,"categories":["claude-rule","root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"cua":{"command":"npx","args":["-y","@modelcontextprotocol/server-cua"]}}},"found":["CLAUDE.md","AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"CLAUDE.md":"# Claude Code project guidance\n\n@AGENTS.md\n","AGENTS.md":"# Repository agent guidance\n\n## Contributor authorship\n\nFollow [Preserve Contributor Authorship](.github/CONTRIBUTING.md#preserve-contributor-authorship).\n\n- A `Salvaged from #<pr>` source pull request must differ from the landing pull request.\n- When adapting a contribution directly in its existing pull request, keep the\n  contributor as the commit author and credit adapting authors with\n  `Co-authored-by` trailers instead of citing the pull request as its own source.\n- Use GitHub-linked or GitHub noreply email addresses for commit authors and\n  coauthors so the contributor-attribution check can resolve each identity.\n- Tell the source contributor where their work shipped.\n\nDo not reimplement submitted work solely to remove its authorship history.\n\n## Issue and pull request workflow\n\nFollow the contribution and selection contract in\n[`CONTRIBUTING.md`](.github/CONTRIBUTING.md#choose-where-work-starts),\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#select-and-start-work), the\nGitHub issue forms, [`rfcs/README.md`](docs/rfcs/README.md), and\n[`SECURITY.md`](.github/SECURITY.md). Keep those files canonical instead of duplicating\ntheir field lists, polling ladder, or RFC lifecycle here.\n\nCoding agents act as workers within that contract, not as a planning authority.\nGitHub holds the durable record: the issue or RFC carries the problem and the\ndecision, and the pull request carries the execution. Local schedulers, queues,\nand worktree tooling are private conveniences; a reviewer must not need them to\nunderstand, reproduce, or continue the work.\n\n- when the authenticated GitHub account has write access, create and push the\n  work branch directly in the canonical repository. Do not default to a personal\n  fork merely because a fork remote exists. Use a fork only when write access is\n  unavailable or the maintainer explicitly requests one, and verify the pull\n  request head owner before reporting it;\n- avoid noisy periodic status comments; keep progress in the linked pull request\n  description; and\n- route suspected vulnerabilities through the private process in\n  [`SECURITY.md`](.github/SECURITY.md), never a public issue, RFC, pull request, log, or\n  screenshot.\n\n### Polling for work\n\nWhen asked what to work on, follow\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#pull-model) and the\n[polling skill](.agents/skills/poll-github-work/SKILL.md).\n\n## Repository layout\n\n[`Development.md`](docs/contributing/Development.md) maps components to paths and toolchains;\n[`TESTING.md`](docs/contributing/TESTING.md) maps them to test commands and CI workflows. Rules\nthat are easy to miss:\n\n- `libs/cua` (cua SDK, `cua` CLI, `cua daemon`) is the only client library.\n  `cua-sdk` is its only UniFFI export crate. Bindings, the Spaces manifest,\n  and bundled skills are generated or synced and have `--check` drift gates.\n- `libs/cua-spacesd` is server-only and runs inside the sandbox. Client\n  code goes in `libs/cua`; the driver depends on `libs/cua`, never the reverse.\n  The driver never injects input itself: all input goes through cua-driver.\n- The `.proto` files in `libs/cua/proto` are the contract. Changes are\n  additive and pass `buf breaking`.\n- Sandboxes are daemon-agnostic: lifecycle and readiness must not assume\n  cua-spacesd or any other in-guest service.\n- `libs/fleet` is a read-only mirror. Never edit it.\n- Tests that start VMs, containers, or host input are opt-in\n  (off by default) and clean up what they create.\n\n## Cross-platform Cua Driver behavior\n\nTreat user-visible Cua Driver behavior as a cross-platform contract. Implement\nshared state, geometry, timing, and protocol semantics in the common crates\nwhenever possible, then keep each macOS, Windows, X11, and Wayland adapter thin.\nDo not silently land a platform-specific cursor or interaction change as though\nit were universal.\n\nFor every affected platform, add focused coverage and either verify the native\nbehavior or document a concrete operating-system or compositor limitation.\nWhen a platform cannot support the same contract, return or publish that\nlimitation explicitly instead of substituting misleading behavior.\n\n## Expensive end-to-end test timing\n\nDuring implementation, use focused unit, contract, and platform smoke tests\nplus the repository's ordinary pull request CI. Do not repeatedly run the full\nrepresentative desktop matrix against intermediate commits when the affected\ncode or test plan is still changing.\n\nRun the complete cross-platform desktop E2E matrix once the implementation is\nstable, on the exact candidate SHA immediately before the pull request is made\nready or merged. If that candidate changes afterward, rerun only the evidence\naffected by the change; a product, harness, generated-contract, or environment\nchange normally requires recertification, while an instructions-only or other\ndemonstrably non-executable change does not require repeating unrelated desktop\nrows. Record the tested SHA and account for any final diff explicitly.\n\nAfter merge, run a short main-branch smoke and release-path verification. Repeat\nthe full matrix after merge only when the merge result materially differs from\nthe certified candidate or the smoke test exposes a regression.\n\n## Canonical Cua Driver desktop E2E\n\nFollow the [test harnesses guide](libs/cua-driver/docs/test-harnesses-guide.md#the-short-version)\nand [CI runner guide](scripts/ci/README.md#desktop-runners) for canonical commands,\nenvironment prerequisites, and evidence authority.\n\nDo not assume that GitHub-hosted Windows runs in Session 0. Keep the hosted Linux\nX11 gate, Nix source checks, and compositor-specific Wayland lanes separate.\n\n## Cua Driver test ownership\n\nThese rules come from the #4094 test audit.\n\n- Give each contract one owner test, at the strongest boundary that can\n  observe it. Delete weaker duplicates instead of keeping parallel copies.\n- Do not add test-only switches, environment hooks, or injectors to shipped\n  code. Test through the public interface or a real seam.\n- Plain `cargo test` must be hermetic: no real input, clipboard, window, or\n  per-user host state. Use the testkit's isolated home. Clipboard round trips\n  need an explicit `CUA_TEST_ALLOW_CLIPBOARD=1` opt-in.\n- Put desktop-bound suites in `cua-driver-e2e` or mark them `#[ignore]`. A\n  canonical runner must select every ignored test, or\n  `libs/cua-driver/tests/manual-e2e-allowlist.txt` must list it with a reason;\n  `.github/scripts/tests/test_cua_driver_e2e_inventory.py` enforces this.\n- CI runs whole crates or test binaries, not hand-maintained module filters,\n  so a new test module cannot be silently left out.\n- A negative test asserts the exact refusal code or error, not just failure.\n- When pruning or merging tests, mutation-check the keeper: break the\n  behavior and confirm the remaining test fails.\n\n## Pull request titles and component releases\n\nFollow the [release-title rules](.github/CONTRIBUTING.md#agent-assisted-contributions)\nand [Sandbox release rules](.github/CONTRIBUTING.md#sandbox-releases).\nDo not use `no-release` to hide a user-visible change.\n\nBefore declaring a pull request ready or merging it, inspect its final changed\nfiles and query its current GitHub title. Correct the title yourself when the\nscope or release impact changed during implementation, and wait for\n`CI: Release metadata` to pass. Do not leave title correction for a maintainer.\n\n## Monorepo component release resolution\n\nCua is a monorepo with independent component release streams. Never use\nGitHub's repository-wide \"Latest\" release badge, the `/releases/latest`\nendpoint, or a generic \"stable\" designation to determine whether a component\nhas shipped or which version users receive.\n\nInspect the component's canonical installer and release workflow instead. For\nCua Driver, both the Unix and Windows installers normally use a\nrelease-managed baked version. Their API fallback selects the highest semantic\nversion whose tag matches `cua-driver-rs-v*`. Both download assets from the\nexact component tag; neither depends on GitHub's repository-wide \"Latest\"\nrelease.\n\nBefore making a release-status or installation-version claim:\n\n- identify the component's tag prefix and canonical installer entry points;\n- inspect version-override and baked-version precedence;\n- verify that the component-tagged release and expected assets exist; and\n- confirm which exact version the canonical installer currently resolves.\n\nDescribe a component as shipped when its own release artifacts exist and its\ncanonical distribution path resolves them. Do not add a separate\n\"promoted to GitHub Latest/stable\" requirement unless that component's\ndistribution code explicitly uses one.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/plugin.json)"},"files":{"CLAUDE.md":"# Claude Code project guidance\n\n@AGENTS.md\n","AGENTS.md":"# Repository agent guidance\n\n## Contributor authorship\n\nFollow [Preserve Contributor Authorship](.github/CONTRIBUTING.md#preserve-contributor-authorship).\n\n- A `Salvaged from #<pr>` source pull request must differ from the landing pull request.\n- When adapting a contribution directly in its existing pull request, keep the\n  contributor as the commit author and credit adapting authors with\n  `Co-authored-by` trailers instead of citing the pull request as its own source.\n- Use GitHub-linked or GitHub noreply email addresses for commit authors and\n  coauthors so the contributor-attribution check can resolve each identity.\n- Tell the source contributor where their work shipped.\n\nDo not reimplement submitted work solely to remove its authorship history.\n\n## Issue and pull request workflow\n\nFollow the contribution and selection contract in\n[`CONTRIBUTING.md`](.github/CONTRIBUTING.md#choose-where-work-starts),\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#select-and-start-work), the\nGitHub issue forms, [`rfcs/README.md`](docs/rfcs/README.md), and\n[`SECURITY.md`](.github/SECURITY.md). Keep those files canonical instead of duplicating\ntheir field lists, polling ladder, or RFC lifecycle here.\n\nCoding agents act as workers within that contract, not as a planning authority.\nGitHub holds the durable record: the issue or RFC carries the problem and the\ndecision, and the pull request carries the execution. Local schedulers, queues,\nand worktree tooling are private conveniences; a reviewer must not need them to\nunderstand, reproduce, or continue the work.\n\n- when the authenticated GitHub account has write access, create and push the\n  work branch directly in the canonical repository. Do not default to a personal\n  fork merely because a fork remote exists. Use a fork only when write access is\n  unavailable or the maintainer explicitly requests one, and verify the pull\n  request head owner before reporting it;\n- avoid noisy periodic status comments; keep progress in the linked pull request\n  description; and\n- route suspected vulnerabilities through the private process in\n  [`SECURITY.md`](.github/SECURITY.md), never a public issue, RFC, pull request, log, or\n  screenshot.\n\n### Polling for work\n\nWhen asked what to work on, follow\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#pull-model) and the\n[polling skill](.agents/skills/poll-github-work/SKILL.md).\n\n## Repository layout\n\n[`Development.md`](docs/contributing/Development.md) maps components to paths and toolchains;\n[`TESTING.md`](docs/contributing/TESTING.md) maps them to test commands and CI workflows. Rules\nthat are easy to miss:\n\n- `libs/cua` (cua SDK, `cua` CLI, `cua daemon`) is the only client library.\n  `cua-sdk` is its only UniFFI export crate. Bindings, the Spaces manifest,\n  and bundled skills are generated or synced and have `--check` drift gates.\n- `libs/cua-spacesd` is server-only and runs inside the sandbox. Client\n  code goes in `libs/cua`; the driver depends on `libs/cua`, never the reverse.\n  The driver never injects input itself: all input goes through cua-driver.\n- The `.proto` files in `libs/cua/proto` are the contract. Changes are\n  additive and pass `buf breaking`.\n- Sandboxes are daemon-agnostic: lifecycle and readiness must not assume\n  cua-spacesd or any other in-guest service.\n- `libs/fleet` is a read-only mirror. Never edit it.\n- Tests that start VMs, containers, or host input are opt-in\n  (off by default) and clean up what they create.\n\n## Cross-platform Cua Driver behavior\n\nTreat user-visible Cua Driver behavior as a cross-platform contract. Implement\nshared state, geometry, timing, and protocol semantics in the common crates\nwhenever possible, then keep each macOS, Windows, X11, and Wayland adapter thin.\nDo not silently land a platform-specific cursor or interaction change as though\nit were universal.\n\nFor every affected platform, add focused coverage and either verify the native\nbehavior or document a concrete operating-system or compositor limitation.\nWhen a platform cannot support the same contract, return or publish that\nlimitation explicitly instead of substituting misleading behavior.\n\n## Expensive end-to-end test timing\n\nDuring implementation, use focused unit, contract, and platform smoke tests\nplus the repository's ordinary pull request CI. Do not repeatedly run the full\nrepresentative desktop matrix against intermediate commits when the affected\ncode or test plan is still changing.\n\nRun the complete cross-platform desktop E2E matrix once the implementation is\nstable, on the exact candidate SHA immediately before the pull request is made\nready or merged. If that candidate changes afterward, rerun only the evidence\naffected by the change; a product, harness, generated-contract, or environment\nchange normally requires recertification, while an instructions-only or other\ndemonstrably non-executable change does not require repeating unrelated desktop\nrows. Record the tested SHA and account for any final diff explicitly.\n\nAfter merge, run a short main-branch smoke and release-path verification. Repeat\nthe full matrix after merge only when the merge result materially differs from\nthe certified candidate or the smoke test exposes a regression.\n\n## Canonical Cua Driver desktop E2E\n\nFollow the [test harnesses guide](libs/cua-driver/docs/test-harnesses-guide.md#the-short-version)\nand [CI runner guide](scripts/ci/README.md#desktop-runners) for canonical commands,\nenvironment prerequisites, and evidence authority.\n\nDo not assume that GitHub-hosted Windows runs in Session 0. Keep the hosted Linux\nX11 gate, Nix source checks, and compositor-specific Wayland lanes separate.\n\n## Cua Driver test ownership\n\nThese rules come from the #4094 test audit.\n\n- Give each contract one owner test, at the strongest boundary that can\n  observe it. Delete weaker duplicates instead of keeping parallel copies.\n- Do not add test-only switches, environment hooks, or injectors to shipped\n  code. Test through the public interface or a real seam.\n- Plain `cargo test` must be hermetic: no real input, clipboard, window, or\n  per-user host state. Use the testkit's isolated home. Clipboard round trips\n  need an explicit `CUA_TEST_ALLOW_CLIPBOARD=1` opt-in.\n- Put desktop-bound suites in `cua-driver-e2e` or mark them `#[ignore]`. A\n  canonical runner must select every ignored test, or\n  `libs/cua-driver/tests/manual-e2e-allowlist.txt` must list it with a reason;\n  `.github/scripts/tests/test_cua_driver_e2e_inventory.py` enforces this.\n- CI runs whole crates or test binaries, not hand-maintained module filters,\n  so a new test module cannot be silently left out.\n- A negative test asserts the exact refusal code or error, not just failure.\n- When pruning or merging tests, mutation-check the keeper: break the\n  behavior and confirm the remaining test fails.\n\n## Pull request titles and component releases\n\nFollow the [release-title rules](.github/CONTRIBUTING.md#agent-assisted-contributions)\nand [Sandbox release rules](.github/CONTRIBUTING.md#sandbox-releases).\nDo not use `no-release` to hide a user-visible change.\n\nBefore declaring a pull request ready or merging it, inspect its final changed\nfiles and query its current GitHub title. Correct the title yourself when the\nscope or release impact changed during implementation, and wait for\n`CI: Release metadata` to pass. Do not leave title correction for a maintainer.\n\n## Monorepo component release resolution\n\nCua is a monorepo with independent component release streams. Never use\nGitHub's repository-wide \"Latest\" release badge, the `/releases/latest`\nendpoint, or a generic \"stable\" designation to determine whether a component\nhas shipped or which version users receive.\n\nInspect the component's canonical installer and release workflow instead. For\nCua Driver, both the Unix and Windows installers normally use a\nrelease-managed baked version. Their API fallback selects the highest semantic\nversion whose tag matches `cua-driver-rs-v*`. Both download assets from the\nexact component tag; neither depends on GitHub's repository-wide \"Latest\"\nrelease.\n\nBefore making a release-status or installation-version claim:\n\n- identify the component's tag prefix and canonical installer entry points;\n- inspect version-override and baked-version precedence;\n- verify that the component-tagged release and expected assets exist; and\n- confirm which exact version the canonical installer currently resolves.\n\nDescribe a component as shipped when its own release artifacts exist and its\ncanonical distribution path resolves them. Do not add a separate\n\"promoted to GitHub Latest/stable\" requirement unless that component's\ndistribution code explicitly uses one.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/trycua/cua/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository agent guidance\n\n## Contributor authorship\n\nFollow [Preserve Contributor Authorship](.github/CONTRIBUTING.md#preserve-contributor-authorship).\n\n- A `Salvaged from #<pr>` source pull request must differ from the landing pull request.\n- When adapting a contribution directly in its existing pull request, keep the\n  contributor as the commit author and credit adapting authors with\n  `Co-authored-by` trailers instead of citing the pull request as its own source.\n- Use GitHub-linked or GitHub noreply email addresses for commit authors and\n  coauthors so the contributor-attribution check can resolve each identity.\n- Tell the source contributor where their work shipped.\n\nDo not reimplement submitted work solely to remove its authorship history.\n\n## Issue and pull request workflow\n\nFollow the contribution and selection contract in\n[`CONTRIBUTING.md`](.github/CONTRIBUTING.md#choose-where-work-starts),\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#select-and-start-work), the\nGitHub issue forms, [`rfcs/README.md`](docs/rfcs/README.md), and\n[`SECURITY.md`](.github/SECURITY.md). Keep those files canonical instead of duplicating\ntheir field lists, polling ladder, or RFC lifecycle here.\n\nCoding agents act as workers within that contract, not as a planning authority.\nGitHub holds the durable record: the issue or RFC carries the problem and the\ndecision, and the pull request carries the execution. Local schedulers, queues,\nand worktree tooling are private conveniences; a reviewer must not need them to\nunderstand, reproduce, or continue the work.\n\n- when the authenticated GitHub account has write access, create and push the\n  work branch directly in the canonical repository. Do not default to a personal\n  fork merely because a fork remote exists. Use a fork only when write access is\n  unavailable or the maintainer explicitly requests one, and verify the pull\n  request head owner before reporting it;\n- avoid noisy periodic status comments; keep progress in the linked pull request\n  description; and\n- route suspected vulnerabilities through the private process in\n  [`SECURITY.md`](.github/SECURITY.md), never a public issue, RFC, pull request, log, or\n  screenshot.\n\n### Polling for work\n\nWhen asked what to work on, follow\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#pull-model) and the\n[polling skill](.agents/skills/poll-github-work/SKILL.md).\n\n## Repository layout\n\n[`Development.md`](docs/contributing/Development.md) maps components to paths and toolchains;\n[`TESTING.md`](docs/contributing/TESTING.md) maps them to test commands and CI workflows. Rules\nthat are easy to miss:\n\n- `libs/cua` (cua SDK, `cua` CLI, `cua daemon`) is the only client library.\n  `cua-sdk` is its only UniFFI export crate. Bindings, the Spaces manifest,\n  and bundled skills are generated or synced and have `--check` drift gates.\n- `libs/cua-spacesd` is server-only and runs inside the sandbox. Client\n  code goes in `libs/cua`; the driver depends on `libs/cua`, never the reverse.\n  The driver never injects input itself: all input goes through cua-driver.\n- The `.proto` files in `libs/cua/proto` are the contract. Changes are\n  additive and pass `buf breaking`.\n- Sandboxes are daemon-agnostic: lifecycle and readiness must not assume\n  cua-spacesd or any other in-guest service.\n- `libs/fleet` is a read-only mirror. Never edit it.\n- Tests that start VMs, containers, or host input are opt-in\n  (off by default) and clean up what they create.\n\n## Cross-platform Cua Driver behavior\n\nTreat user-visible Cua Driver behavior as a cross-platform contract. Implement\nshared state, geometry, timing, and protocol semantics in the common crates\nwhenever possible, then keep each macOS, Windows, X11, and Wayland adapter thin.\nDo not silently land a platform-specific cursor or interaction change as though\nit were universal.\n\nFor every affected platform, add focused coverage and either verify the native\nbehavior or document a concrete operating-system or compositor limitation.\nWhen a platform cannot support the same contract, return or publish that\nlimitation explicitly instead of substituting misleading behavior.\n\n## Expensive end-to-end test timing\n\nDuring implementation, use focused unit, contract, and platform smoke tests\nplus the repository's ordinary pull request CI. Do not repeatedly run the full\nrepresentative desktop matrix against intermediate commits when the affected\ncode or test plan is still changing.\n\nRun the complete cross-platform desktop E2E matrix once the implementation is\nstable, on the exact candidate SHA immediately before the pull request is made\nready or merged. If that candidate changes afterward, rerun only the evidence\naffected by the change; a product, harness, generated-contract, or environment\nchange normally requires recertification, while an instructions-only or other\ndemonstrably non-executable change does not require repeating unrelated desktop\nrows. Record the tested SHA and account for any final diff explicitly.\n\nAfter merge, run a short main-branch smoke and release-path verification. Repeat\nthe full matrix after merge only when the merge result materially differs from\nthe certified candidate or the smoke test exposes a regression.\n\n## Canonical Cua Driver desktop E2E\n\nFollow the [test harnesses guide](libs/cua-driver/docs/test-harnesses-guide.md#the-short-version)\nand [CI runner guide](scripts/ci/README.md#desktop-runners) for canonical commands,\nenvironment prerequisites, and evidence authority.\n\nDo not assume that GitHub-hosted Windows runs in Session 0. Keep the hosted Linux\nX11 gate, Nix source checks, and compositor-specific Wayland lanes separate.\n\n## Cua Driver test ownership\n\nThese rules come from the #4094 test audit.\n\n- Give each contract one owner test, at the strongest boundary that can\n  observe it. Delete weaker duplicates instead of keeping parallel copies.\n- Do not add test-only switches, environment hooks, or injectors to shipped\n  code. Test through the public interface or a real seam.\n- Plain `cargo test` must be hermetic: no real input, clipboard, window, or\n  per-user host state. Use the testkit's isolated home. Clipboard round trips\n  need an explicit `CUA_TEST_ALLOW_CLIPBOARD=1` opt-in.\n- Put desktop-bound suites in `cua-driver-e2e` or mark them `#[ignore]`. A\n  canonical runner must select every ignored test, or\n  `libs/cua-driver/tests/manual-e2e-allowlist.txt` must list it with a reason;\n  `.github/scripts/tests/test_cua_driver_e2e_inventory.py` enforces this.\n- CI runs whole crates or test binaries, not hand-maintained module filters,\n  so a new test module cannot be silently left out.\n- A negative test asserts the exact refusal code or error, not just failure.\n- When pruning or merging tests, mutation-check the keeper: break the\n  behavior and confirm the remaining test fails.\n\n## Pull request titles and component releases\n\nFollow the [release-title rules](.github/CONTRIBUTING.md#agent-assisted-contributions)\nand [Sandbox release rules](.github/CONTRIBUTING.md#sandbox-releases).\nDo not use `no-release` to hide a user-visible change.\n\nBefore declaring a pull request ready or merging it, inspect its final changed\nfiles and query its current GitHub title. Correct the title yourself when the\nscope or release impact changed during implementation, and wait for\n`CI: Release metadata` to pass. Do not leave title correction for a maintainer.\n\n## Monorepo component release resolution\n\nCua is a monorepo with independent component release streams. Never use\nGitHub's repository-wide \"Latest\" release badge, the `/releases/latest`\nendpoint, or a generic \"stable\" designation to determine whether a component\nhas shipped or which version users receive.\n\nInspect the component's canonical installer and release workflow instead. For\nCua Driver, both the Unix and Windows installers normally use a\nrelease-managed baked version. Their API fallback selects the highest semantic\nversion whose tag matches `cua-driver-rs-v*`. Both download assets from the\nexact component tag; neither depends on GitHub's repository-wide \"Latest\"\nrelease.\n\nBefore making a release-status or installation-version claim:\n\n- identify the component's tag prefix and canonical installer entry points;\n- inspect version-override and baked-version precedence;\n- verify that the component-tagged release and expected assets exist; and\n- confirm which exact version the canonical installer currently resolves.\n\nDescribe a component as shipped when its own release artifacts exist and its\ncanonical distribution path resolves them. Do not add a separate\n\"promoted to GitHub Latest/stable\" requirement unless that component's\ndistribution code explicitly uses one.\n","isInternal":false,"tokens":1900,"sizeBytes":8677},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/trycua/cua/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Code project guidance\n\n@AGENTS.md\n","isInternal":false,"tokens":11,"sizeBytes":43},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":189},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":175},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/trycua/cua/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":168}],"systemPromptSnippet":"<yakaai_skills repo=\"trycua/cua\">\n<!-- File: AGENTS.md (Tokens: ~1900 | Category: root-instruction) -->\n# Repository agent guidance\n\n## Contributor authorship\n\nFollow [Preserve Contributor Authorship](.github/CONTRIBUTING.md#preserve-contributor-authorship).\n\n- A `Salvaged from #<pr>` source pull request must differ from the landing pull request.\n- When adapting a contribution directly in its existing pull request, keep the\n  contributor as the commit author and credit adapting authors with\n  `Co-authored-by` trailers instead of citing the pull request as its own source.\n- Use GitHub-linked or GitHub noreply email addresses for commit authors and\n  coauthors so the contributor-attribution check can resolve each identity.\n- Tell the source contributor where their work shipped.\n\nDo not reimplement submitted work solely to remove its authorship history.\n\n## Issue and pull request workflow\n\nFollow the contribution and selection contract in\n[`CONTRIBUTING.md`](.github/CONTRIBUTING.md#choose-where-work-starts),\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#select-and-start-work), the\nGitHub issue forms, [`rfcs/README.md`](docs/rfcs/README.md), and\n[`SECURITY.md`](.github/SECURITY.md). Keep those files canonical instead of duplicating\ntheir field lists, polling ladder, or RFC lifecycle here.\n\nCoding agents act as workers within that contract, not as a planning authority.\nGitHub holds the durable record: the issue or RFC carries the problem and the\ndecision, and the pull request carries the execution. Local schedulers, queues,\nand worktree tooling are private conveniences; a reviewer must not need them to\nunderstand, reproduce, or continue the work.\n\n- when the authenticated GitHub account has write access, create and push the\n  work branch directly in the canonical repository. Do not default to a personal\n  fork merely because a fork remote exists. Use a fork only when write access is\n  unavailable or the maintainer explicitly requests one, and verify the pull\n  request head owner before reporting it;\n- avoid noisy periodic status comments; keep progress in the linked pull request\n  description; and\n- route suspected vulnerabilities through the private process in\n  [`SECURITY.md`](.github/SECURITY.md), never a public issue, RFC, pull request, log, or\n  screenshot.\n\n### Polling for work\n\nWhen asked what to work on, follow\n[`MAINTAINERS.md`](docs/contributing/MAINTAINERS.md#pull-model) and the\n[polling skill](.agents/skills/poll-github-work/SKILL.md).\n\n## Repository layout\n\n[`Development.md`](docs/contributing/Development.md) maps components to paths and toolchains;\n[`TESTING.md`](docs/contributing/TESTING.md) maps them to test commands and CI workflows. Rules\nthat are easy to miss:\n\n- `libs/cua` (cua SDK, `cua` CLI, `cua daemon`) is the only client library.\n  `cua-sdk` is its only UniFFI export crate. Bindings, the Spaces manifest,\n  and bundled skills are generated or synced and have `--check` drift gates.\n- `libs/cua-spacesd` is server-only and runs inside the sandbox. Client\n  code goes in `libs/cua`; the driver depends on `libs/cua`, never the reverse.\n  The driver never injects input itself: all input goes through cua-driver.\n- The `.proto` files in `libs/cua/proto` are the contract. Changes are\n  additive and pass `buf breaking`.\n- Sandboxes are daemon-agnostic: lifecycle and readiness must not assume\n  cua-spacesd or any other in-guest service.\n- `libs/fleet` is a read-only mirror. Never edit it.\n- Tests that start VMs, containers, or host input are opt-in\n  (off by default) and clean up what they create.\n\n## Cross-platform Cua Driver behavior\n\nTreat user-visible Cua Driver behavior as a cross-platform contract. Implement\nshared state, geometry, timing, and protocol semantics in the common crates\nwhenever possible, then keep each macOS, Windows, X11, and Wayland adapter thin.\nDo not silently land a platform-specific cursor or interaction change as though\nit were universal.\n\nFor every affected platform, add focused coverage and either verify the native\nbehavior or document a concrete operating-system or compositor limitation.\nWhen a platform cannot support the same contract, return or publish that\nlimitation explicitly instead of substituting misleading behavior.\n\n## Expensive end-to-end test timing\n\nDuring implementation, use focused unit, contract, and platform smoke tests\nplus the repository's ordinary pull request CI. Do not repeatedly run the full\nrepresentative desktop matrix against intermediate commits when the affected\ncode or test plan is still changing.\n\nRun the complete cross-platform desktop E2E matrix once the implementation is\nstable, on the exact candidate SHA immediately before the pull request is made\nready or merged. If that candidate changes afterward, rerun only the evidence\naffected by the change; a product, harness, generated-contract, or environment\nchange normally requires recertification, while an instructions-only or other\ndemonstrably non-executable change does not require repeating unrelated desktop\nrows. Record the tested SHA and account for any final diff explicitly.\n\nAfter merge, run a short main-branch smoke and release-path verification. Repeat\nthe full matrix after merge only when the merge result materially differs from\nthe certified candidate or the smoke test exposes a regression.\n\n## Canonical Cua Driver desktop E2E\n\nFollow the [test harnesses guide](libs/cua-driver/docs/test-harnesses-guide.md#the-short-version)\nand [CI runner guide](scripts/ci/README.md#desktop-runners) for canonical commands,\nenvironment prerequisites, and evidence authority.\n\nDo not assume that GitHub-hosted Windows runs in Session 0. Keep the hosted Linux\nX11 gate, Nix source checks, and compositor-specific Wayland lanes separate.\n\n## Cua Driver test ownership\n\nThese rules come from the #4094 test audit.\n\n- Give each contract one owner test, at the strongest boundary that can\n  observe it. Delete weaker duplicates instead of keeping parallel copies.\n- Do not add test-only switches, environment hooks, or injectors to shipped\n  code. Test through the public interface or a real seam.\n- Plain `cargo test` must be hermetic: no real input, clipboard, window, or\n  per-user host state. Use the testkit's isolated home. Clipboard round trips\n  need an explicit `CUA_TEST_ALLOW_CLIPBOARD=1` opt-in.\n- Put desktop-bound suites in `cua-driver-e2e` or mark them `#[ignore]`. A\n  canonical runner must select every ignored test, or\n  `libs/cua-driver/tests/manual-e2e-allowlist.txt` must list it with a reason;\n  `.github/scripts/tests/test_cua_driver_e2e_inventory.py` enforces this.\n- CI runs whole crates or test binaries, not hand-maintained module filters,\n  so a new test module cannot be silently left out.\n- A negative test asserts the exact refusal code or error, not just failure.\n- When pruning or merging tests, mutation-check the keeper: break the\n  behavior and confirm the remaining test fails.\n\n## Pull request titles and component releases\n\nFollow the [release-title rules](.github/CONTRIBUTING.md#agent-assisted-contributions)\nand [Sandbox release rules](.github/CONTRIBUTING.md#sandbox-releases).\nDo not use `no-release` to hide a user-visible change.\n\nBefore declaring a pull request ready or merging it, inspect its final changed\nfiles and query its current GitHub title. Correct the title yourself when the\nscope or release impact changed during implementation, and wait for\n`CI: Release metadata` to pass. Do not leave title correction for a maintainer.\n\n## Monorepo component release resolution\n\nCua is a monorepo with independent component release streams. Never use\nGitHub's repository-wide \"Latest\" release badge, the `/releases/latest`\nendpoint, or a generic \"stable\" designation to determine whether a component\nhas shipped or which version users receive.\n\nInspect the component's canonical installer and release workflow instead. For\nCua Driver, both the Unix and Windows installers normally use a\nrelease-managed baked version. Their API fallback selects the highest semantic\nversion whose tag matches `cua-driver-rs-v*`. Both download assets from the\nexact component tag; neither depends on GitHub's repository-wide \"Latest\"\nrelease.\n\nBefore making a release-status or installation-version claim:\n\n- identify the component's tag prefix and canonical installer entry points;\n- inspect version-override and baked-version precedence;\n- verify that the component-tagged release and expected assets exist; and\n- confirm which exact version the canonical installer currently resolves.\n\nDescribe a component as shipped when its own release artifacts exist and its\ncanonical distribution path resolves them. Do not add a separate\n\"promoted to GitHub Latest/stable\" requirement unless that component's\ndistribution code explicitly uses one.\n\n<!-- File: CLAUDE.md (Tokens: ~11 | Category: claude-rule) -->\n# Claude Code project guidance\n\n@AGENTS.md\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/trycua/cua/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}