Add nv-tech-assistant example

[ZhiyongBNV]

Description

Adds examples/nv-tech-assistant/ — an example that turns a NemoClaw-managed OpenClaw agent into a grounded NVIDIA technical assistant, and doubles as a minimal, reusable recipe for the two most common sandbox customizations: adding a custom skill and adding custom network policies, both applied to a running sandbox with no rebuild.

NVIDIA's technology surface is large, overlapping, and fast-moving — dozens of similarly-named SDKs, models that get renamed, repos that move between orgs — so an agent answering from memory produces plausible-but-wrong SDK names, invented APIs, and dead links. The nv-tech-assistant skill fixes this by grounding: it routes every NVIDIA technical question ("how do I use this SDK", "recommend a model for X", "how do I fix this TensorRT error") to searches against authorized sources (docs.nvidia.com, developer.nvidia.com, NGC, build.nvidia.com, the developer blog and forums, NVIDIA's GitHub orgs, the NVIDIA Hugging Face org, arXiv) and answers only with cited, verbatim-quoted evidence.

What's included

• examples/nv-tech-assistant/README.md — guide covering: apply the policy presets → upload the skill (nemoclaw <sbx-name> upload skills/nv-tech-assistant /sandbox/.openclaw/skills/, recognized by OpenClaw at runtime) → try it via the OpenClaw TUI or a connected messaging channel, with example /nv_tech_assistant prompts and a pointer for writing your own custom policy from the bundled YAMLs.
• examples/nv-tech-assistant/policies/ — three egress policy presets for policy-add: nvidia_ext.yaml (*.nvidia.com sites), github_ext.yaml (github.com, api.github.com, raw.githubusercontent.com read-only), arxiv.yaml (arxiv.org, export.arxiv.org).
• examples/nv-tech-assistant/skills/nv-tech-assistant/ — the skill: SKILL.md (grounding principles, workflow, and playbooks for five question types: SDK usage/sample code, technology recommendation, success stories, troubleshooting, integration planning) plus references/ (NVIDIA product disambiguation map, per-source search recipes and URL patterns, a policy-authoring guide, and an annotated policy template).
• One row in the root README example catalog.

Verification

• python scripts/check_license_headers.py --check
• git diff --check
• Relevant example setup or syntax checks
  • Setup the sandbox following the README.md file in the example

Release And Compliance

• No secrets, local .env files, private certificates, snapshots, or token caches are included.
• Third-party dependency changes are reflected in THIRD-PARTY-NOTICES.
• Public documentation is free of internal-only links or private workspace details.
• Commits include DCO sign-off (git commit -s).

[nv-nedelman-1]

any reason this is set to full API (read and write) access without tls?
same question for export.arxiv.org policy below

I would expect something like this for a read-only assistant:

access: read-only
protocol: rest
enforcement: enforce

[nv-nedelman-1]

same comment/idea as https://github.com/NVIDIA/nemoclaw-community/pull/49/changes#r3616540299

why full read/write access?

[nv-nedelman-1]

same comment as https://github.com/NVIDIA/nemoclaw-community/pull/49/changes#r3616540299

why full read/write access with tls skip?

[nv-nedelman-1]

we really want to avoid creating a policy with write access to an API unless it's absolutely required. I recommend having stronger wording in this agent skill e.g. something like "DO NOT add full access to an API endpoint unless it's absolutely required"

[nv-nedelman-1]

@ZhiyongBNV thanks for the contribution! Made some comments, mostly around network policy.

Additionally, can you add some convenience scripts for setup/teardown? We're trying to set some level of consistency across new examples added to the repo. The tavily example found here illustrates this well via onboard.sh, stop.sh scripts etc