NVIDIA NemoClaw is an open-source reference stack for running always-on AI agents such as OpenClaw and Hermes inside NVIDIA OpenShell sandboxes more safely. It provides CLI tooling, a blueprint for sandbox orchestration, and security hardening.
Status: Active development. Interfaces may change without notice.
Technical correctness, passing tests, and green CI do not establish product approval.
Before 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.
The 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.
If the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior.
Stop and request maintainer direction, or route an independent solution through Community Solutions.
This repo ships agent skills under .agents/skills/.
Use nemoclaw-user-guide for end-user documentation routing, nemoclaw-contributor-* for contributor workflows, and nemoclaw-maintainer-* for maintainer workflows.
The 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.
Component-specific guidance belongs in the AGENTS.md file of the package it describes, not in a skill.
Use nemoclaw-skills-guide only when choosing a skill or browsing the catalog. Go directly to a known skill.
Load supporting references only when their described condition applies; do not preload a lifecycle stack.
When editing a skill, keep its description short and specific to the task that needs it. Put conditional
procedures in references and keep completion criteria in the entrypoint. Preserve concrete security,
publication, and release constraints; avoid generic checklists and fixed report formats without a consumer.
Skills that write or review explanatory text must follow the shared Documentation Writing and Review contract.
Keep 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.
For source, test, build-tooling, or hook changes, read the applicable sections of the
development reference. It owns the architecture map, language
conventions, test lanes, and hook behavior. For messaging changes, also use
src/lib/messaging/AGENTS.md.
| Task | Command or guidance |
|---|---|
| Set up or diagnose a contributor checkout | npm run dev:setup / npm run dev:doctor |
| Validate changed behavior | npm run test:changed; placement and evidence in test/README.md |
| Validate a committed PR diff | npm run validate:pr; follow CONTRIBUTING.md for when it is needed |
| Build documentation | npm run docs; use documentation validation for additional checks that apply to the change |
| Find component builds, test lanes, and hook commands | Development reference and package.json |
Follow the user's requested outcome and existing authorization. Repository skills supply task knowledge and operational constraints; they must not add unrequested work or require the user to repeat an authorization. A specific confirmation bound to an irreversible action still applies. When an instruction requires a pause, name the file, quote the requirement, and explain the missing decision. Continue independent authorized work while that decision is pending.
Use CONTRIBUTING.md for contribution requirements and the nearest guidance for changed paths.
Use nemoclaw-contributor-onboard when setup or repair is needed. Read the smallest sufficient source
set. Ask only when a missing choice changes the required outcome or constraints.
Complete implementation, inspection, and applicable validation for the requested change. Fix failures
caused by that change and rerun affected checks without asking at each step. Continue into PR
publication and review follow-up when requested. A first patch or lifecycle handoff is not completion.
Keep local verification within the test's documented effects; live E2E and external writes retain
their own authorization boundaries. Use ./scripts/dev-setup.sh --expose-cli only with explicit approval.
When adding or extending E2E tests, read the E2E authoring reference.
It owns behavior selection, coverage granularity, and bounded retry requirements. Use
nemoclaw-maintainer-e2e for execution or evidence inspection.
Follow WRITING.md for all agent-written text.
Add mechanisms only for a current requirement and consumer, with validation appropriate to the changed behavior. Complete the smallest requested outcome and report its evidence.
Follow .agents/skills/_shared/git-github-hard-stop.md, which owns access failures and mechanical Git recovery.
Follow .agents/skills/_shared/pr-follow-up.md.
Adding a CLI command:
- Entry point:
bin/nemoclaw.js(launches the compiled CLI indist/) - Main CLI implementation lives in
src/lib/and compiles todist/lib/ - Add tests in
test/
Adding a plugin feature:
- Source:
nemoclaw/src/ - Co-locate tests as
*.test.ts - Build with
cd nemoclaw && npm run build
Adding a network policy preset:
- Add YAML to
nemoclaw-blueprint/policies/presets/ - Follow existing preset structure (see
github.yaml,brave.yaml)
Adding model-specific sandbox compatibility:
- Add a declarative manifest under
nemoclaw-blueprint/model-specific-setup/<agent>/ - Use one
agentper manifest (openclaw,hermes, etc.); do not make shared multi-agent manifests - Put OpenClaw executable wrappers under
nemoclaw-blueprint/openclaw-plugins/ - Put Hermes executable wrappers under
agents/hermes/ - Keep
agents/hermes/generate-config.tsas a thin build-time entrypoint; add Hermes env parsing, config construction, registry handling, and serialization underagents/hermes/config/ - Do not add Hermes behavior for an OpenClaw issue without a Hermes-specific repro or acceptance test
When the managed sandbox image changes, update digest and components.sandbox.image in
nemoclaw-blueprint/blueprint.yaml with the same immutable SHA-256 digest. Release tooling must
update both fields together. test/onboarding/validate-blueprint.test.ts rejects mutable tags and
mismatched digests.
npm installat root triggersprek installwhich sets up git hooks. If hooks fail, check thatcore.hooksPathis unset:git config --unset core.hooksPath- The
nemoclaw/subdirectory has its ownpackage.jsonandnode_modules. It is a separate npm project that shares the root Oxlint and Oxfmt configuration files. - Coverage thresholds are ratcheted in
ci/coverage-threshold-*.json— new code should not decrease CLI or plugin coverage - The
.claude/skillssymlink points to.agents/skills— both paths resolve to the same content
- Treat
docs/as the source of truth for public-facing documentation. Follow the Documentation Agent Guide for the documentation-agent workflow, including DORI routing. - Ordinary code PRs may defer only
docs/**,fern/docs.yml, andfern/assets/**changes toDocs / Author Post-Merge Catch-Up. Keep all other owning repository guidance in the same PR, including activeAGENTS.mdfiles,.agents/skills/**, andtest/e2e/**/README.md. - Direct documentation-only changes follow
docs/AGENTS.md, the shared Documentation Writing and Review contract, documented validation, and independent review.
Follow nemoclaw-contributor-create-pr for publication.
- PRs that change
scripts/prepare-dgx-station-host.shmust 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. - No secrets, API keys, or credentials committed
- Check
.github/pr-limits.jsonfor the contributor's open PR limit.