{"owner":"NVIDIA","repo":"NemoClaw","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":5732,"categories":["root-instruction","claude-rule","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"NemoClaw":{"command":"npx","args":["-y","@modelcontextprotocol/server-NemoClaw"]}}},"found":["AGENTS.md","CLAUDE.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n","CLAUDE.md":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\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/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n","CLAUDE.md":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\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/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/NVIDIA/NemoClaw/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n","isInternal":false,"tokens":2416,"sizeBytes":11166},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/NVIDIA/NemoClaw/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n","isInternal":false,"tokens":2416,"sizeBytes":11166},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":194},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":180},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/NVIDIA/NemoClaw/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/NVIDIA/NemoClaw/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":173}],"systemPromptSnippet":"\n\n\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n\n\n\n\n\n# Agent Instructions\n\n## Project Overview\n\nNVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as [OpenClaw](https://openclaw.ai) and [Hermes](https://get-hermes.ai/) inside [NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.\n\nStatus: Active development. Interfaces may change without notice.\n\n## Product Scope Gate\n\nTechnical correctness, passing tests, and green CI do not establish product approval.\nBefore implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined.\nThe recorded decision must be `Accept` before implementation begins. The record must state the reason, placement, accountable maintainer, and validation plan. `Request changes`, `Defer`, and `Decline` do not authorize implementation. Small documentation corrections and low-risk fixes do not require this decision.\nIf the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.\nStop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx).\n\n## Agent Skills\n\nThis repo ships agent skills under `.agents/skills/`.\nUse `nemoclaw-user-guide` for end-user documentation routing, `nemoclaw-contributor-*` for contributor workflows, and `nemoclaw-maintainer-*` for maintainer workflows.\nThe contributor lifecycle has one owner for each stage: `nemoclaw-contributor-onboard` for checkout setup, `nemoclaw-contributor-plan-issue` for planning, `nemoclaw-contributor-implement-issue` for implementation and its tests, and `nemoclaw-contributor-create-pr` for publication and review follow-up.\nComponent-specific guidance belongs in the `AGENTS.md` file of the package it describes, not in a skill.\nUse `nemoclaw-skills-guide` only when choosing a skill or browsing the catalog. Go directly to a known skill.\nLoad supporting references only when their described condition applies; do not preload a lifecycle stack.\nWhen editing a skill, keep its description short and specific to the task that needs it. Put conditional\nprocedures in references and keep completion criteria in the entrypoint. Preserve concrete security,\npublication, and release constraints; avoid generic checklists and fixed report formats without a consumer.\nSkills that write or review explanatory text must follow the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract.\nKeep repository skill workflows agent-harness agnostic. State required capabilities, actions, and observable results instead of requiring harness-specific tool names. A skill may name a client or command when that client or command is the user-visible subject. Harness-specific automation may assist with a workflow, but it does not define or replace the skill's requirements.\n\n## Development guidance\n\nFor source, test, build-tooling, or hook changes, read the applicable sections of the\n[development reference](.agents/references/development.md). It owns the architecture map, language\nconventions, test lanes, and hook behavior. For messaging changes, also use\n[`src/lib/messaging/AGENTS.md`](src/lib/messaging/AGENTS.md).\n\n## Quick Reference\n\n| Task | Command or guidance |\n|---|---|\n| Set up or diagnose a contributor checkout | `npm run dev:setup` / `npm run dev:doctor` |\n| Validate changed behavior | `npm run test:changed`; placement and evidence in `test/README.md` |\n| Validate a committed PR diff | `npm run validate:pr`; follow `CONTRIBUTING.md` for when it is needed |\n| Build documentation | `npm run docs`; use [documentation validation](docs/CONTRIBUTING.md#validate-the-change) for additional checks that apply to the change |\n| Find component builds, test lanes, and hook commands | [Development reference](.agents/references/development.md#quick-reference) and `package.json` |\n\n## Working with This Repo\n\n### Scope and completion\n\nFollow the user's requested outcome and existing authorization. Repository skills supply task\nknowledge and operational constraints; they must not add unrequested work or require the user to\nrepeat an authorization. A specific confirmation bound to an irreversible action still applies.\nCarry authorization through in-scope repairs, qualification receipt updates, and the shared bounded\nretry policy. Distinguish task authorization from test evidence and independent merge approval.\nA new commit invalidates affected evidence; it does not alone require renewed task authorization.\nHonor an explicit one-run or one-commit limit, expiry, or revocation. Do not invent such limits when\nasking for permission. Ask again when scope, cost, credential exposure, or resource ownership changes.\nWhen an instruction requires a pause, name the file, quote the requirement, and explain the missing\ndecision. Continue independent authorized work while that decision is pending.\n\nUse `CONTRIBUTING.md` for contribution requirements and the nearest guidance for changed paths.\nUse `nemoclaw-contributor-onboard` when setup or repair is needed. Read the smallest sufficient source\nset. Ask only when a missing choice changes the required outcome or constraints.\n\nComplete implementation, inspection, and applicable validation for the requested change. Fix failures\ncaused by that change and rerun affected checks without asking at each step. Continue into PR\npublication and review follow-up when requested. A first patch or lifecycle handoff is not completion.\nKeep local verification within the test's documented effects; live E2E and external writes retain\ntheir own authorization boundaries. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval.\n\n### E2E Triage\n\nFor every E2E triage, diagnosis, debugging, or repair task, first use\n[`nemoclaw-maintainer-audit-e2e-assertions`](.agents/skills/nemoclaw-maintainer-audit-e2e-assertions/SKILL.md).\nThis also applies when E2E failures emerge during broader PR or CI work. Complete its itemized\nsource audit before a repair push or expensive rerun. Status-only and dispatch-only requests\ncontinue through the existing E2E execution skill without an assertion audit.\n\n### E2E Selection and Authoring\n\nWhen adding or extending E2E tests, read the [E2E authoring reference](.agents/references/e2e-authoring.md).\nIt owns behavior selection, coverage granularity, and bounded retry requirements. Use\n`nemoclaw-maintainer-e2e` for execution or evidence inspection.\n\n### Plain Language\n\nFollow [WRITING.md](WRITING.md) for all agent-written text.\n\n### Direct Design\n\nAdd mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.\n\n### Git and GitHub Access Failures\n\nFollow `.agents/skills/_shared/git-github-hard-stop.md`, which owns access failures and mechanical Git recovery.\n\n### Pull Request Follow-Up\n\nFollow `.agents/skills/_shared/pr-follow-up.md`.\n\nAn authorized PR workflow includes synchronizing the working branch with its target branch under the\nshared contract. Use a merge or GitHub's Update branch operation. Resolve mechanical, in-scope\nconflicts without separate approval. These actions are not destructive Git operations.\n\n### Common Patterns\n\n**Adding a CLI command:**\n\n- Entry point: `bin/nemoclaw.js` (launches the compiled CLI in `dist/`)\n- Main CLI implementation lives in `src/lib/` and compiles to `dist/lib/`\n- Add tests in `test/`\n\n**Adding a plugin feature:**\n\n- Source: `nemoclaw/src/`\n- Co-locate tests as `*.test.ts`\n- Build with `cd nemoclaw && npm run build`\n\n**Adding a network policy preset:**\n\n- Add YAML to `nemoclaw-blueprint/policies/presets/`\n- Follow existing preset structure (see `github.yaml`, `brave.yaml`)\n\n**Adding model-specific sandbox compatibility:**\n\n- Add a declarative manifest under `nemoclaw-blueprint/model-specific-setup//`\n- Use one `agent` per manifest (`openclaw`, `hermes`, etc.); do not make shared multi-agent manifests\n- Put OpenClaw executable wrappers under `nemoclaw-blueprint/openclaw-plugins/`\n- Put Hermes executable wrappers under `agents/hermes/`\n- Keep `agents/hermes/generate-config.ts` as a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization under `agents/hermes/config/`\n- Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test\n\n### Blueprint Image Pins\n\nWhen the managed sandbox image changes, update `digest` and `components.sandbox.image` in\n`nemoclaw-blueprint/blueprint.yaml` with the same immutable SHA-256 digest. Release tooling must\nupdate both fields together. `test/onboarding/validate-blueprint.test.ts` rejects mutable tags and\nmismatched digests.\n\n### Gotchas\n\n- `npm install` at root triggers `prek install` which sets up git hooks. If hooks fail, check that `core.hooksPath` is unset: `git config --unset core.hooksPath`\n- The `nemoclaw/` subdirectory has its own `package.json` and `node_modules`.\n It is a separate npm project that shares the root Oxlint and Oxfmt configuration files.\n- Coverage thresholds are ratcheted in `ci/coverage-threshold-*.json` — new code should not decrease CLI or plugin coverage\n- The `.claude/skills` symlink points to `.agents/skills` — both paths resolve to the same content\n\n## Documentation\n\n- Treat `docs/` as the source of truth for public-facing documentation. Follow the [Documentation Agent Guide](docs/AGENTS.md) for the documentation-agent workflow, including DORI routing.\n- Ordinary code PRs may defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**` changes to `Docs / Author Post-Merge Catch-Up`.\n Keep all other owning repository guidance in the same PR, including active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.\n- Direct documentation-only changes follow `docs/AGENTS.md`, the shared [Documentation Writing and Review](.agents/skills/_shared/documentation-writing-review.md) contract, documented validation, and independent review.\n\n## PR Requirements\n\nFollow `nemoclaw-contributor-create-pr` for publication.\n\n- PRs that change `scripts/prepare-dgx-station-host.sh` must include reviewable DGX Station test evidence identifying the tested commit, Station profile or scenario, result, and a supporting link. Any maintainer may review the evidence; without acceptable evidence, the PR is not ready to approve or merge. Treat the evidence as human-reviewed, not authenticated hardware provenance. Exceptional bypasses use existing repository governance and must document the reason on the PR.\n- No secrets, API keys, or credentials committed\n- Check `.github/pr-limits.json` for the contributor's open PR limit.\n\n\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/NVIDIA/NemoClaw/HEAD/.claude-plugin/marketplace.json)\n\n\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/NVIDIA/NemoClaw/HEAD/.claude-plugin/plugin.json)\n\n\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/NVIDIA/NemoClaw/HEAD/.cursor/mcp.json)\n"}