docs: refresh docs and skills

.agents/skills/nemoclaw-contributor-create-pr/SKILL.md

@@ -51,7 +51,7 @@ Run the docs and hook checks instead:
 
 ```bash
 npx prek run --all-files
-make docs
+npm run docs
 ```
 
 If a required check fails, fix the issue before creating the PR.
@@ -134,7 +134,7 @@ Use the exact template structure below. Fill in each section based on the diff (
 - [ ] Tests added or updated for new or changed behavior
 - [ ] No secrets, API keys, or credentials committed
 - [ ] Docs updated for user-facing behavior changes
-- [ ] `make docs` builds without warnings (doc changes only)
+- [ ] `npm run docs` builds without warnings (doc changes only)
 - [ ] Doc pages follow the [style guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md) (doc changes only)
 - [ ] New doc pages include SPDX header and frontmatter (new pages only)
 
@@ -197,7 +197,7 @@ Created PR [#NNN](https://github.com/NVIDIA/NemoClaw/pull/NNN)
 
 - **Do not invent your own PR body format.** Use the template from Step 5 exactly.
 - **Do not omit sections.** Even if a section is not applicable, keep it with the "Skip if..." comment.
-- **Do not check boxes for steps you did not run.** If you did not run `make docs`, leave that box unchecked.
+- **Do not check boxes for steps you did not run.** If you did not run `npm run docs`, leave that box unchecked.
 - **Do not run the full test suite for doc-only changes by default.** Run docs and hook checks instead, and leave `npm test` unchecked unless you actually ran it.
 - **Do not forget the DCO sign-off.** CI will reject the PR without it.
 - **Do not forget `--assignee @me`.** Every PR must be assigned to its creator.

.agents/skills/nemoclaw-contributor-update-docs/SKILL.md

@@ -50,7 +50,7 @@ git log -50 --oneline --no-merges
 
 Filter to commits that are likely to affect docs. Apply every rule below before proceeding. A commit excluded by any rule must not produce doc changes.
 
-1. **Commit type**: `feat`, `fix`, `refactor`, `perf` commits often change behavior. `docs` commits are already doc changes. `chore`, `ci`, `test` commits rarely need doc updates.
+1. **Commit type**: `feat`, `fix`, `refactor`, `perf` commits often change behavior. `docs` commits are already doc changes, but still need a review pass when they fall in the scanned range.
 2. **Files changed**: Changes to `nemoclaw/src/`, `nemoclaw-blueprint/`, `bin/`, `scripts/`, or policy-related code are high-signal.
 3. **Ignore**: Changes limited to `test/`, `.github/`, or internal-only modules.
 4. **Skip list**: Exclude any commit whose short hash appears in `skip-commits`, or whose commit message or changed file paths contain a `skip-features` substring. Report skipped commits in the final summary under a "Skipped (docs-skip)" heading.
@@ -79,6 +79,8 @@ For each relevant commit, determine which doc page(s) it affects. Use this mappi
 | Inference-related changes | `docs/inference/inference-options.mdx` |
 
 If a commit does not map to any existing page but introduces a user-visible concept, flag it as needing a new page.
+If a commit already changes files under `docs/`, include those pages in the target page list and run a docs review or edit pass against them using the style guidance in Step 5.
+Do not assume an existing doc change is complete, correctly placed, or style-compliant just because it landed with the source commit.
 
 ## Step 3: Read the Commit Details
 
@@ -98,6 +100,7 @@ Extract:
 ## Step 4: Read the Current Doc Page
 
 Before editing, read the full target doc page to understand its current content and structure.
+For target pages that were already changed by a scanned commit, compare the committed doc diff against the source behavior and the style guidance before deciding whether to edit further.
 
 Identify where the new content should go. Follow the page's existing structure.
 
@@ -161,9 +164,8 @@ Skip this step when the user only asked for ordinary doc catch-up and no release
 
 If the user invoked this skill for release prep, finish the release-specific doc work before verification:
 
-1. Make any requested doc version bumps in `versions1.json` and `project.json` in the `docs/` directory.
-2. Determine the release label from the release version. Release labels use `vX.Y.Z` format. For example, if `docs/project.json` has `"version": "0.0.37"`, the release label is `v0.0.37`. Use the version requested by the user if one was provided; otherwise use the version in `docs/project.json` after the bump.
-3. Refresh the NemoClaw user skills:
+1. Determine the release label from the release version requested by the user. Release labels use `vX.Y.Z` format. For example, release `0.0.37` uses label `v0.0.37`. If the user did not provide a release version, ask for it before opening the release-prep PR.
+2. Refresh the NemoClaw user skills:
 
    ```bash
    python3 scripts/docs-to-skills.py docs/ .agents/skills/ --prefix nemoclaw-user --doc-platform fern-mdx
@@ -174,7 +176,7 @@ If the user invoked this skill for release prep, finish the release-specific doc
 After making changes, build the docs locally:
 
 ```bash
-make docs
+npm run docs
 ```
 
 Check for:
@@ -213,10 +215,10 @@ User says: "Catch up the docs for everything merged since v0.1.0."
 3. Map each to a doc page.
 4. Read the commit diffs and current doc pages.
 5. Draft doc updates reflecting the source code changes in the commits following the style guide.
-6. **Release prep only:** Apply release-prep version bumps if the user requested release prep.
+6. **Release prep only:** Determine the release label from the user-requested release version.
 7. **Release prep only:** Run `python3 scripts/docs-to-skills.py docs/ .agents/skills/ --prefix nemoclaw-user --doc-platform fern-mdx`.
 8. Present the summary.
-9. Build with `make docs` to verify.
+9. Build with `npm run docs` to verify.
 10. **Release prep only:** Commit changes and open a pull request with the `documentation` label and the corresponding `vX.Y.Z` release label. Include a concise summary of the doc updates and a source summary that links each identified merged PR to its matching doc page. Include the PR number, affected doc page, links, and description of the doc change in this shape:
 
    ```markdown

.agents/skills/nemoclaw-user-configure-inference/SKILL.md

@@ -31,10 +31,36 @@ The onboard wizard detects Ollama automatically when it is installed or running
 
 If Ollama is installed but not running, NemoClaw starts it for you.
 On macOS and Linux, the wizard can also offer to install Ollama when it is not present.
+When the host Ollama is below the minimum version NemoClaw expects for its starter models (currently `0.7.0`), the wizard surfaces an explicit **Upgrade Ollama** entry in the provider menu instead of silently reusing the older daemon, and the express setup path resolves to that entry.
+The wizard inspects both the CLI binary (`ollama --version`) and the locally running daemon (`/api/version` on `:11434`) so the upgrade entry still appears when only one side is stale, for example a fresh user-local binary paired with the original system daemon.
+The gate skips Windows-host Ollama reached from WSL via `host.docker.internal`; the separate **Use / Start / Install Ollama on Windows host** entries handle that case and run their own actions on the Windows side.
+On macOS, the wizard runs the platform install or upgrade path with `brew upgrade ollama`.
+On Linux, the wizard runs the official `https://ollama.com/install.sh` path.
+Upgrades on Linux always take the sudo-driven system path because the sudo-free user-local fallback would leave the existing system daemon on `:11434` serving the stale binary.
+If sudo is not available in a non-interactive run, NemoClaw refuses to silently downgrade the path and asks you to rerun interactively or upgrade Ollama manually.
+After an upgrade finishes, NemoClaw re-probes the running daemon's `/api/version` and fails the run if the daemon still reports below the minimum.
+Fresh installs skip this re-probe because the bundled installers ship a daemon at or above the minimum.
 On WSL, the wizard can use, start, restart, or install Ollama on the Windows host through PowerShell interop.
-On Debian and Ubuntu, the native Linux install path checks for `zstd` before it runs the Ollama installer.
-If `zstd` is missing, NemoClaw installs it with `apt-get` and explains the sudo prompt before continuing.
-On non-apt Linux distributions, install `zstd` first, then rerun onboarding.
+
+### Linux Install Modes
+
+On native Linux, the install path picks between a system install (under `/usr/local`, via the official `https://ollama.com/install.sh`) and a sudo-free user-local install (under `${HOME}/.local`).
+NemoClaw selects the mode automatically:
+
+- Running as root or with passwordless sudo (`sudo -n true` returns 0) selects the system install.
+- A non-interactive run (`NEMOCLAW_NON_INTERACTIVE=1` or no TTY on stdin) without passwordless sudo selects the user-local install.
+  This is the path that lets headless hosts complete onboarding without prompting for a sudo password.
+- An interactive shell without passwordless sudo selects the system install and lets the official installer prompt for the password as usual.
+
+Override the detection with `NEMOCLAW_OLLAMA_INSTALL_MODE=system` or `NEMOCLAW_OLLAMA_INSTALL_MODE=user`.
+
+The user-local install replicates only the binary extraction step of the official installer.
+It downloads the release tarball, extracts it to `${HOME}/.local`, and launches `${HOME}/.local/bin/ollama serve` once.
+It does not configure a systemd service, does not create the `ollama` system user, and does not install CUDA drivers, so the daemon must be relaunched manually after a reboot.
+NemoClaw also prints a one-line `PATH` hint if `${HOME}/.local/bin` is not already on your `PATH`; you can add `export PATH="${HOME}/.local/bin:$PATH"` to your shell profile to invoke `ollama` directly.
+
+Both modes rely on `zstd` for archive extraction. On Debian and Ubuntu, the system path uses `sudo apt-get` to install `zstd` automatically and explains the prompt before continuing.
+The user-local path cannot bootstrap system packages without elevation, so if `zstd` is missing it prints per-distro install hints and exits — install `zstd` manually, then rerun onboarding.
 
 Run the onboard wizard.
 
@@ -44,7 +70,8 @@ $ nemoclaw onboard
 
 Select **Local Ollama** from the provider list.
 NemoClaw lists installed models or offers starter models if none are installed.
-On hosts with at least 32 GiB of detected GPU memory, the starter list includes `qwen3.6:35b` and selects it by default.
+On hosts where the larger starter models fit the currently available GPU memory, the starter list includes `qwen3.6:35b` and selects it by default.
+When another GPU workload is using most of the memory at onboard time, NemoClaw downgrades the menu to the largest model that still fits.
 It pulls the selected model, loads it into memory, and validates it before continuing.
 If the selected model declares that it does not support tool calling, onboarding stops with guidance to choose a model whose `ollama show <model>` capabilities include `tools`.
 The validation also requires structured chat-completions tool calls.
@@ -136,6 +163,8 @@ $ NEMOCLAW_PROVIDER=ollama \
 ```
 
 If `NEMOCLAW_MODEL` is not set, NemoClaw selects a default model based on available memory.
+If `NEMOCLAW_MODEL` names a known bootstrap model (for example `qwen3.6:35b`) that does not fit the host's currently available GPU memory, NemoClaw warns and falls back to the largest known model that does fit.
+Unknown or custom tags (any value the bootstrap registry has not seen) are still passed through; the Ollama runner validates the choice itself.
 
 `--yes` (or `NEMOCLAW_YES=1`) authorises the Ollama model download without an interactive confirmation prompt.
 Under `--non-interactive`, `--yes` (or `NEMOCLAW_YES=1`) is required to authorise the download — onboard exits otherwise, since it cannot prompt.

.agents/skills/nemoclaw-user-configure-security/references/best-practices.md

@@ -174,7 +174,7 @@ The container mounts system directories read-only to prevent the agent from modi
 ### Agent Config Directory
 
 The `/sandbox/.openclaw` directory contains the OpenClaw gateway configuration (model routing, CORS settings, channel config).
-The current entrypoint reads the gateway auth token from OpenClaw config when present, exports it as `OPENCLAW_GATEWAY_TOKEN`, and writes it to `/tmp/nemoclaw-proxy-env.sh` so interactive sandbox sessions can reach the gateway through the static `/sandbox/.bashrc` and `/sandbox/.profile` source shims.
+The current entrypoint reads the gateway auth token from OpenClaw config when present, exports it as `OPENCLAW_GATEWAY_TOKEN`, and writes it to `/tmp/nemoclaw-proxy-env.sh` so interactive sandbox sessions can reach the gateway through system-wide shell hooks.
 In root mode, the gateway process still runs as the separate `gateway` user, but the token is intentionally available to sandbox shells for local gateway access.
 
 Writable agent state such as plugins, skills, hooks, and workspace metadata lives directly under `/sandbox/.openclaw`.

.agents/skills/nemoclaw-user-deploy-remote/references/sandbox-hardening.md

@@ -98,8 +98,8 @@ System paths remain read-only to prevent agents from:
 - Modifying DNS resolution or TLS trust stores
 - Tampering with libraries or shell configuration outside `/sandbox`
 
-The image build pre-creates shell init files `.bashrc` and `.profile`.
-These files source runtime proxy configuration from `/tmp/nemoclaw-proxy-env.sh`.
+The image build pre-creates locked shell init files `.bashrc` and `.profile` without proxy entries.
+Runtime proxy configuration is sourced from system-wide shell hooks that read `/tmp/nemoclaw-proxy-env.sh`.
 
 ### Landlock Kernel Requirements
 

.agents/skills/nemoclaw-user-manage-policy/references/integration-policy-examples.md

@@ -163,6 +163,20 @@ $ nemoclaw my-assistant policy-add github --yes
 $ nemoclaw my-assistant policy-add jira --yes
 ```
 
+The `jira` preset intentionally allows Node.js access to Atlassian Cloud and does not allow `curl`.
+When validating it manually, avoid plain `curl -s` against `auth.atlassian.com`.
+Atlassian can return an empty redirect body even when the request succeeds.
+Use an explicit status probe instead:
+
+```console
+$ node -e "require('https').get('https://api.atlassian.com', r => console.log(r.statusCode))"
+$ curl -sS -o /dev/null -w '%{http_code}' --max-time 10 https://auth.atlassian.com
+```
+
+Before approval, the curl probe should report `000` or a local policy denial.
+After approving the blocked request in OpenShell, it should report an HTTP
+status such as `301` or `200`.
+
 Remove access when the task is done:
 
 ```console

.agents/skills/nemoclaw-user-manage-sandboxes/references/messaging-channels.md

@@ -30,6 +30,8 @@ For details, refer to Commands (use the `nemoclaw-user-reference` skill).
 
 Telegram uses a bot token from [BotFather](https://t.me/BotFather).
 Open Telegram, send `/newbot` to [@BotFather](https://t.me/BotFather), follow the prompts, and copy the token.
+For Telegram group chats, disable privacy mode before testing group replies: in @BotFather, run `/setprivacy`, choose the bot, then choose **Disable**.
+After changing privacy mode, remove the bot from each Telegram group and add it back so Telegram applies the new delivery setting to that group.
 `TELEGRAM_ALLOWED_IDS` is a comma-separated list of Telegram user IDs for DM access.
 Group chats stay open by default so rebuilt sandboxes do not silently drop Telegram group messages because of an empty group allowlist.
 Set `TELEGRAM_REQUIRE_MENTION=1` to make the bot reply in Telegram groups only when users mention it.
@@ -190,6 +192,7 @@ Use the matching policy preset (`telegram`, `discord`, `slack`, or `whatsapp`) o
 ## Tunnel Command
 
 When the host has `cloudflared`, `nemoclaw tunnel start` starts a cloudflared tunnel that can expose the dashboard with a public URL.
+Set `CLOUDFLARE_TUNNEL_TOKEN` before running the command when you want to use a Cloudflare named tunnel instead of a generated quick-tunnel URL.
 `nemoclaw tunnel stop` stops the tunnel and asks NemoClaw to stop the in-sandbox gateway for the selected or default sandbox.
 The older `nemoclaw start` still works as a deprecated alias.
 

.agents/skills/nemoclaw-user-overview/references/how-it-works.md

@@ -14,7 +14,7 @@ NemoClaw keeps the user workflow on the host while OpenShell enforces the sandbo
 The gateway sits between NemoClaw control, the sandbox, inference providers, and external integrations.
 That placement lets NemoClaw configure the environment without giving the agent direct access to host credentials or uncontrolled network egress.
 
-![NemoClaw High-Level Component Diagram](https://docs.nvidia.com/nemoclaw/latest/about/images/nemoclaw-highlevel-component-diagram.html)
+![NemoClaw High-Level Component Diagram](images/nemoclaw-highlevel-component-diagram.png)
 
 The diagram has the following components: