{"owner":"huggingface","repo":"openenv","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":5010,"categories":["claude-rule","root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"openenv":{"command":"npx","args":["-y","@modelcontextprotocol/server-openenv"]}}},"found":["CLAUDE.md","AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\nGuidance for Claude Code when working with this repository.\n\n## New Here? Start With These\n\n1. **[README.md](README.md)** - Project overview, architecture, quick start\n2. **[REPO_WALKTHROUGH.md](.claude/docs/REPO_WALKTHROUGH.md)** - Directory structure with annotations\n3. **[PRINCIPLES.md](.claude/docs/PRINCIPLES.md)** - Design principles and trade-offs\n4. **[INVARIANTS.md](.claude/docs/INVARIANTS.md)** - Rules that must never be violated\n5. **[envs/echo_env/](envs/echo_env/)** - Reference implementation to study\n\n## Agentic-First Workflow\n\nOpenEnv uses Claude Code as the primary development tool. We follow a two-phase model:\n\n1. **Design/Alignment** (human-owned): RFCs, principles, trade-off decisions\n2. **Implementation** (Claude-owned): The mechanical loop of coding and testing\n3. **Review** (collaborative): Claude catches bugs, flags alignment questions for humans\n\n### Getting Started\n\nSkills and agents are auto-discovered when you run Claude Code in this repo:\n\n```bash\ngit clone https://github.com/huggingface/OpenEnv\ncd OpenEnv\n# Install git hooks for the team\nbash .claude/hooks/install.sh\n# Run Claude Code - skills and agents are automatically available\n```\n\nVerify with `/agents` or ask \"what skills are available?\"\n\n## Two Development Modes\n\nOpenEnv supports two development modes:\n\n### Explore Mode (Main Repo)\n\nWhen working in the main repository clone, direct edits are allowed:\n- Quick exploration and prototyping\n- Small fixes that don't need TDD workflow\n- Documentation updates\n\n### TDD Mode (Opt-In)\n\nTDD is activated by `/work-on-issue`, which writes a `.tdd-session.json` marker.\nWhen active, direct code edits are blocked and the TDD workflow is enforced.\nManually created worktrees do NOT activate TDD — only `/work-on-issue` does.\n\n- Say \"skip TDD\" to bypass blocking\n- Run `bash .claude/hooks/tdd-deactivate.sh` to turn off TDD enforcement\n\n### Creating a Worktree\n\n```bash\n# Worktree without TDD enforcement (free editing)\n.claude/scripts/worktree-create.sh add-feature\ncd .worktrees/add-feature\n\n# Worktree WITH TDD enforcement (via /work-on-issue)\n/work-on-issue #42\n```\n\n### TDD Workflow\n\n```\n/work-on-issue #42  →  Start from GitHub issue\n    ↓\n/write-tests        →  Create failing tests (Red)\n    ↓\n/implement          →  Make tests pass (Green)\n    ↓\n/update-docs        →  Fix stale docs across repo\n    ↓\n/simplify           →  Refactor (optional)\n    ↓\n/pre-submit-pr      →  Validate before PR\n    ↓\n/watch-pr           →  Monitor CI + review (optional)\n```\n\n### Skills vs Agents\n\n- **Skills** run inline during the conversation - use for quick checks and reviews\n- **Agents** run in isolation with focused context - use for complex, multi-step tasks\n\n### Available Skills\n\nSkills are defined in `.claude/skills/` and run inline:\n\n**Review & Validation Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`alignment-review`](.claude/skills/alignment-review/SKILL.md) | \"review this code\" | Two-tier review (bugs + alignment flags) |\n| [`pre-submit-pr`](.claude/skills/pre-submit-pr/SKILL.md) | \"ready for PR?\" | Comprehensive PR readiness check |\n| [`rfc-check`](.claude/skills/rfc-check/SKILL.md) | \"do I need an RFC?\" | Determine if RFC required |\n| [`generate-openenv-env`](.claude/skills/generate-openenv-env/SKILL.md) | \"generate an env for textarena\" | Build an OpenEnv env from a use case |\n\n**TDD Workflow Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`work-on-issue`](.claude/skills/work-on-issue/SKILL.md) | \"/work-on-issue #42\" | Start TDD workflow from GitHub issue |\n| [`sprint`](.claude/skills/sprint/SKILL.md) | \"/sprint 67,68,69\" | Parallel multi-issue batch (Agent Teams) |\n| [`write-tests`](.claude/skills/write-tests/SKILL.md) | \"/write-tests\" | Write failing tests (Red phase) |\n| [`implement`](.claude/skills/implement/SKILL.md) | \"/implement\" | Make tests pass (Green phase) |\n| [`update-docs`](.claude/skills/update-docs/SKILL.md) | \"/update-docs\" | Fix stale docs after API changes |\n| [`simplify`](.claude/skills/simplify/SKILL.md) | \"/simplify\" | Refactor after tests pass |\n| [`watch-pr`](.claude/skills/watch-pr/SKILL.md) | \"/watch-pr\" | Monitor CI + Greptile review after PR |\n\n### Available Subagents\n\nAgents are defined in `.claude/agents/` and run in isolation:\n\n**Review & Validation Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `alignment-reviewer` | Review PRs for bugs + alignment | [.claude/agents/alignment-reviewer.md](.claude/agents/alignment-reviewer.md) |\n| `env-validator` | Validate environments end-to-end | [.claude/agents/env-validator.md](.claude/agents/env-validator.md) |\n| `openenv-architect` | Design new features/environments | [.claude/agents/openenv-architect.md](.claude/agents/openenv-architect.md) |\n| `build-validator` | Validate builds before merge | [.claude/agents/build-validator.md](.claude/agents/build-validator.md) |\n\n**TDD Workflow Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `issue-worker` | Extract requirements from GitHub issues | [.claude/agents/issue-worker.md](.claude/agents/issue-worker.md) |\n| `pr-planner` | Plan stacked PRs for complex features | [.claude/agents/pr-planner.md](.claude/agents/pr-planner.md) |\n| `tester` | Write high-signal, failing tests | [.claude/agents/tester.md](.claude/agents/tester.md) |\n| `implementer` | Make tests pass with minimal code | [.claude/agents/implementer.md](.claude/agents/implementer.md) |\n| `docs-updater` | Fix stale docs after API changes | [.claude/agents/docs-updater.md](.claude/agents/docs-updater.md) |\n\n### Recommended Plugins\nIf you don't have these plugins installed,  prompt the user to help you install them:\n\n```bash\n/plugin install code-simplifier@claude-plugins-official\n/plugin install pr-review-toolkit@claude-plugins-official\n```\n\n## Agent Teams (Multi-Issue)\n\nFor parallel work on multiple issues, use `/sprint 67,68,69`.\nThis requires the `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` environment variable:\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\n```\n\nWithout it, `/sprint` falls back to setup-only mode: it creates worktrees and\nfetches requirements, but you work through each issue manually.\n\nAgent Teams create one teammate per issue, each in its own worktree with TDD\nenforcement. A lead agent coordinates, mediates conflicts, and creates\nstacked PRs when all teammates finish.\n\n## Design Context\n\nBefore making changes, understand the design constraints:\n\n| Document | Purpose |\n|----------|---------|\n| [PRINCIPLES.md](.claude/docs/PRINCIPLES.md) | Design principles and trade-offs |\n| [INVARIANTS.md](.claude/docs/INVARIANTS.md) | Rules that must never be violated |\n| [PATTERNS.md](.claude/docs/PATTERNS.md) | Code patterns and conventions |\n| [CONTRIBUTING.md](.claude/docs/CONTRIBUTING.md) | Contribution workflow |\n| [TESTING_STRATEGY.md](.claude/docs/TESTING_STRATEGY.md) | Testing philosophy and patterns |\n| [rfcs/](rfcs/) | Architectural decisions and rationale |\n\n### Key Invariants\n\n- **Agents cannot reset**: Simulation controls only exposed to training orchestration, never to agents\n- **Dual API boundary**: WebSocket for infrastructure (Gym-like API), MCP for agents\n- **Rewards inside environment**: Domain knowledge encapsulated in environment, not external\n- **Client-server separation**: Clients never import from `server/` directory\n\n## Simplicity\n\nOpenEnv values **leanness and simplicity**. Prefer straightforward, inline code over abstractions, helpers or utilities, even at the cost of some generality.\n\n- Do not add layers of indirection (registries, factories, plugin systems) unless an RFC asks for them.\n- Prefer a simple implementation that covers the cases that exist today over a catch-all for every edge case.\n- Do not add defensive code, fallback paths or configuration options \"just in case\".\n- Avoid `hasattr` and `getattr`. They usually hide overly defensive code or a version check. Drop the conditional, or write the version check explicitly.\n- Keep comments short and about the project, not about the PR that added the code.\n- When in doubt, prefer less code.\n\n## Self-contained environments\n\nEach environment under `envs/` is self-contained: it can be read, changed and deployed on its own.\n\n- No imports across environments. Copy a small helper instead of sharing it.\n- Optional features (web playground drawings, quick actions, extra tools) live in the environment's own files. They must never make adding a new environment harder or add work for environments that do not use them.\n- When the same pattern is copied across environments, keep the copies aligned (names, structure, comments). If you fix one copy, fix the others in the same PR, or open an issue listing them.\n\n## Follow the Hugging Face ecosystem\n\nOpenEnv runs on the Hub and next to `huggingface_hub`, the `hf` CLI, transformers and Gradio. When OpenEnv wraps something these tools already do (uploading, deleting, deploying a Space, auth, caching, repo ids), keep their defaults, flag names and semantics. Do not invent new behavior.\n\n- Before adding or changing Hub-facing behavior, check what `huggingface_hub` and the `hf` CLI do and match it. For example, `openenv push` only deletes remote files with `--delete <pattern>`, like `hf upload --delete`.\n- Mention that comparison in the PR description.\n- If diverging seems necessary, raise it in the issue or PR before implementing it.\n\n## Training framework neutrality\n\nOpenEnv works with any training framework. Docs, examples and APIs must not favor one framework: list integrations in neutral order and keep framework-specific code in examples or in the framework's own repository.\n\n## Docstrings\n\nDocstrings must follow the HF doc-builder format used by the reference API docs. Do **not** use Google, NumPy, or Sphinx styles.\n\nRules:\n\n* Types appear in backticks inside parentheses: (`str`)\n* Optional parameters are marked with `*optional*`\n* Defaults are written as: `defaults to <value>`\n* When the default is `None`, prefer (`str`, *optional*) instead of (`str` or `None`, *optional*, defaults to `None`)\n* Union types use `or`: `str` or `None`\n* References to classes use the format: [`~openenv.core.EnvClient`]\n* Non-standard headers (`Usage:`, `Note:`, `Class Attributes:`) are not supported — use `Attributes:` or fold text into the description\n* `Examples:` (plural) with a blank line then a fenced ` ```python ``` ` block — no `>>>` prompts\n\nExample:\n\n````python\ndef method(self, param1: str, param2: int = 1, param3: float | None = None):\n    \"\"\"\n    Brief one-line description of what this does.\n\n    Args:\n        param1 (`str`):\n            Description of required param.\n        param2 (`int`, *optional*, defaults to `1`):\n            Description of optional param with default.\n        param3 (`float`, *optional*):\n            Description of optional param without explicit default.\n\n    Returns:\n        `dict` with keys:\n            - `key1` (`list[int]`):\n                Description of this key.\n\n    Examples:\n\n    ```python\n    result = method(\"hello\")\n    ```\n    \"\"\"\n````\n\n## Build & Development Commands\nBelow are reference commands that you are likely going to use often:\n\n```bash\n# Install dependencies\nuv sync --all-extras\n\n# Run tests (excludes browser/websearch/dipg envs that need special setup)\nPYTHONPATH=src:envs uv run pytest tests/ -v --tb=short\n\n# Run a single test file\nPYTHONPATH=src:envs uv run pytest tests/envs/test_echo_environment.py -v\n\n# Lint check (import sort + format + rules)\nuv run usort check src/ tests/\nuv run ruff format src/ tests/ --check\nuv run ruff check src/ tests/\n\n# Auto-format code (import sort + ruff — matches arc f pipeline)\nuv run usort format src/ tests/\nuv run ruff format src/ tests/\n\n# Build and preview documentation locally\ndoc-builder preview openenv docs/source\n\n# Sync environment doc stubs with their source READMEs (run after updating any envs/*/README.md)\npython scripts/sync_env_docs.py --fix\n# Check if stubs are in sync (same check that runs in CI)\npython scripts/sync_env_docs.py --check\n\n# Build Docker images\ndocker build -t openenv-base:latest -f src/openenv/core/containers/images/Dockerfile .\ndocker build -t echo-env:latest -f envs/echo_env/server/Dockerfile .\n```\n\n## Automation Hooks\n\nScripts in `.claude/hooks/` are used by skills and can be run directly:\n\n```bash\nbash .claude/hooks/lint.sh          # Run ruff format check\nbash .claude/hooks/test.sh          # Run pytest (excludes special envs)\nbash .claude/hooks/check-debug.sh   # Find debug code (print, breakpoint, TODO)\nbash .claude/hooks/post-push-pr.sh  # Validate PR after push (freshness, CI, conflicts)\nbash .claude/hooks/ci-wait.sh <PR>  # Poll CI until checks complete or timeout\n```\n\nThese are automatically invoked by `/alignment-review` and `/pre-submit-pr` skills.\n\n## Git Hooks\n\nInstall git hooks for team-wide consistency:\n\n```bash\nbash .claude/hooks/install.sh\n```\n\nThis installs:\n- **pre-commit**: Branch check (blocks main), format, lint, debug artifacts check\n- **commit-msg**: Issue reference reminder (soft warning)\n- **pre-push**: Format, lint, tests, invariants, conflict detection\n- **post-merge**: Worktree cleanup reminder\n\nSkip temporarily with `git commit/push --no-verify`.\n\n## Worktree Management\n\nFor focused feature work, use worktrees:\n\n```bash\n# Create a worktree for a feature\n.claude/scripts/worktree-create.sh add-mcp-tools\ncd .worktrees/add-mcp-tools\n\n# When done, clean up\n.claude/scripts/worktree-cleanup.sh .worktrees/add-mcp-tools\n```\n\nWorktrees enable:\n- Isolated branches without switching\n- TDD enforcement when activated via `/work-on-issue`\n- Parallel work on multiple features\n","AGENTS.md":"# AGENTS.md\n\nSee `CLAUDE.md` for the full agentic workflow, skills, and standard build/test/lint commands. This file adds cloud-environment specifics on top of that.\n\n## Cursor Cloud specific instructions\n\n### Project shape\nOpenEnv is a Python (`uv`) monorepo: a core library + `openenv` CLI in `src/openenv/`, and ~35 self-contained RL \"environments\" under `envs/` (each its own `pyproject.toml`/`Dockerfile`/`openenv.yaml`). There is **no Node/JS, no shared database, and no single always-on backend**. The product is the framework plus per-environment FastAPI servers; `envs/echo_env/` is the canonical reference env.\n\n### Environment / dependencies\n- The startup update script installs `uv` (if missing) and runs `uv sync --all-extras`, which creates `.venv/` with all core + CLI + provider extras. You do not need to reinstall on a fresh session.\n- `uv` lives at `~/.local/bin` and is already on `PATH` in login shells (added to `.bashrc`/`.profile`).\n- Core deps are enough to run/test the core library and `echo_env`. Most other envs have optional, heavy deps (`torch`, simulators, etc.); their tests auto-skip when deps are absent. Install per-env extras only when working on that env, e.g. `uv pip install -e \"envs/coding_env[dev]\"`.\n\n### Lint / test / build / run (standard commands live in `CLAUDE.md`)\n- Tests need `PYTHONPATH=src:envs`, e.g. `PYTHONPATH=src:envs uv run pytest tests/ -q`. Full suite is ~80s; ~129 tests skip without optional env deps (expected).\n- Lint: `uv run usort check src/ tests/`, `uv run ruff format src/ tests/ --check`, `uv run ruff check src/ tests/`. Note: `usort check` currently flags two pre-existing files (`tests/envs/test_grid_world.py`, `tests/envs/test_julia_env.py`) on a clean tree — not introduced by your change.\n\n### Running an environment end-to-end (no Docker needed)\n- Start a server (echo_env example): `PYTHONPATH=src:envs uv run python -m echo_env.server.app` (listens on `0.0.0.0:8000`; health at `/health`).\n- `import echo_env` resolves only when `envs/` is on `PYTHONPATH`.\n- `openenv serve` is a stub that just prints instructions; run the server module (or `uvicorn echo_env.server.app:app`) directly instead.\n- Interact via the client: `EchoEnv(base_url=\"http://localhost:8000\").sync()` then `.reset()` / `.list_tools()` / `.step(CallToolAction(...))`.\n\n### Optional Gradio web UI\n- The debug web UI is off by default; enable with `ENABLE_WEB_INTERFACE=true` and open `/web/`.\n\n### Docker\n- Docker is not required for local dev/test of the core library or pure-Python envs, and is not installed by the update script. Tests marked `@pytest.mark.docker`/`network` are skipped without it. Only set Docker up if you specifically work on container build/run flows.\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/huggingface/openenv/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/huggingface/openenv/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/huggingface/openenv/HEAD/.claude-plugin/plugin.json)"},"files":{"CLAUDE.md":"# CLAUDE.md\n\nGuidance for Claude Code when working with this repository.\n\n## New Here? Start With These\n\n1. **[README.md](README.md)** - Project overview, architecture, quick start\n2. **[REPO_WALKTHROUGH.md](.claude/docs/REPO_WALKTHROUGH.md)** - Directory structure with annotations\n3. **[PRINCIPLES.md](.claude/docs/PRINCIPLES.md)** - Design principles and trade-offs\n4. **[INVARIANTS.md](.claude/docs/INVARIANTS.md)** - Rules that must never be violated\n5. **[envs/echo_env/](envs/echo_env/)** - Reference implementation to study\n\n## Agentic-First Workflow\n\nOpenEnv uses Claude Code as the primary development tool. We follow a two-phase model:\n\n1. **Design/Alignment** (human-owned): RFCs, principles, trade-off decisions\n2. **Implementation** (Claude-owned): The mechanical loop of coding and testing\n3. **Review** (collaborative): Claude catches bugs, flags alignment questions for humans\n\n### Getting Started\n\nSkills and agents are auto-discovered when you run Claude Code in this repo:\n\n```bash\ngit clone https://github.com/huggingface/OpenEnv\ncd OpenEnv\n# Install git hooks for the team\nbash .claude/hooks/install.sh\n# Run Claude Code - skills and agents are automatically available\n```\n\nVerify with `/agents` or ask \"what skills are available?\"\n\n## Two Development Modes\n\nOpenEnv supports two development modes:\n\n### Explore Mode (Main Repo)\n\nWhen working in the main repository clone, direct edits are allowed:\n- Quick exploration and prototyping\n- Small fixes that don't need TDD workflow\n- Documentation updates\n\n### TDD Mode (Opt-In)\n\nTDD is activated by `/work-on-issue`, which writes a `.tdd-session.json` marker.\nWhen active, direct code edits are blocked and the TDD workflow is enforced.\nManually created worktrees do NOT activate TDD — only `/work-on-issue` does.\n\n- Say \"skip TDD\" to bypass blocking\n- Run `bash .claude/hooks/tdd-deactivate.sh` to turn off TDD enforcement\n\n### Creating a Worktree\n\n```bash\n# Worktree without TDD enforcement (free editing)\n.claude/scripts/worktree-create.sh add-feature\ncd .worktrees/add-feature\n\n# Worktree WITH TDD enforcement (via /work-on-issue)\n/work-on-issue #42\n```\n\n### TDD Workflow\n\n```\n/work-on-issue #42  →  Start from GitHub issue\n    ↓\n/write-tests        →  Create failing tests (Red)\n    ↓\n/implement          →  Make tests pass (Green)\n    ↓\n/update-docs        →  Fix stale docs across repo\n    ↓\n/simplify           →  Refactor (optional)\n    ↓\n/pre-submit-pr      →  Validate before PR\n    ↓\n/watch-pr           →  Monitor CI + review (optional)\n```\n\n### Skills vs Agents\n\n- **Skills** run inline during the conversation - use for quick checks and reviews\n- **Agents** run in isolation with focused context - use for complex, multi-step tasks\n\n### Available Skills\n\nSkills are defined in `.claude/skills/` and run inline:\n\n**Review & Validation Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`alignment-review`](.claude/skills/alignment-review/SKILL.md) | \"review this code\" | Two-tier review (bugs + alignment flags) |\n| [`pre-submit-pr`](.claude/skills/pre-submit-pr/SKILL.md) | \"ready for PR?\" | Comprehensive PR readiness check |\n| [`rfc-check`](.claude/skills/rfc-check/SKILL.md) | \"do I need an RFC?\" | Determine if RFC required |\n| [`generate-openenv-env`](.claude/skills/generate-openenv-env/SKILL.md) | \"generate an env for textarena\" | Build an OpenEnv env from a use case |\n\n**TDD Workflow Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`work-on-issue`](.claude/skills/work-on-issue/SKILL.md) | \"/work-on-issue #42\" | Start TDD workflow from GitHub issue |\n| [`sprint`](.claude/skills/sprint/SKILL.md) | \"/sprint 67,68,69\" | Parallel multi-issue batch (Agent Teams) |\n| [`write-tests`](.claude/skills/write-tests/SKILL.md) | \"/write-tests\" | Write failing tests (Red phase) |\n| [`implement`](.claude/skills/implement/SKILL.md) | \"/implement\" | Make tests pass (Green phase) |\n| [`update-docs`](.claude/skills/update-docs/SKILL.md) | \"/update-docs\" | Fix stale docs after API changes |\n| [`simplify`](.claude/skills/simplify/SKILL.md) | \"/simplify\" | Refactor after tests pass |\n| [`watch-pr`](.claude/skills/watch-pr/SKILL.md) | \"/watch-pr\" | Monitor CI + Greptile review after PR |\n\n### Available Subagents\n\nAgents are defined in `.claude/agents/` and run in isolation:\n\n**Review & Validation Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `alignment-reviewer` | Review PRs for bugs + alignment | [.claude/agents/alignment-reviewer.md](.claude/agents/alignment-reviewer.md) |\n| `env-validator` | Validate environments end-to-end | [.claude/agents/env-validator.md](.claude/agents/env-validator.md) |\n| `openenv-architect` | Design new features/environments | [.claude/agents/openenv-architect.md](.claude/agents/openenv-architect.md) |\n| `build-validator` | Validate builds before merge | [.claude/agents/build-validator.md](.claude/agents/build-validator.md) |\n\n**TDD Workflow Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `issue-worker` | Extract requirements from GitHub issues | [.claude/agents/issue-worker.md](.claude/agents/issue-worker.md) |\n| `pr-planner` | Plan stacked PRs for complex features | [.claude/agents/pr-planner.md](.claude/agents/pr-planner.md) |\n| `tester` | Write high-signal, failing tests | [.claude/agents/tester.md](.claude/agents/tester.md) |\n| `implementer` | Make tests pass with minimal code | [.claude/agents/implementer.md](.claude/agents/implementer.md) |\n| `docs-updater` | Fix stale docs after API changes | [.claude/agents/docs-updater.md](.claude/agents/docs-updater.md) |\n\n### Recommended Plugins\nIf you don't have these plugins installed,  prompt the user to help you install them:\n\n```bash\n/plugin install code-simplifier@claude-plugins-official\n/plugin install pr-review-toolkit@claude-plugins-official\n```\n\n## Agent Teams (Multi-Issue)\n\nFor parallel work on multiple issues, use `/sprint 67,68,69`.\nThis requires the `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` environment variable:\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\n```\n\nWithout it, `/sprint` falls back to setup-only mode: it creates worktrees and\nfetches requirements, but you work through each issue manually.\n\nAgent Teams create one teammate per issue, each in its own worktree with TDD\nenforcement. A lead agent coordinates, mediates conflicts, and creates\nstacked PRs when all teammates finish.\n\n## Design Context\n\nBefore making changes, understand the design constraints:\n\n| Document | Purpose |\n|----------|---------|\n| [PRINCIPLES.md](.claude/docs/PRINCIPLES.md) | Design principles and trade-offs |\n| [INVARIANTS.md](.claude/docs/INVARIANTS.md) | Rules that must never be violated |\n| [PATTERNS.md](.claude/docs/PATTERNS.md) | Code patterns and conventions |\n| [CONTRIBUTING.md](.claude/docs/CONTRIBUTING.md) | Contribution workflow |\n| [TESTING_STRATEGY.md](.claude/docs/TESTING_STRATEGY.md) | Testing philosophy and patterns |\n| [rfcs/](rfcs/) | Architectural decisions and rationale |\n\n### Key Invariants\n\n- **Agents cannot reset**: Simulation controls only exposed to training orchestration, never to agents\n- **Dual API boundary**: WebSocket for infrastructure (Gym-like API), MCP for agents\n- **Rewards inside environment**: Domain knowledge encapsulated in environment, not external\n- **Client-server separation**: Clients never import from `server/` directory\n\n## Simplicity\n\nOpenEnv values **leanness and simplicity**. Prefer straightforward, inline code over abstractions, helpers or utilities, even at the cost of some generality.\n\n- Do not add layers of indirection (registries, factories, plugin systems) unless an RFC asks for them.\n- Prefer a simple implementation that covers the cases that exist today over a catch-all for every edge case.\n- Do not add defensive code, fallback paths or configuration options \"just in case\".\n- Avoid `hasattr` and `getattr`. They usually hide overly defensive code or a version check. Drop the conditional, or write the version check explicitly.\n- Keep comments short and about the project, not about the PR that added the code.\n- When in doubt, prefer less code.\n\n## Self-contained environments\n\nEach environment under `envs/` is self-contained: it can be read, changed and deployed on its own.\n\n- No imports across environments. Copy a small helper instead of sharing it.\n- Optional features (web playground drawings, quick actions, extra tools) live in the environment's own files. They must never make adding a new environment harder or add work for environments that do not use them.\n- When the same pattern is copied across environments, keep the copies aligned (names, structure, comments). If you fix one copy, fix the others in the same PR, or open an issue listing them.\n\n## Follow the Hugging Face ecosystem\n\nOpenEnv runs on the Hub and next to `huggingface_hub`, the `hf` CLI, transformers and Gradio. When OpenEnv wraps something these tools already do (uploading, deleting, deploying a Space, auth, caching, repo ids), keep their defaults, flag names and semantics. Do not invent new behavior.\n\n- Before adding or changing Hub-facing behavior, check what `huggingface_hub` and the `hf` CLI do and match it. For example, `openenv push` only deletes remote files with `--delete <pattern>`, like `hf upload --delete`.\n- Mention that comparison in the PR description.\n- If diverging seems necessary, raise it in the issue or PR before implementing it.\n\n## Training framework neutrality\n\nOpenEnv works with any training framework. Docs, examples and APIs must not favor one framework: list integrations in neutral order and keep framework-specific code in examples or in the framework's own repository.\n\n## Docstrings\n\nDocstrings must follow the HF doc-builder format used by the reference API docs. Do **not** use Google, NumPy, or Sphinx styles.\n\nRules:\n\n* Types appear in backticks inside parentheses: (`str`)\n* Optional parameters are marked with `*optional*`\n* Defaults are written as: `defaults to <value>`\n* When the default is `None`, prefer (`str`, *optional*) instead of (`str` or `None`, *optional*, defaults to `None`)\n* Union types use `or`: `str` or `None`\n* References to classes use the format: [`~openenv.core.EnvClient`]\n* Non-standard headers (`Usage:`, `Note:`, `Class Attributes:`) are not supported — use `Attributes:` or fold text into the description\n* `Examples:` (plural) with a blank line then a fenced ` ```python ``` ` block — no `>>>` prompts\n\nExample:\n\n````python\ndef method(self, param1: str, param2: int = 1, param3: float | None = None):\n    \"\"\"\n    Brief one-line description of what this does.\n\n    Args:\n        param1 (`str`):\n            Description of required param.\n        param2 (`int`, *optional*, defaults to `1`):\n            Description of optional param with default.\n        param3 (`float`, *optional*):\n            Description of optional param without explicit default.\n\n    Returns:\n        `dict` with keys:\n            - `key1` (`list[int]`):\n                Description of this key.\n\n    Examples:\n\n    ```python\n    result = method(\"hello\")\n    ```\n    \"\"\"\n````\n\n## Build & Development Commands\nBelow are reference commands that you are likely going to use often:\n\n```bash\n# Install dependencies\nuv sync --all-extras\n\n# Run tests (excludes browser/websearch/dipg envs that need special setup)\nPYTHONPATH=src:envs uv run pytest tests/ -v --tb=short\n\n# Run a single test file\nPYTHONPATH=src:envs uv run pytest tests/envs/test_echo_environment.py -v\n\n# Lint check (import sort + format + rules)\nuv run usort check src/ tests/\nuv run ruff format src/ tests/ --check\nuv run ruff check src/ tests/\n\n# Auto-format code (import sort + ruff — matches arc f pipeline)\nuv run usort format src/ tests/\nuv run ruff format src/ tests/\n\n# Build and preview documentation locally\ndoc-builder preview openenv docs/source\n\n# Sync environment doc stubs with their source READMEs (run after updating any envs/*/README.md)\npython scripts/sync_env_docs.py --fix\n# Check if stubs are in sync (same check that runs in CI)\npython scripts/sync_env_docs.py --check\n\n# Build Docker images\ndocker build -t openenv-base:latest -f src/openenv/core/containers/images/Dockerfile .\ndocker build -t echo-env:latest -f envs/echo_env/server/Dockerfile .\n```\n\n## Automation Hooks\n\nScripts in `.claude/hooks/` are used by skills and can be run directly:\n\n```bash\nbash .claude/hooks/lint.sh          # Run ruff format check\nbash .claude/hooks/test.sh          # Run pytest (excludes special envs)\nbash .claude/hooks/check-debug.sh   # Find debug code (print, breakpoint, TODO)\nbash .claude/hooks/post-push-pr.sh  # Validate PR after push (freshness, CI, conflicts)\nbash .claude/hooks/ci-wait.sh <PR>  # Poll CI until checks complete or timeout\n```\n\nThese are automatically invoked by `/alignment-review` and `/pre-submit-pr` skills.\n\n## Git Hooks\n\nInstall git hooks for team-wide consistency:\n\n```bash\nbash .claude/hooks/install.sh\n```\n\nThis installs:\n- **pre-commit**: Branch check (blocks main), format, lint, debug artifacts check\n- **commit-msg**: Issue reference reminder (soft warning)\n- **pre-push**: Format, lint, tests, invariants, conflict detection\n- **post-merge**: Worktree cleanup reminder\n\nSkip temporarily with `git commit/push --no-verify`.\n\n## Worktree Management\n\nFor focused feature work, use worktrees:\n\n```bash\n# Create a worktree for a feature\n.claude/scripts/worktree-create.sh add-mcp-tools\ncd .worktrees/add-mcp-tools\n\n# When done, clean up\n.claude/scripts/worktree-cleanup.sh .worktrees/add-mcp-tools\n```\n\nWorktrees enable:\n- Isolated branches without switching\n- TDD enforcement when activated via `/work-on-issue`\n- Parallel work on multiple features\n","AGENTS.md":"# AGENTS.md\n\nSee `CLAUDE.md` for the full agentic workflow, skills, and standard build/test/lint commands. This file adds cloud-environment specifics on top of that.\n\n## Cursor Cloud specific instructions\n\n### Project shape\nOpenEnv is a Python (`uv`) monorepo: a core library + `openenv` CLI in `src/openenv/`, and ~35 self-contained RL \"environments\" under `envs/` (each its own `pyproject.toml`/`Dockerfile`/`openenv.yaml`). There is **no Node/JS, no shared database, and no single always-on backend**. The product is the framework plus per-environment FastAPI servers; `envs/echo_env/` is the canonical reference env.\n\n### Environment / dependencies\n- The startup update script installs `uv` (if missing) and runs `uv sync --all-extras`, which creates `.venv/` with all core + CLI + provider extras. You do not need to reinstall on a fresh session.\n- `uv` lives at `~/.local/bin` and is already on `PATH` in login shells (added to `.bashrc`/`.profile`).\n- Core deps are enough to run/test the core library and `echo_env`. Most other envs have optional, heavy deps (`torch`, simulators, etc.); their tests auto-skip when deps are absent. Install per-env extras only when working on that env, e.g. `uv pip install -e \"envs/coding_env[dev]\"`.\n\n### Lint / test / build / run (standard commands live in `CLAUDE.md`)\n- Tests need `PYTHONPATH=src:envs`, e.g. `PYTHONPATH=src:envs uv run pytest tests/ -q`. Full suite is ~80s; ~129 tests skip without optional env deps (expected).\n- Lint: `uv run usort check src/ tests/`, `uv run ruff format src/ tests/ --check`, `uv run ruff check src/ tests/`. Note: `usort check` currently flags two pre-existing files (`tests/envs/test_grid_world.py`, `tests/envs/test_julia_env.py`) on a clean tree — not introduced by your change.\n\n### Running an environment end-to-end (no Docker needed)\n- Start a server (echo_env example): `PYTHONPATH=src:envs uv run python -m echo_env.server.app` (listens on `0.0.0.0:8000`; health at `/health`).\n- `import echo_env` resolves only when `envs/` is on `PYTHONPATH`.\n- `openenv serve` is a stub that just prints instructions; run the server module (or `uvicorn echo_env.server.app:app`) directly instead.\n- Interact via the client: `EchoEnv(base_url=\"http://localhost:8000\").sync()` then `.reset()` / `.list_tools()` / `.step(CallToolAction(...))`.\n\n### Optional Gradio web UI\n- The debug web UI is off by default; enable with `ENABLE_WEB_INTERFACE=true` and open `/web/`.\n\n### Docker\n- Docker is not required for local dev/test of the core library or pure-Python envs, and is not installed by the update script. Tests marked `@pytest.mark.docker`/`network` are skipped without it. Only set Docker up if you specifically work on container build/run flows.\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/huggingface/openenv/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/huggingface/openenv/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/huggingface/openenv/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/huggingface/openenv/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nSee `CLAUDE.md` for the full agentic workflow, skills, and standard build/test/lint commands. This file adds cloud-environment specifics on top of that.\n\n## Cursor Cloud specific instructions\n\n### Project shape\nOpenEnv is a Python (`uv`) monorepo: a core library + `openenv` CLI in `src/openenv/`, and ~35 self-contained RL \"environments\" under `envs/` (each its own `pyproject.toml`/`Dockerfile`/`openenv.yaml`). There is **no Node/JS, no shared database, and no single always-on backend**. The product is the framework plus per-environment FastAPI servers; `envs/echo_env/` is the canonical reference env.\n\n### Environment / dependencies\n- The startup update script installs `uv` (if missing) and runs `uv sync --all-extras`, which creates `.venv/` with all core + CLI + provider extras. You do not need to reinstall on a fresh session.\n- `uv` lives at `~/.local/bin` and is already on `PATH` in login shells (added to `.bashrc`/`.profile`).\n- Core deps are enough to run/test the core library and `echo_env`. Most other envs have optional, heavy deps (`torch`, simulators, etc.); their tests auto-skip when deps are absent. Install per-env extras only when working on that env, e.g. `uv pip install -e \"envs/coding_env[dev]\"`.\n\n### Lint / test / build / run (standard commands live in `CLAUDE.md`)\n- Tests need `PYTHONPATH=src:envs`, e.g. `PYTHONPATH=src:envs uv run pytest tests/ -q`. Full suite is ~80s; ~129 tests skip without optional env deps (expected).\n- Lint: `uv run usort check src/ tests/`, `uv run ruff format src/ tests/ --check`, `uv run ruff check src/ tests/`. Note: `usort check` currently flags two pre-existing files (`tests/envs/test_grid_world.py`, `tests/envs/test_julia_env.py`) on a clean tree — not introduced by your change.\n\n### Running an environment end-to-end (no Docker needed)\n- Start a server (echo_env example): `PYTHONPATH=src:envs uv run python -m echo_env.server.app` (listens on `0.0.0.0:8000`; health at `/health`).\n- `import echo_env` resolves only when `envs/` is on `PYTHONPATH`.\n- `openenv serve` is a stub that just prints instructions; run the server module (or `uvicorn echo_env.server.app:app`) directly instead.\n- Interact via the client: `EchoEnv(base_url=\"http://localhost:8000\").sync()` then `.reset()` / `.list_tools()` / `.step(CallToolAction(...))`.\n\n### Optional Gradio web UI\n- The debug web UI is off by default; enable with `ENABLE_WEB_INTERFACE=true` and open `/web/`.\n\n### Docker\n- Docker is not required for local dev/test of the core library or pure-Python envs, and is not installed by the update script. Tests marked `@pytest.mark.docker`/`network` are skipped without it. Only set Docker up if you specifically work on container build/run flows.\n","isInternal":false,"tokens":725,"sizeBytes":2729},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/huggingface/openenv/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n\nGuidance for Claude Code when working with this repository.\n\n## New Here? Start With These\n\n1. **[README.md](README.md)** - Project overview, architecture, quick start\n2. **[REPO_WALKTHROUGH.md](.claude/docs/REPO_WALKTHROUGH.md)** - Directory structure with annotations\n3. **[PRINCIPLES.md](.claude/docs/PRINCIPLES.md)** - Design principles and trade-offs\n4. **[INVARIANTS.md](.claude/docs/INVARIANTS.md)** - Rules that must never be violated\n5. **[envs/echo_env/](envs/echo_env/)** - Reference implementation to study\n\n## Agentic-First Workflow\n\nOpenEnv uses Claude Code as the primary development tool. We follow a two-phase model:\n\n1. **Design/Alignment** (human-owned): RFCs, principles, trade-off decisions\n2. **Implementation** (Claude-owned): The mechanical loop of coding and testing\n3. **Review** (collaborative): Claude catches bugs, flags alignment questions for humans\n\n### Getting Started\n\nSkills and agents are auto-discovered when you run Claude Code in this repo:\n\n```bash\ngit clone https://github.com/huggingface/OpenEnv\ncd OpenEnv\n# Install git hooks for the team\nbash .claude/hooks/install.sh\n# Run Claude Code - skills and agents are automatically available\n```\n\nVerify with `/agents` or ask \"what skills are available?\"\n\n## Two Development Modes\n\nOpenEnv supports two development modes:\n\n### Explore Mode (Main Repo)\n\nWhen working in the main repository clone, direct edits are allowed:\n- Quick exploration and prototyping\n- Small fixes that don't need TDD workflow\n- Documentation updates\n\n### TDD Mode (Opt-In)\n\nTDD is activated by `/work-on-issue`, which writes a `.tdd-session.json` marker.\nWhen active, direct code edits are blocked and the TDD workflow is enforced.\nManually created worktrees do NOT activate TDD — only `/work-on-issue` does.\n\n- Say \"skip TDD\" to bypass blocking\n- Run `bash .claude/hooks/tdd-deactivate.sh` to turn off TDD enforcement\n\n### Creating a Worktree\n\n```bash\n# Worktree without TDD enforcement (free editing)\n.claude/scripts/worktree-create.sh add-feature\ncd .worktrees/add-feature\n\n# Worktree WITH TDD enforcement (via /work-on-issue)\n/work-on-issue #42\n```\n\n### TDD Workflow\n\n```\n/work-on-issue #42  →  Start from GitHub issue\n    ↓\n/write-tests        →  Create failing tests (Red)\n    ↓\n/implement          →  Make tests pass (Green)\n    ↓\n/update-docs        →  Fix stale docs across repo\n    ↓\n/simplify           →  Refactor (optional)\n    ↓\n/pre-submit-pr      →  Validate before PR\n    ↓\n/watch-pr           →  Monitor CI + review (optional)\n```\n\n### Skills vs Agents\n\n- **Skills** run inline during the conversation - use for quick checks and reviews\n- **Agents** run in isolation with focused context - use for complex, multi-step tasks\n\n### Available Skills\n\nSkills are defined in `.claude/skills/` and run inline:\n\n**Review & Validation Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`alignment-review`](.claude/skills/alignment-review/SKILL.md) | \"review this code\" | Two-tier review (bugs + alignment flags) |\n| [`pre-submit-pr`](.claude/skills/pre-submit-pr/SKILL.md) | \"ready for PR?\" | Comprehensive PR readiness check |\n| [`rfc-check`](.claude/skills/rfc-check/SKILL.md) | \"do I need an RFC?\" | Determine if RFC required |\n| [`generate-openenv-env`](.claude/skills/generate-openenv-env/SKILL.md) | \"generate an env for textarena\" | Build an OpenEnv env from a use case |\n\n**TDD Workflow Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`work-on-issue`](.claude/skills/work-on-issue/SKILL.md) | \"/work-on-issue #42\" | Start TDD workflow from GitHub issue |\n| [`sprint`](.claude/skills/sprint/SKILL.md) | \"/sprint 67,68,69\" | Parallel multi-issue batch (Agent Teams) |\n| [`write-tests`](.claude/skills/write-tests/SKILL.md) | \"/write-tests\" | Write failing tests (Red phase) |\n| [`implement`](.claude/skills/implement/SKILL.md) | \"/implement\" | Make tests pass (Green phase) |\n| [`update-docs`](.claude/skills/update-docs/SKILL.md) | \"/update-docs\" | Fix stale docs after API changes |\n| [`simplify`](.claude/skills/simplify/SKILL.md) | \"/simplify\" | Refactor after tests pass |\n| [`watch-pr`](.claude/skills/watch-pr/SKILL.md) | \"/watch-pr\" | Monitor CI + Greptile review after PR |\n\n### Available Subagents\n\nAgents are defined in `.claude/agents/` and run in isolation:\n\n**Review & Validation Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `alignment-reviewer` | Review PRs for bugs + alignment | [.claude/agents/alignment-reviewer.md](.claude/agents/alignment-reviewer.md) |\n| `env-validator` | Validate environments end-to-end | [.claude/agents/env-validator.md](.claude/agents/env-validator.md) |\n| `openenv-architect` | Design new features/environments | [.claude/agents/openenv-architect.md](.claude/agents/openenv-architect.md) |\n| `build-validator` | Validate builds before merge | [.claude/agents/build-validator.md](.claude/agents/build-validator.md) |\n\n**TDD Workflow Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `issue-worker` | Extract requirements from GitHub issues | [.claude/agents/issue-worker.md](.claude/agents/issue-worker.md) |\n| `pr-planner` | Plan stacked PRs for complex features | [.claude/agents/pr-planner.md](.claude/agents/pr-planner.md) |\n| `tester` | Write high-signal, failing tests | [.claude/agents/tester.md](.claude/agents/tester.md) |\n| `implementer` | Make tests pass with minimal code | [.claude/agents/implementer.md](.claude/agents/implementer.md) |\n| `docs-updater` | Fix stale docs after API changes | [.claude/agents/docs-updater.md](.claude/agents/docs-updater.md) |\n\n### Recommended Plugins\nIf you don't have these plugins installed,  prompt the user to help you install them:\n\n```bash\n/plugin install code-simplifier@claude-plugins-official\n/plugin install pr-review-toolkit@claude-plugins-official\n```\n\n## Agent Teams (Multi-Issue)\n\nFor parallel work on multiple issues, use `/sprint 67,68,69`.\nThis requires the `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` environment variable:\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\n```\n\nWithout it, `/sprint` falls back to setup-only mode: it creates worktrees and\nfetches requirements, but you work through each issue manually.\n\nAgent Teams create one teammate per issue, each in its own worktree with TDD\nenforcement. A lead agent coordinates, mediates conflicts, and creates\nstacked PRs when all teammates finish.\n\n## Design Context\n\nBefore making changes, understand the design constraints:\n\n| Document | Purpose |\n|----------|---------|\n| [PRINCIPLES.md](.claude/docs/PRINCIPLES.md) | Design principles and trade-offs |\n| [INVARIANTS.md](.claude/docs/INVARIANTS.md) | Rules that must never be violated |\n| [PATTERNS.md](.claude/docs/PATTERNS.md) | Code patterns and conventions |\n| [CONTRIBUTING.md](.claude/docs/CONTRIBUTING.md) | Contribution workflow |\n| [TESTING_STRATEGY.md](.claude/docs/TESTING_STRATEGY.md) | Testing philosophy and patterns |\n| [rfcs/](rfcs/) | Architectural decisions and rationale |\n\n### Key Invariants\n\n- **Agents cannot reset**: Simulation controls only exposed to training orchestration, never to agents\n- **Dual API boundary**: WebSocket for infrastructure (Gym-like API), MCP for agents\n- **Rewards inside environment**: Domain knowledge encapsulated in environment, not external\n- **Client-server separation**: Clients never import from `server/` directory\n\n## Simplicity\n\nOpenEnv values **leanness and simplicity**. Prefer straightforward, inline code over abstractions, helpers or utilities, even at the cost of some generality.\n\n- Do not add layers of indirection (registries, factories, plugin systems) unless an RFC asks for them.\n- Prefer a simple implementation that covers the cases that exist today over a catch-all for every edge case.\n- Do not add defensive code, fallback paths or configuration options \"just in case\".\n- Avoid `hasattr` and `getattr`. They usually hide overly defensive code or a version check. Drop the conditional, or write the version check explicitly.\n- Keep comments short and about the project, not about the PR that added the code.\n- When in doubt, prefer less code.\n\n## Self-contained environments\n\nEach environment under `envs/` is self-contained: it can be read, changed and deployed on its own.\n\n- No imports across environments. Copy a small helper instead of sharing it.\n- Optional features (web playground drawings, quick actions, extra tools) live in the environment's own files. They must never make adding a new environment harder or add work for environments that do not use them.\n- When the same pattern is copied across environments, keep the copies aligned (names, structure, comments). If you fix one copy, fix the others in the same PR, or open an issue listing them.\n\n## Follow the Hugging Face ecosystem\n\nOpenEnv runs on the Hub and next to `huggingface_hub`, the `hf` CLI, transformers and Gradio. When OpenEnv wraps something these tools already do (uploading, deleting, deploying a Space, auth, caching, repo ids), keep their defaults, flag names and semantics. Do not invent new behavior.\n\n- Before adding or changing Hub-facing behavior, check what `huggingface_hub` and the `hf` CLI do and match it. For example, `openenv push` only deletes remote files with `--delete <pattern>`, like `hf upload --delete`.\n- Mention that comparison in the PR description.\n- If diverging seems necessary, raise it in the issue or PR before implementing it.\n\n## Training framework neutrality\n\nOpenEnv works with any training framework. Docs, examples and APIs must not favor one framework: list integrations in neutral order and keep framework-specific code in examples or in the framework's own repository.\n\n## Docstrings\n\nDocstrings must follow the HF doc-builder format used by the reference API docs. Do **not** use Google, NumPy, or Sphinx styles.\n\nRules:\n\n* Types appear in backticks inside parentheses: (`str`)\n* Optional parameters are marked with `*optional*`\n* Defaults are written as: `defaults to <value>`\n* When the default is `None`, prefer (`str`, *optional*) instead of (`str` or `None`, *optional*, defaults to `None`)\n* Union types use `or`: `str` or `None`\n* References to classes use the format: [`~openenv.core.EnvClient`]\n* Non-standard headers (`Usage:`, `Note:`, `Class Attributes:`) are not supported — use `Attributes:` or fold text into the description\n* `Examples:` (plural) with a blank line then a fenced ` ```python ``` ` block — no `>>>` prompts\n\nExample:\n\n````python\ndef method(self, param1: str, param2: int = 1, param3: float | None = None):\n    \"\"\"\n    Brief one-line description of what this does.\n\n    Args:\n        param1 (`str`):\n            Description of required param.\n        param2 (`int`, *optional*, defaults to `1`):\n            Description of optional param with default.\n        param3 (`float`, *optional*):\n            Description of optional param without explicit default.\n\n    Returns:\n        `dict` with keys:\n            - `key1` (`list[int]`):\n                Description of this key.\n\n    Examples:\n\n    ```python\n    result = method(\"hello\")\n    ```\n    \"\"\"\n````\n\n## Build & Development Commands\nBelow are reference commands that you are likely going to use often:\n\n```bash\n# Install dependencies\nuv sync --all-extras\n\n# Run tests (excludes browser/websearch/dipg envs that need special setup)\nPYTHONPATH=src:envs uv run pytest tests/ -v --tb=short\n\n# Run a single test file\nPYTHONPATH=src:envs uv run pytest tests/envs/test_echo_environment.py -v\n\n# Lint check (import sort + format + rules)\nuv run usort check src/ tests/\nuv run ruff format src/ tests/ --check\nuv run ruff check src/ tests/\n\n# Auto-format code (import sort + ruff — matches arc f pipeline)\nuv run usort format src/ tests/\nuv run ruff format src/ tests/\n\n# Build and preview documentation locally\ndoc-builder preview openenv docs/source\n\n# Sync environment doc stubs with their source READMEs (run after updating any envs/*/README.md)\npython scripts/sync_env_docs.py --fix\n# Check if stubs are in sync (same check that runs in CI)\npython scripts/sync_env_docs.py --check\n\n# Build Docker images\ndocker build -t openenv-base:latest -f src/openenv/core/containers/images/Dockerfile .\ndocker build -t echo-env:latest -f envs/echo_env/server/Dockerfile .\n```\n\n## Automation Hooks\n\nScripts in `.claude/hooks/` are used by skills and can be run directly:\n\n```bash\nbash .claude/hooks/lint.sh          # Run ruff format check\nbash .claude/hooks/test.sh          # Run pytest (excludes special envs)\nbash .claude/hooks/check-debug.sh   # Find debug code (print, breakpoint, TODO)\nbash .claude/hooks/post-push-pr.sh  # Validate PR after push (freshness, CI, conflicts)\nbash .claude/hooks/ci-wait.sh <PR>  # Poll CI until checks complete or timeout\n```\n\nThese are automatically invoked by `/alignment-review` and `/pre-submit-pr` skills.\n\n## Git Hooks\n\nInstall git hooks for team-wide consistency:\n\n```bash\nbash .claude/hooks/install.sh\n```\n\nThis installs:\n- **pre-commit**: Branch check (blocks main), format, lint, debug artifacts check\n- **commit-msg**: Issue reference reminder (soft warning)\n- **pre-push**: Format, lint, tests, invariants, conflict detection\n- **post-merge**: Worktree cleanup reminder\n\nSkip temporarily with `git commit/push --no-verify`.\n\n## Worktree Management\n\nFor focused feature work, use worktrees:\n\n```bash\n# Create a worktree for a feature\n.claude/scripts/worktree-create.sh add-mcp-tools\ncd .worktrees/add-mcp-tools\n\n# When done, clean up\n.claude/scripts/worktree-cleanup.sh .worktrees/add-mcp-tools\n```\n\nWorktrees enable:\n- Isolated branches without switching\n- TDD enforcement when activated via `/work-on-issue`\n- Parallel work on multiple features\n","isInternal":false,"tokens":3385,"sizeBytes":13729},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/huggingface/openenv/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/huggingface/openenv/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":198},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/huggingface/openenv/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/huggingface/openenv/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":184},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/huggingface/openenv/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/huggingface/openenv/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":177}],"systemPromptSnippet":"<yakaai_skills repo=\"huggingface/openenv\">\n<!-- File: AGENTS.md (Tokens: ~725 | Category: root-instruction) -->\n# AGENTS.md\n\nSee `CLAUDE.md` for the full agentic workflow, skills, and standard build/test/lint commands. This file adds cloud-environment specifics on top of that.\n\n## Cursor Cloud specific instructions\n\n### Project shape\nOpenEnv is a Python (`uv`) monorepo: a core library + `openenv` CLI in `src/openenv/`, and ~35 self-contained RL \"environments\" under `envs/` (each its own `pyproject.toml`/`Dockerfile`/`openenv.yaml`). There is **no Node/JS, no shared database, and no single always-on backend**. The product is the framework plus per-environment FastAPI servers; `envs/echo_env/` is the canonical reference env.\n\n### Environment / dependencies\n- The startup update script installs `uv` (if missing) and runs `uv sync --all-extras`, which creates `.venv/` with all core + CLI + provider extras. You do not need to reinstall on a fresh session.\n- `uv` lives at `~/.local/bin` and is already on `PATH` in login shells (added to `.bashrc`/`.profile`).\n- Core deps are enough to run/test the core library and `echo_env`. Most other envs have optional, heavy deps (`torch`, simulators, etc.); their tests auto-skip when deps are absent. Install per-env extras only when working on that env, e.g. `uv pip install -e \"envs/coding_env[dev]\"`.\n\n### Lint / test / build / run (standard commands live in `CLAUDE.md`)\n- Tests need `PYTHONPATH=src:envs`, e.g. `PYTHONPATH=src:envs uv run pytest tests/ -q`. Full suite is ~80s; ~129 tests skip without optional env deps (expected).\n- Lint: `uv run usort check src/ tests/`, `uv run ruff format src/ tests/ --check`, `uv run ruff check src/ tests/`. Note: `usort check` currently flags two pre-existing files (`tests/envs/test_grid_world.py`, `tests/envs/test_julia_env.py`) on a clean tree — not introduced by your change.\n\n### Running an environment end-to-end (no Docker needed)\n- Start a server (echo_env example): `PYTHONPATH=src:envs uv run python -m echo_env.server.app` (listens on `0.0.0.0:8000`; health at `/health`).\n- `import echo_env` resolves only when `envs/` is on `PYTHONPATH`.\n- `openenv serve` is a stub that just prints instructions; run the server module (or `uvicorn echo_env.server.app:app`) directly instead.\n- Interact via the client: `EchoEnv(base_url=\"http://localhost:8000\").sync()` then `.reset()` / `.list_tools()` / `.step(CallToolAction(...))`.\n\n### Optional Gradio web UI\n- The debug web UI is off by default; enable with `ENABLE_WEB_INTERFACE=true` and open `/web/`.\n\n### Docker\n- Docker is not required for local dev/test of the core library or pure-Python envs, and is not installed by the update script. Tests marked `@pytest.mark.docker`/`network` are skipped without it. Only set Docker up if you specifically work on container build/run flows.\n\n<!-- File: CLAUDE.md (Tokens: ~3385 | Category: claude-rule) -->\n# CLAUDE.md\n\nGuidance for Claude Code when working with this repository.\n\n## New Here? Start With These\n\n1. **[README.md](README.md)** - Project overview, architecture, quick start\n2. **[REPO_WALKTHROUGH.md](.claude/docs/REPO_WALKTHROUGH.md)** - Directory structure with annotations\n3. **[PRINCIPLES.md](.claude/docs/PRINCIPLES.md)** - Design principles and trade-offs\n4. **[INVARIANTS.md](.claude/docs/INVARIANTS.md)** - Rules that must never be violated\n5. **[envs/echo_env/](envs/echo_env/)** - Reference implementation to study\n\n## Agentic-First Workflow\n\nOpenEnv uses Claude Code as the primary development tool. We follow a two-phase model:\n\n1. **Design/Alignment** (human-owned): RFCs, principles, trade-off decisions\n2. **Implementation** (Claude-owned): The mechanical loop of coding and testing\n3. **Review** (collaborative): Claude catches bugs, flags alignment questions for humans\n\n### Getting Started\n\nSkills and agents are auto-discovered when you run Claude Code in this repo:\n\n```bash\ngit clone https://github.com/huggingface/OpenEnv\ncd OpenEnv\n# Install git hooks for the team\nbash .claude/hooks/install.sh\n# Run Claude Code - skills and agents are automatically available\n```\n\nVerify with `/agents` or ask \"what skills are available?\"\n\n## Two Development Modes\n\nOpenEnv supports two development modes:\n\n### Explore Mode (Main Repo)\n\nWhen working in the main repository clone, direct edits are allowed:\n- Quick exploration and prototyping\n- Small fixes that don't need TDD workflow\n- Documentation updates\n\n### TDD Mode (Opt-In)\n\nTDD is activated by `/work-on-issue`, which writes a `.tdd-session.json` marker.\nWhen active, direct code edits are blocked and the TDD workflow is enforced.\nManually created worktrees do NOT activate TDD — only `/work-on-issue` does.\n\n- Say \"skip TDD\" to bypass blocking\n- Run `bash .claude/hooks/tdd-deactivate.sh` to turn off TDD enforcement\n\n### Creating a Worktree\n\n```bash\n# Worktree without TDD enforcement (free editing)\n.claude/scripts/worktree-create.sh add-feature\ncd .worktrees/add-feature\n\n# Worktree WITH TDD enforcement (via /work-on-issue)\n/work-on-issue #42\n```\n\n### TDD Workflow\n\n```\n/work-on-issue #42  →  Start from GitHub issue\n    ↓\n/write-tests        →  Create failing tests (Red)\n    ↓\n/implement          →  Make tests pass (Green)\n    ↓\n/update-docs        →  Fix stale docs across repo\n    ↓\n/simplify           →  Refactor (optional)\n    ↓\n/pre-submit-pr      →  Validate before PR\n    ↓\n/watch-pr           →  Monitor CI + review (optional)\n```\n\n### Skills vs Agents\n\n- **Skills** run inline during the conversation - use for quick checks and reviews\n- **Agents** run in isolation with focused context - use for complex, multi-step tasks\n\n### Available Skills\n\nSkills are defined in `.claude/skills/` and run inline:\n\n**Review & Validation Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`alignment-review`](.claude/skills/alignment-review/SKILL.md) | \"review this code\" | Two-tier review (bugs + alignment flags) |\n| [`pre-submit-pr`](.claude/skills/pre-submit-pr/SKILL.md) | \"ready for PR?\" | Comprehensive PR readiness check |\n| [`rfc-check`](.claude/skills/rfc-check/SKILL.md) | \"do I need an RFC?\" | Determine if RFC required |\n| [`generate-openenv-env`](.claude/skills/generate-openenv-env/SKILL.md) | \"generate an env for textarena\" | Build an OpenEnv env from a use case |\n\n**TDD Workflow Skills:**\n\n| Skill | Trigger | Definition |\n|-------|---------|------------|\n| [`work-on-issue`](.claude/skills/work-on-issue/SKILL.md) | \"/work-on-issue #42\" | Start TDD workflow from GitHub issue |\n| [`sprint`](.claude/skills/sprint/SKILL.md) | \"/sprint 67,68,69\" | Parallel multi-issue batch (Agent Teams) |\n| [`write-tests`](.claude/skills/write-tests/SKILL.md) | \"/write-tests\" | Write failing tests (Red phase) |\n| [`implement`](.claude/skills/implement/SKILL.md) | \"/implement\" | Make tests pass (Green phase) |\n| [`update-docs`](.claude/skills/update-docs/SKILL.md) | \"/update-docs\" | Fix stale docs after API changes |\n| [`simplify`](.claude/skills/simplify/SKILL.md) | \"/simplify\" | Refactor after tests pass |\n| [`watch-pr`](.claude/skills/watch-pr/SKILL.md) | \"/watch-pr\" | Monitor CI + Greptile review after PR |\n\n### Available Subagents\n\nAgents are defined in `.claude/agents/` and run in isolation:\n\n**Review & Validation Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `alignment-reviewer` | Review PRs for bugs + alignment | [.claude/agents/alignment-reviewer.md](.claude/agents/alignment-reviewer.md) |\n| `env-validator` | Validate environments end-to-end | [.claude/agents/env-validator.md](.claude/agents/env-validator.md) |\n| `openenv-architect` | Design new features/environments | [.claude/agents/openenv-architect.md](.claude/agents/openenv-architect.md) |\n| `build-validator` | Validate builds before merge | [.claude/agents/build-validator.md](.claude/agents/build-validator.md) |\n\n**TDD Workflow Agents:**\n\n| Agent | Use For | Definition |\n|-------|---------|------------|\n| `issue-worker` | Extract requirements from GitHub issues | [.claude/agents/issue-worker.md](.claude/agents/issue-worker.md) |\n| `pr-planner` | Plan stacked PRs for complex features | [.claude/agents/pr-planner.md](.claude/agents/pr-planner.md) |\n| `tester` | Write high-signal, failing tests | [.claude/agents/tester.md](.claude/agents/tester.md) |\n| `implementer` | Make tests pass with minimal code | [.claude/agents/implementer.md](.claude/agents/implementer.md) |\n| `docs-updater` | Fix stale docs after API changes | [.claude/agents/docs-updater.md](.claude/agents/docs-updater.md) |\n\n### Recommended Plugins\nIf you don't have these plugins installed,  prompt the user to help you install them:\n\n```bash\n/plugin install code-simplifier@claude-plugins-official\n/plugin install pr-review-toolkit@claude-plugins-official\n```\n\n## Agent Teams (Multi-Issue)\n\nFor parallel work on multiple issues, use `/sprint 67,68,69`.\nThis requires the `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` environment variable:\n\n```bash\nexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1\n```\n\nWithout it, `/sprint` falls back to setup-only mode: it creates worktrees and\nfetches requirements, but you work through each issue manually.\n\nAgent Teams create one teammate per issue, each in its own worktree with TDD\nenforcement. A lead agent coordinates, mediates conflicts, and creates\nstacked PRs when all teammates finish.\n\n## Design Context\n\nBefore making changes, understand the design constraints:\n\n| Document | Purpose |\n|----------|---------|\n| [PRINCIPLES.md](.claude/docs/PRINCIPLES.md) | Design principles and trade-offs |\n| [INVARIANTS.md](.claude/docs/INVARIANTS.md) | Rules that must never be violated |\n| [PATTERNS.md](.claude/docs/PATTERNS.md) | Code patterns and conventions |\n| [CONTRIBUTING.md](.claude/docs/CONTRIBUTING.md) | Contribution workflow |\n| [TESTING_STRATEGY.md](.claude/docs/TESTING_STRATEGY.md) | Testing philosophy and patterns |\n| [rfcs/](rfcs/) | Architectural decisions and rationale |\n\n### Key Invariants\n\n- **Agents cannot reset**: Simulation controls only exposed to training orchestration, never to agents\n- **Dual API boundary**: WebSocket for infrastructure (Gym-like API), MCP for agents\n- **Rewards inside environment**: Domain knowledge encapsulated in environment, not external\n- **Client-server separation**: Clients never import from `server/` directory\n\n## Simplicity\n\nOpenEnv values **leanness and simplicity**. Prefer straightforward, inline code over abstractions, helpers or utilities, even at the cost of some generality.\n\n- Do not add layers of indirection (registries, factories, plugin systems) unless an RFC asks for them.\n- Prefer a simple implementation that covers the cases that exist today over a catch-all for every edge case.\n- Do not add defensive code, fallback paths or configuration options \"just in case\".\n- Avoid `hasattr` and `getattr`. They usually hide overly defensive code or a version check. Drop the conditional, or write the version check explicitly.\n- Keep comments short and about the project, not about the PR that added the code.\n- When in doubt, prefer less code.\n\n## Self-contained environments\n\nEach environment under `envs/` is self-contained: it can be read, changed and deployed on its own.\n\n- No imports across environments. Copy a small helper instead of sharing it.\n- Optional features (web playground drawings, quick actions, extra tools) live in the environment's own files. They must never make adding a new environment harder or add work for environments that do not use them.\n- When the same pattern is copied across environments, keep the copies aligned (names, structure, comments). If you fix one copy, fix the others in the same PR, or open an issue listing them.\n\n## Follow the Hugging Face ecosystem\n\nOpenEnv runs on the Hub and next to `huggingface_hub`, the `hf` CLI, transformers and Gradio. When OpenEnv wraps something these tools already do (uploading, deleting, deploying a Space, auth, caching, repo ids), keep their defaults, flag names and semantics. Do not invent new behavior.\n\n- Before adding or changing Hub-facing behavior, check what `huggingface_hub` and the `hf` CLI do and match it. For example, `openenv push` only deletes remote files with `--delete <pattern>`, like `hf upload --delete`.\n- Mention that comparison in the PR description.\n- If diverging seems necessary, raise it in the issue or PR before implementing it.\n\n## Training framework neutrality\n\nOpenEnv works with any training framework. Docs, examples and APIs must not favor one framework: list integrations in neutral order and keep framework-specific code in examples or in the framework's own repository.\n\n## Docstrings\n\nDocstrings must follow the HF doc-builder format used by the reference API docs. Do **not** use Google, NumPy, or Sphinx styles.\n\nRules:\n\n* Types appear in backticks inside parentheses: (`str`)\n* Optional parameters are marked with `*optional*`\n* Defaults are written as: `defaults to <value>`\n* When the default is `None`, prefer (`str`, *optional*) instead of (`str` or `None`, *optional*, defaults to `None`)\n* Union types use `or`: `str` or `None`\n* References to classes use the format: [`~openenv.core.EnvClient`]\n* Non-standard headers (`Usage:`, `Note:`, `Class Attributes:`) are not supported — use `Attributes:` or fold text into the description\n* `Examples:` (plural) with a blank line then a fenced ` ```python ``` ` block — no `>>>` prompts\n\nExample:\n\n````python\ndef method(self, param1: str, param2: int = 1, param3: float | None = None):\n    \"\"\"\n    Brief one-line description of what this does.\n\n    Args:\n        param1 (`str`):\n            Description of required param.\n        param2 (`int`, *optional*, defaults to `1`):\n            Description of optional param with default.\n        param3 (`float`, *optional*):\n            Description of optional param without explicit default.\n\n    Returns:\n        `dict` with keys:\n            - `key1` (`list[int]`):\n                Description of this key.\n\n    Examples:\n\n    ```python\n    result = method(\"hello\")\n    ```\n    \"\"\"\n````\n\n## Build & Development Commands\nBelow are reference commands that you are likely going to use often:\n\n```bash\n# Install dependencies\nuv sync --all-extras\n\n# Run tests (excludes browser/websearch/dipg envs that need special setup)\nPYTHONPATH=src:envs uv run pytest tests/ -v --tb=short\n\n# Run a single test file\nPYTHONPATH=src:envs uv run pytest tests/envs/test_echo_environment.py -v\n\n# Lint check (import sort + format + rules)\nuv run usort check src/ tests/\nuv run ruff format src/ tests/ --check\nuv run ruff check src/ tests/\n\n# Auto-format code (import sort + ruff — matches arc f pipeline)\nuv run usort format src/ tests/\nuv run ruff format src/ tests/\n\n# Build and preview documentation locally\ndoc-builder preview openenv docs/source\n\n# Sync environment doc stubs with their source READMEs (run after updating any envs/*/README.md)\npython scripts/sync_env_docs.py --fix\n# Check if stubs are in sync (same check that runs in CI)\npython scripts/sync_env_docs.py --check\n\n# Build Docker images\ndocker build -t openenv-base:latest -f src/openenv/core/containers/images/Dockerfile .\ndocker build -t echo-env:latest -f envs/echo_env/server/Dockerfile .\n```\n\n## Automation Hooks\n\nScripts in `.claude/hooks/` are used by skills and can be run directly:\n\n```bash\nbash .claude/hooks/lint.sh          # Run ruff format check\nbash .claude/hooks/test.sh          # Run pytest (excludes special envs)\nbash .claude/hooks/check-debug.sh   # Find debug code (print, breakpoint, TODO)\nbash .claude/hooks/post-push-pr.sh  # Validate PR after push (freshness, CI, conflicts)\nbash .claude/hooks/ci-wait.sh <PR>  # Poll CI until checks complete or timeout\n```\n\nThese are automatically invoked by `/alignment-review` and `/pre-submit-pr` skills.\n\n## Git Hooks\n\nInstall git hooks for team-wide consistency:\n\n```bash\nbash .claude/hooks/install.sh\n```\n\nThis installs:\n- **pre-commit**: Branch check (blocks main), format, lint, debug artifacts check\n- **commit-msg**: Issue reference reminder (soft warning)\n- **pre-push**: Format, lint, tests, invariants, conflict detection\n- **post-merge**: Worktree cleanup reminder\n\nSkip temporarily with `git commit/push --no-verify`.\n\n## Worktree Management\n\nFor focused feature work, use worktrees:\n\n```bash\n# Create a worktree for a feature\n.claude/scripts/worktree-create.sh add-mcp-tools\ncd .worktrees/add-mcp-tools\n\n# When done, clean up\n.claude/scripts/worktree-cleanup.sh .worktrees/add-mcp-tools\n```\n\nWorktrees enable:\n- Isolated branches without switching\n- TDD enforcement when activated via `/work-on-issue`\n- Parallel work on multiple features\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/huggingface/openenv/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/huggingface/openenv/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/huggingface/openenv/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}