{"owner":"alibaba","repo":"OpenSandbox","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2777,"categories":["claude-rule","root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"OpenSandbox":{"command":"npx","args":["-y","@modelcontextprotocol/server-OpenSandbox"]}}},"found":["CLAUDE.md","AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"CLAUDE.md":"# OpenSandbox Claude Guide\n\nSee `AGENTS.md` for all rules, routing, and conventions.\n","AGENTS.md":"# OpenSandbox AGENTS\n\nUse this file as the root router for the monorepo. Prefer the nearest `AGENTS.md` in the directory tree for task-specific instructions.\n\n## Repository Map\n\n- `server/`: FastAPI lifecycle control plane, Docker/Kubernetes runtime integration, snapshot metadata, and server tests\n- `components/execd/`: in-sandbox execution daemon\n- `components/egress/`: per-sandbox network egress policy sidecar\n- `components/ingress/`: ingress gateway and endpoint routing\n- `components/internal/`: shared Go helpers used by runtime components\n- `sdks/`: sandbox, code-interpreter, and MCP SDKs plus generated clients\n- `specs/`: public OpenAPI contracts and examples\n- `kubernetes/`: Kubernetes operator, CRDs, task-executor, and Kind e2e tests\n- `manifests/charts/`: Helm charts (base, controller, server, ingress-gateway, node-agent, fast-sandbox, opensandbox umbrella)\n- `cli/`: `osb` command-line client and bundled CLI skills\n- `tests/`: cross-language end-to-end SDK tests\n- `docs/`, `examples/`, `oseps/`: documentation, samples, and proposals\n\n## Routing\n\n- For `server/**`, or lifecycle server behavior, sandbox creation flow, or user-visible server config, read `server/AGENTS.md`.\n- For `sdks/**`, or SDK generation, handwritten adapters, or cross-language SDK alignment, read `sdks/AGENTS.md`.\n- For `specs/**`, or API contract, schema, or example changes, read `specs/AGENTS.md`.\n- For `kubernetes/**`, or CRDs, controller behavior, task execution, Helm/Kustomize deployment, pool scheduling, pause/resume snapshots, or Kind e2e tests, read `kubernetes/AGENTS.md`.\n- For cross-cutting changes spanning spec, server, and SDKs, start with `specs/AGENTS.md` and then read affected consumer guides.\n- For runtime component changes under `components/**`, read the nearest `README.md` or `DEVELOPMENT.md`; keep component APIs aligned with `specs/` and SDK consumers.\n- For CLI changes under `cli/**`, read `cli/README.md` and verify command help/output behavior alongside unit tests.\n- For cross-language e2e tests under `tests/**`, read the language-local README and keep test assumptions aligned with current server and SDK behavior.\n- For areas without a local `AGENTS.md`, use the nearest `README.md`, `DEVELOPMENT.md`, and CI workflow as the next source of truth.\n\n## Working Principles\n\n- Think before coding: state assumptions, surface ambiguity, and ask or push back when the request has conflicting interpretations.\n- Simplicity first: implement the smallest solution that satisfies the request; avoid speculative features, one-off abstractions, and unnecessary configurability.\n- Surgical changes: touch only files and lines needed for the task, match local style, and do not refactor or delete unrelated pre-existing code.\n- Goal-driven execution: translate non-trivial work into verifiable success criteria, add or update focused tests when behavior changes, and loop until checks pass or blockers are clear.\n\n## Guardrails\n\nAlways:\n\n- Treat `specs/*` as public contract sources.\n- Keep spec, implementation, SDKs, docs, examples, config, and CLI behavior aligned when user-visible behavior changes; update `docs/` first.\n- When changing `specs/*`, also update or verify affected server, SDK, docs, and release outputs when practical.\n- When changing CRDs or Kubernetes public behavior, update or verify generated manifests, Helm/Kustomize deployment output, server Kubernetes integration, and docs when practical.\n- Prefer additive, backward-compatible changes for public interfaces.\n- Regenerate derived outputs when the source-of-truth file changes.\n- Mention unrun or blocked verification in the final handoff.\n- Prefer file-scoped or package-scoped checks before full-suite validation.\n\nAsk first:\n\n- Breaking public API, SDK, config, protocol, or CLI changes\n- Breaking CRD, annotation, label, Helm values, or Kubernetes deployment changes\n- Intentional drift between a public contract and its implementation\n- User-visible config or behavior changes without a clear migration story\n\nNever:\n\n- Edit generated output as the only fix.\n- Mix unrelated component work into the same change.\n\n## Documentation Rules\n\n### Content ownership — single source of truth\n\n| Content type | Source of truth | Rule |\n|---|---|---|\n| Root README | repo root `README.md` | GitHub homepage |\n| SDK, CLI, Helm, and other publishable package READMEs | package directory | Keep install, quick start, and package entry points; no long-form docs |\n| Non-publishable component/module READMEs | component/module directory | Keep minimal pointers to `docs/` when a docs page exists |\n| Examples | `docs/examples/` + runnable code under `examples/` | Put docs in `docs/examples/`; keep example READMEs as thin pointers |\n| OSEPs | `oseps/` | `docs/community/oseps.md` only indexes GitHub proposals |\n| CONTRIBUTING, CODE_OF_CONDUCT, DEVELOPMENT | repo root / component directory | `docs/community/` links to them, does not duplicate them |\n\n**When adding design/how-it-works content**: high-level architecture design and implementation principles go under `docs/architecture/`; user-facing usage instructions go under `docs/guides/`. Do not mix usage how-tos into architecture pages, or internals into guides.\n\n**When handling localized READMEs**: do not add new localized copies for SDKs, examples, or non-special modules.\n\n**When linking from README files to docs**: prefer repository-relative `docs/*.md` links (they match the checked-out branch/tag); use `https://open-sandbox.ai` only as a public site entry point, not as the only source link from versioned code directories.\n\n### Docs site structure\n\n```\ndocs/\n  getting-started/     # Quick start, installation, configuration\n  architecture/        # High-level architecture design and implementation principles (overview, control-plane/, data-plane/, network/, fast-sandbox/)\n  deployment/          # Deployment and operations (Kubernetes install, storage, metrics)\n  guides/              # User-facing usage and feature guides (credential vault, secure container, pause/resume, etc.)\n  sdks/                # SDK reference (one page per language per SDK)\n  api/                 # OpenAPI spec reference\n  cli/                 # CLI reference\n  examples/            # One page per example\n  community/           # Contributing, code of conduct, OSEPs, releases\n  reference/           # Migration guides\n```\n\n### Docs conventions\n\n- Engine: VitePress. Config is a static `config.mts` with no build-time code generation.\n- All images go in `docs/public/images/`. Reference them with a document-relative path to that directory (for example, `../public/images/filename` from `docs/guides/`) so they render in both repository previews and VitePress.\n- Every page must have YAML frontmatter with `title` and `description`.\n- Internal links use VitePress absolute paths (e.g., `/sdks/python`, `/guides/credential-vault`).\n- Links to source code or specs use full GitHub URLs.\n- Use VitePress custom containers (`::: tip`, `::: warning`, `::: info`) and code groups where appropriate.\n- Build and verify: `cd docs && pnpm docs:build` — must complete with zero errors.\n- The README.md in `docs/` is for docs-site contributors only (how to run dev server), and must stay excluded from the published site.\n- Markdown prose style, for all `.md` files in the repo: do not hard-wrap prose — a sentence or paragraph is written on a single line and editors soft-wrap. One line per list item and per blockquote paragraph.\n- Hard breaks (two trailing spaces or a trailing backslash) are only for intentional rendering, never for prose wrapping. Keep verbatim blocks untouched: code blocks, tables, YAML frontmatter, HTML blocks, ASCII diagrams. Never reflow generated markdown (e.g., helm-docs chart READMEs under `manifests/charts/*/README.md`) — change its source template and regenerate instead.\n- Never insert a blank line inside a paragraph, and never reflow or re-structure unrelated markdown while editing a file. When generating markdown programmatically, join soft-wrapped lines with a single space (no space between adjacent CJK characters).\n\n## Review Focus\n\n- Prioritize breaking changes in specs, SDK interfaces, config, CLI behavior, and protocols; flag protocol changes that are unnecessary, inconsistent, or hard to implement.\n- Flag changes that break source-of-truth boundaries or intended layering.\n- Call out missing tests and compatibility risks explicitly.\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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.claude-plugin/plugin.json)"},"files":{"CLAUDE.md":"# OpenSandbox Claude Guide\n\nSee `AGENTS.md` for all rules, routing, and conventions.\n","AGENTS.md":"# OpenSandbox AGENTS\n\nUse this file as the root router for the monorepo. Prefer the nearest `AGENTS.md` in the directory tree for task-specific instructions.\n\n## Repository Map\n\n- `server/`: FastAPI lifecycle control plane, Docker/Kubernetes runtime integration, snapshot metadata, and server tests\n- `components/execd/`: in-sandbox execution daemon\n- `components/egress/`: per-sandbox network egress policy sidecar\n- `components/ingress/`: ingress gateway and endpoint routing\n- `components/internal/`: shared Go helpers used by runtime components\n- `sdks/`: sandbox, code-interpreter, and MCP SDKs plus generated clients\n- `specs/`: public OpenAPI contracts and examples\n- `kubernetes/`: Kubernetes operator, CRDs, task-executor, and Kind e2e tests\n- `manifests/charts/`: Helm charts (base, controller, server, ingress-gateway, node-agent, fast-sandbox, opensandbox umbrella)\n- `cli/`: `osb` command-line client and bundled CLI skills\n- `tests/`: cross-language end-to-end SDK tests\n- `docs/`, `examples/`, `oseps/`: documentation, samples, and proposals\n\n## Routing\n\n- For `server/**`, or lifecycle server behavior, sandbox creation flow, or user-visible server config, read `server/AGENTS.md`.\n- For `sdks/**`, or SDK generation, handwritten adapters, or cross-language SDK alignment, read `sdks/AGENTS.md`.\n- For `specs/**`, or API contract, schema, or example changes, read `specs/AGENTS.md`.\n- For `kubernetes/**`, or CRDs, controller behavior, task execution, Helm/Kustomize deployment, pool scheduling, pause/resume snapshots, or Kind e2e tests, read `kubernetes/AGENTS.md`.\n- For cross-cutting changes spanning spec, server, and SDKs, start with `specs/AGENTS.md` and then read affected consumer guides.\n- For runtime component changes under `components/**`, read the nearest `README.md` or `DEVELOPMENT.md`; keep component APIs aligned with `specs/` and SDK consumers.\n- For CLI changes under `cli/**`, read `cli/README.md` and verify command help/output behavior alongside unit tests.\n- For cross-language e2e tests under `tests/**`, read the language-local README and keep test assumptions aligned with current server and SDK behavior.\n- For areas without a local `AGENTS.md`, use the nearest `README.md`, `DEVELOPMENT.md`, and CI workflow as the next source of truth.\n\n## Working Principles\n\n- Think before coding: state assumptions, surface ambiguity, and ask or push back when the request has conflicting interpretations.\n- Simplicity first: implement the smallest solution that satisfies the request; avoid speculative features, one-off abstractions, and unnecessary configurability.\n- Surgical changes: touch only files and lines needed for the task, match local style, and do not refactor or delete unrelated pre-existing code.\n- Goal-driven execution: translate non-trivial work into verifiable success criteria, add or update focused tests when behavior changes, and loop until checks pass or blockers are clear.\n\n## Guardrails\n\nAlways:\n\n- Treat `specs/*` as public contract sources.\n- Keep spec, implementation, SDKs, docs, examples, config, and CLI behavior aligned when user-visible behavior changes; update `docs/` first.\n- When changing `specs/*`, also update or verify affected server, SDK, docs, and release outputs when practical.\n- When changing CRDs or Kubernetes public behavior, update or verify generated manifests, Helm/Kustomize deployment output, server Kubernetes integration, and docs when practical.\n- Prefer additive, backward-compatible changes for public interfaces.\n- Regenerate derived outputs when the source-of-truth file changes.\n- Mention unrun or blocked verification in the final handoff.\n- Prefer file-scoped or package-scoped checks before full-suite validation.\n\nAsk first:\n\n- Breaking public API, SDK, config, protocol, or CLI changes\n- Breaking CRD, annotation, label, Helm values, or Kubernetes deployment changes\n- Intentional drift between a public contract and its implementation\n- User-visible config or behavior changes without a clear migration story\n\nNever:\n\n- Edit generated output as the only fix.\n- Mix unrelated component work into the same change.\n\n## Documentation Rules\n\n### Content ownership — single source of truth\n\n| Content type | Source of truth | Rule |\n|---|---|---|\n| Root README | repo root `README.md` | GitHub homepage |\n| SDK, CLI, Helm, and other publishable package READMEs | package directory | Keep install, quick start, and package entry points; no long-form docs |\n| Non-publishable component/module READMEs | component/module directory | Keep minimal pointers to `docs/` when a docs page exists |\n| Examples | `docs/examples/` + runnable code under `examples/` | Put docs in `docs/examples/`; keep example READMEs as thin pointers |\n| OSEPs | `oseps/` | `docs/community/oseps.md` only indexes GitHub proposals |\n| CONTRIBUTING, CODE_OF_CONDUCT, DEVELOPMENT | repo root / component directory | `docs/community/` links to them, does not duplicate them |\n\n**When adding design/how-it-works content**: high-level architecture design and implementation principles go under `docs/architecture/`; user-facing usage instructions go under `docs/guides/`. Do not mix usage how-tos into architecture pages, or internals into guides.\n\n**When handling localized READMEs**: do not add new localized copies for SDKs, examples, or non-special modules.\n\n**When linking from README files to docs**: prefer repository-relative `docs/*.md` links (they match the checked-out branch/tag); use `https://open-sandbox.ai` only as a public site entry point, not as the only source link from versioned code directories.\n\n### Docs site structure\n\n```\ndocs/\n  getting-started/     # Quick start, installation, configuration\n  architecture/        # High-level architecture design and implementation principles (overview, control-plane/, data-plane/, network/, fast-sandbox/)\n  deployment/          # Deployment and operations (Kubernetes install, storage, metrics)\n  guides/              # User-facing usage and feature guides (credential vault, secure container, pause/resume, etc.)\n  sdks/                # SDK reference (one page per language per SDK)\n  api/                 # OpenAPI spec reference\n  cli/                 # CLI reference\n  examples/            # One page per example\n  community/           # Contributing, code of conduct, OSEPs, releases\n  reference/           # Migration guides\n```\n\n### Docs conventions\n\n- Engine: VitePress. Config is a static `config.mts` with no build-time code generation.\n- All images go in `docs/public/images/`. Reference them with a document-relative path to that directory (for example, `../public/images/filename` from `docs/guides/`) so they render in both repository previews and VitePress.\n- Every page must have YAML frontmatter with `title` and `description`.\n- Internal links use VitePress absolute paths (e.g., `/sdks/python`, `/guides/credential-vault`).\n- Links to source code or specs use full GitHub URLs.\n- Use VitePress custom containers (`::: tip`, `::: warning`, `::: info`) and code groups where appropriate.\n- Build and verify: `cd docs && pnpm docs:build` — must complete with zero errors.\n- The README.md in `docs/` is for docs-site contributors only (how to run dev server), and must stay excluded from the published site.\n- Markdown prose style, for all `.md` files in the repo: do not hard-wrap prose — a sentence or paragraph is written on a single line and editors soft-wrap. One line per list item and per blockquote paragraph.\n- Hard breaks (two trailing spaces or a trailing backslash) are only for intentional rendering, never for prose wrapping. Keep verbatim blocks untouched: code blocks, tables, YAML frontmatter, HTML blocks, ASCII diagrams. Never reflow generated markdown (e.g., helm-docs chart READMEs under `manifests/charts/*/README.md`) — change its source template and regenerate instead.\n- Never insert a blank line inside a paragraph, and never reflow or re-structure unrelated markdown while editing a file. When generating markdown programmatically, join soft-wrapped lines with a single space (no space between adjacent CJK characters).\n\n## Review Focus\n\n- Prioritize breaking changes in specs, SDK interfaces, config, CLI behavior, and protocols; flag protocol changes that are unnecessary, inconsistent, or hard to implement.\n- Flag changes that break source-of-truth boundaries or intended layering.\n- Call out missing tests and compatibility risks explicitly.\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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/alibaba/OpenSandbox/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# OpenSandbox AGENTS\n\nUse this file as the root router for the monorepo. Prefer the nearest `AGENTS.md` in the directory tree for task-specific instructions.\n\n## Repository Map\n\n- `server/`: FastAPI lifecycle control plane, Docker/Kubernetes runtime integration, snapshot metadata, and server tests\n- `components/execd/`: in-sandbox execution daemon\n- `components/egress/`: per-sandbox network egress policy sidecar\n- `components/ingress/`: ingress gateway and endpoint routing\n- `components/internal/`: shared Go helpers used by runtime components\n- `sdks/`: sandbox, code-interpreter, and MCP SDKs plus generated clients\n- `specs/`: public OpenAPI contracts and examples\n- `kubernetes/`: Kubernetes operator, CRDs, task-executor, and Kind e2e tests\n- `manifests/charts/`: Helm charts (base, controller, server, ingress-gateway, node-agent, fast-sandbox, opensandbox umbrella)\n- `cli/`: `osb` command-line client and bundled CLI skills\n- `tests/`: cross-language end-to-end SDK tests\n- `docs/`, `examples/`, `oseps/`: documentation, samples, and proposals\n\n## Routing\n\n- For `server/**`, or lifecycle server behavior, sandbox creation flow, or user-visible server config, read `server/AGENTS.md`.\n- For `sdks/**`, or SDK generation, handwritten adapters, or cross-language SDK alignment, read `sdks/AGENTS.md`.\n- For `specs/**`, or API contract, schema, or example changes, read `specs/AGENTS.md`.\n- For `kubernetes/**`, or CRDs, controller behavior, task execution, Helm/Kustomize deployment, pool scheduling, pause/resume snapshots, or Kind e2e tests, read `kubernetes/AGENTS.md`.\n- For cross-cutting changes spanning spec, server, and SDKs, start with `specs/AGENTS.md` and then read affected consumer guides.\n- For runtime component changes under `components/**`, read the nearest `README.md` or `DEVELOPMENT.md`; keep component APIs aligned with `specs/` and SDK consumers.\n- For CLI changes under `cli/**`, read `cli/README.md` and verify command help/output behavior alongside unit tests.\n- For cross-language e2e tests under `tests/**`, read the language-local README and keep test assumptions aligned with current server and SDK behavior.\n- For areas without a local `AGENTS.md`, use the nearest `README.md`, `DEVELOPMENT.md`, and CI workflow as the next source of truth.\n\n## Working Principles\n\n- Think before coding: state assumptions, surface ambiguity, and ask or push back when the request has conflicting interpretations.\n- Simplicity first: implement the smallest solution that satisfies the request; avoid speculative features, one-off abstractions, and unnecessary configurability.\n- Surgical changes: touch only files and lines needed for the task, match local style, and do not refactor or delete unrelated pre-existing code.\n- Goal-driven execution: translate non-trivial work into verifiable success criteria, add or update focused tests when behavior changes, and loop until checks pass or blockers are clear.\n\n## Guardrails\n\nAlways:\n\n- Treat `specs/*` as public contract sources.\n- Keep spec, implementation, SDKs, docs, examples, config, and CLI behavior aligned when user-visible behavior changes; update `docs/` first.\n- When changing `specs/*`, also update or verify affected server, SDK, docs, and release outputs when practical.\n- When changing CRDs or Kubernetes public behavior, update or verify generated manifests, Helm/Kustomize deployment output, server Kubernetes integration, and docs when practical.\n- Prefer additive, backward-compatible changes for public interfaces.\n- Regenerate derived outputs when the source-of-truth file changes.\n- Mention unrun or blocked verification in the final handoff.\n- Prefer file-scoped or package-scoped checks before full-suite validation.\n\nAsk first:\n\n- Breaking public API, SDK, config, protocol, or CLI changes\n- Breaking CRD, annotation, label, Helm values, or Kubernetes deployment changes\n- Intentional drift between a public contract and its implementation\n- User-visible config or behavior changes without a clear migration story\n\nNever:\n\n- Edit generated output as the only fix.\n- Mix unrelated component work into the same change.\n\n## Documentation Rules\n\n### Content ownership — single source of truth\n\n| Content type | Source of truth | Rule |\n|---|---|---|\n| Root README | repo root `README.md` | GitHub homepage |\n| SDK, CLI, Helm, and other publishable package READMEs | package directory | Keep install, quick start, and package entry points; no long-form docs |\n| Non-publishable component/module READMEs | component/module directory | Keep minimal pointers to `docs/` when a docs page exists |\n| Examples | `docs/examples/` + runnable code under `examples/` | Put docs in `docs/examples/`; keep example READMEs as thin pointers |\n| OSEPs | `oseps/` | `docs/community/oseps.md` only indexes GitHub proposals |\n| CONTRIBUTING, CODE_OF_CONDUCT, DEVELOPMENT | repo root / component directory | `docs/community/` links to them, does not duplicate them |\n\n**When adding design/how-it-works content**: high-level architecture design and implementation principles go under `docs/architecture/`; user-facing usage instructions go under `docs/guides/`. Do not mix usage how-tos into architecture pages, or internals into guides.\n\n**When handling localized READMEs**: do not add new localized copies for SDKs, examples, or non-special modules.\n\n**When linking from README files to docs**: prefer repository-relative `docs/*.md` links (they match the checked-out branch/tag); use `https://open-sandbox.ai` only as a public site entry point, not as the only source link from versioned code directories.\n\n### Docs site structure\n\n```\ndocs/\n  getting-started/     # Quick start, installation, configuration\n  architecture/        # High-level architecture design and implementation principles (overview, control-plane/, data-plane/, network/, fast-sandbox/)\n  deployment/          # Deployment and operations (Kubernetes install, storage, metrics)\n  guides/              # User-facing usage and feature guides (credential vault, secure container, pause/resume, etc.)\n  sdks/                # SDK reference (one page per language per SDK)\n  api/                 # OpenAPI spec reference\n  cli/                 # CLI reference\n  examples/            # One page per example\n  community/           # Contributing, code of conduct, OSEPs, releases\n  reference/           # Migration guides\n```\n\n### Docs conventions\n\n- Engine: VitePress. Config is a static `config.mts` with no build-time code generation.\n- All images go in `docs/public/images/`. Reference them with a document-relative path to that directory (for example, `../public/images/filename` from `docs/guides/`) so they render in both repository previews and VitePress.\n- Every page must have YAML frontmatter with `title` and `description`.\n- Internal links use VitePress absolute paths (e.g., `/sdks/python`, `/guides/credential-vault`).\n- Links to source code or specs use full GitHub URLs.\n- Use VitePress custom containers (`::: tip`, `::: warning`, `::: info`) and code groups where appropriate.\n- Build and verify: `cd docs && pnpm docs:build` — must complete with zero errors.\n- The README.md in `docs/` is for docs-site contributors only (how to run dev server), and must stay excluded from the published site.\n- Markdown prose style, for all `.md` files in the repo: do not hard-wrap prose — a sentence or paragraph is written on a single line and editors soft-wrap. One line per list item and per blockquote paragraph.\n- Hard breaks (two trailing spaces or a trailing backslash) are only for intentional rendering, never for prose wrapping. Keep verbatim blocks untouched: code blocks, tables, YAML frontmatter, HTML blocks, ASCII diagrams. Never reflow generated markdown (e.g., helm-docs chart READMEs under `manifests/charts/*/README.md`) — change its source template and regenerate instead.\n- Never insert a blank line inside a paragraph, and never reflow or re-structure unrelated markdown while editing a file. When generating markdown programmatically, join soft-wrapped lines with a single space (no space between adjacent CJK characters).\n\n## Review Focus\n\n- Prioritize breaking changes in specs, SDK interfaces, config, CLI behavior, and protocols; flag protocol changes that are unnecessary, inconsistent, or hard to implement.\n- Flag changes that break source-of-truth boundaries or intended layering.\n- Call out missing tests and compatibility risks explicitly.\n","isInternal":false,"tokens":1855,"sizeBytes":8430},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/alibaba/OpenSandbox/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# OpenSandbox Claude Guide\n\nSee `AGENTS.md` for all rules, routing, and conventions.\n","isInternal":false,"tokens":22,"sizeBytes":85},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":198},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":184},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":177}],"systemPromptSnippet":"<yakaai_skills repo=\"alibaba/OpenSandbox\">\n<!-- File: AGENTS.md (Tokens: ~1855 | Category: root-instruction) -->\n# OpenSandbox AGENTS\n\nUse this file as the root router for the monorepo. Prefer the nearest `AGENTS.md` in the directory tree for task-specific instructions.\n\n## Repository Map\n\n- `server/`: FastAPI lifecycle control plane, Docker/Kubernetes runtime integration, snapshot metadata, and server tests\n- `components/execd/`: in-sandbox execution daemon\n- `components/egress/`: per-sandbox network egress policy sidecar\n- `components/ingress/`: ingress gateway and endpoint routing\n- `components/internal/`: shared Go helpers used by runtime components\n- `sdks/`: sandbox, code-interpreter, and MCP SDKs plus generated clients\n- `specs/`: public OpenAPI contracts and examples\n- `kubernetes/`: Kubernetes operator, CRDs, task-executor, and Kind e2e tests\n- `manifests/charts/`: Helm charts (base, controller, server, ingress-gateway, node-agent, fast-sandbox, opensandbox umbrella)\n- `cli/`: `osb` command-line client and bundled CLI skills\n- `tests/`: cross-language end-to-end SDK tests\n- `docs/`, `examples/`, `oseps/`: documentation, samples, and proposals\n\n## Routing\n\n- For `server/**`, or lifecycle server behavior, sandbox creation flow, or user-visible server config, read `server/AGENTS.md`.\n- For `sdks/**`, or SDK generation, handwritten adapters, or cross-language SDK alignment, read `sdks/AGENTS.md`.\n- For `specs/**`, or API contract, schema, or example changes, read `specs/AGENTS.md`.\n- For `kubernetes/**`, or CRDs, controller behavior, task execution, Helm/Kustomize deployment, pool scheduling, pause/resume snapshots, or Kind e2e tests, read `kubernetes/AGENTS.md`.\n- For cross-cutting changes spanning spec, server, and SDKs, start with `specs/AGENTS.md` and then read affected consumer guides.\n- For runtime component changes under `components/**`, read the nearest `README.md` or `DEVELOPMENT.md`; keep component APIs aligned with `specs/` and SDK consumers.\n- For CLI changes under `cli/**`, read `cli/README.md` and verify command help/output behavior alongside unit tests.\n- For cross-language e2e tests under `tests/**`, read the language-local README and keep test assumptions aligned with current server and SDK behavior.\n- For areas without a local `AGENTS.md`, use the nearest `README.md`, `DEVELOPMENT.md`, and CI workflow as the next source of truth.\n\n## Working Principles\n\n- Think before coding: state assumptions, surface ambiguity, and ask or push back when the request has conflicting interpretations.\n- Simplicity first: implement the smallest solution that satisfies the request; avoid speculative features, one-off abstractions, and unnecessary configurability.\n- Surgical changes: touch only files and lines needed for the task, match local style, and do not refactor or delete unrelated pre-existing code.\n- Goal-driven execution: translate non-trivial work into verifiable success criteria, add or update focused tests when behavior changes, and loop until checks pass or blockers are clear.\n\n## Guardrails\n\nAlways:\n\n- Treat `specs/*` as public contract sources.\n- Keep spec, implementation, SDKs, docs, examples, config, and CLI behavior aligned when user-visible behavior changes; update `docs/` first.\n- When changing `specs/*`, also update or verify affected server, SDK, docs, and release outputs when practical.\n- When changing CRDs or Kubernetes public behavior, update or verify generated manifests, Helm/Kustomize deployment output, server Kubernetes integration, and docs when practical.\n- Prefer additive, backward-compatible changes for public interfaces.\n- Regenerate derived outputs when the source-of-truth file changes.\n- Mention unrun or blocked verification in the final handoff.\n- Prefer file-scoped or package-scoped checks before full-suite validation.\n\nAsk first:\n\n- Breaking public API, SDK, config, protocol, or CLI changes\n- Breaking CRD, annotation, label, Helm values, or Kubernetes deployment changes\n- Intentional drift between a public contract and its implementation\n- User-visible config or behavior changes without a clear migration story\n\nNever:\n\n- Edit generated output as the only fix.\n- Mix unrelated component work into the same change.\n\n## Documentation Rules\n\n### Content ownership — single source of truth\n\n| Content type | Source of truth | Rule |\n|---|---|---|\n| Root README | repo root `README.md` | GitHub homepage |\n| SDK, CLI, Helm, and other publishable package READMEs | package directory | Keep install, quick start, and package entry points; no long-form docs |\n| Non-publishable component/module READMEs | component/module directory | Keep minimal pointers to `docs/` when a docs page exists |\n| Examples | `docs/examples/` + runnable code under `examples/` | Put docs in `docs/examples/`; keep example READMEs as thin pointers |\n| OSEPs | `oseps/` | `docs/community/oseps.md` only indexes GitHub proposals |\n| CONTRIBUTING, CODE_OF_CONDUCT, DEVELOPMENT | repo root / component directory | `docs/community/` links to them, does not duplicate them |\n\n**When adding design/how-it-works content**: high-level architecture design and implementation principles go under `docs/architecture/`; user-facing usage instructions go under `docs/guides/`. Do not mix usage how-tos into architecture pages, or internals into guides.\n\n**When handling localized READMEs**: do not add new localized copies for SDKs, examples, or non-special modules.\n\n**When linking from README files to docs**: prefer repository-relative `docs/*.md` links (they match the checked-out branch/tag); use `https://open-sandbox.ai` only as a public site entry point, not as the only source link from versioned code directories.\n\n### Docs site structure\n\n```\ndocs/\n  getting-started/     # Quick start, installation, configuration\n  architecture/        # High-level architecture design and implementation principles (overview, control-plane/, data-plane/, network/, fast-sandbox/)\n  deployment/          # Deployment and operations (Kubernetes install, storage, metrics)\n  guides/              # User-facing usage and feature guides (credential vault, secure container, pause/resume, etc.)\n  sdks/                # SDK reference (one page per language per SDK)\n  api/                 # OpenAPI spec reference\n  cli/                 # CLI reference\n  examples/            # One page per example\n  community/           # Contributing, code of conduct, OSEPs, releases\n  reference/           # Migration guides\n```\n\n### Docs conventions\n\n- Engine: VitePress. Config is a static `config.mts` with no build-time code generation.\n- All images go in `docs/public/images/`. Reference them with a document-relative path to that directory (for example, `../public/images/filename` from `docs/guides/`) so they render in both repository previews and VitePress.\n- Every page must have YAML frontmatter with `title` and `description`.\n- Internal links use VitePress absolute paths (e.g., `/sdks/python`, `/guides/credential-vault`).\n- Links to source code or specs use full GitHub URLs.\n- Use VitePress custom containers (`::: tip`, `::: warning`, `::: info`) and code groups where appropriate.\n- Build and verify: `cd docs && pnpm docs:build` — must complete with zero errors.\n- The README.md in `docs/` is for docs-site contributors only (how to run dev server), and must stay excluded from the published site.\n- Markdown prose style, for all `.md` files in the repo: do not hard-wrap prose — a sentence or paragraph is written on a single line and editors soft-wrap. One line per list item and per blockquote paragraph.\n- Hard breaks (two trailing spaces or a trailing backslash) are only for intentional rendering, never for prose wrapping. Keep verbatim blocks untouched: code blocks, tables, YAML frontmatter, HTML blocks, ASCII diagrams. Never reflow generated markdown (e.g., helm-docs chart READMEs under `manifests/charts/*/README.md`) — change its source template and regenerate instead.\n- Never insert a blank line inside a paragraph, and never reflow or re-structure unrelated markdown while editing a file. When generating markdown programmatically, join soft-wrapped lines with a single space (no space between adjacent CJK characters).\n\n## Review Focus\n\n- Prioritize breaking changes in specs, SDK interfaces, config, CLI behavior, and protocols; flag protocol changes that are unnecessary, inconsistent, or hard to implement.\n- Flag changes that break source-of-truth boundaries or intended layering.\n- Call out missing tests and compatibility risks explicitly.\n\n<!-- File: CLAUDE.md (Tokens: ~22 | Category: claude-rule) -->\n# OpenSandbox Claude Guide\n\nSee `AGENTS.md` for all rules, routing, and conventions.\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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/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/alibaba/OpenSandbox/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}