nvwb
Skill156 starsChanged 7 days agoApache-2.0View on GitHub
Manage NVIDIA AI Workbench projects, contexts, builds, and environments via the nvwb CLI. This skill should be used when the user wants to create, clone, build, manage, or configure AI Workbench projects, contexts, or environments.
- Reads credentials
In this repository28 other files it gives its agents.
- AGENTS.mdAGENTS.md
- module-1Skill
- module-2Skill
- module-3Skill
- module-4Skill
- module-5Skill
- module-6Skill
- module-7Skill
- nvwb-projectSkill
- setup-workshop-nemoclaw-operatorSkill
- setup-workshop-nemoclawSkill
- setup-workshopSkill
- workshopSkill
- module-1Skill
- module-2Skill
- module-3Skill
- module-4Skill
- module-5Skill
- module-6Skill
- module-7Skill
- nvwb-projectSkill
- nvwbSkill
- setup-workshop-nemoclaw-operatorSkill
- setup-workshop-nemoclawSkill
- setup-workshopSkill
- workshopSkill
- code-reviewSkill
- technical-writingSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Before taking action, check the current state:
- Distinctive: line 59
When a build fails:
- Distinctive: line 60
Read the build output carefully for the error message
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
NVIDIA AI Workbench — Local Machine (Control Plane)
NVIDIA AI Workbench is a lightweight, containerized development platform for GPU-accelerated AI/ML workflows. Every project is a Git repo with a .project/spec.yaml that defines the container environment. It supports Docker and Podman as container runtimes.
The nvwb CLI always runs on the local machine — the user's laptop or desktop. From there it manages contexts, which may be local (container on the same machine) or remote (container on a server or cloud instance accessed via SSH). Codex using this skill is on the local machine.
The user wants help with: $ARGUMENTS
Core Concepts
- Contexts — Locations/machines where projects run (local, remote SSH, Brev cloud)
- Projects — Git repos with container configuration (
.project/spec.yaml) - Applications — Services inside the container (JupyterLab, VS Code, custom webapps/processes)
- Environment Variables — Runtime values set via CLI; sensitive ones (
--is-sensitive) are masked in output. Values are never committed to Git. Projects may declare required secret variable names inspec.yamlunderexecution.secrets.
Current State Detection
Before taking action, check the current state:
nvwb list contexts # What locations are configured?
nvwb status # Is a project open? Is the container running?
nvwb list projects # What projects exist in the active context?Build vs Runtime Isolation
Build-time (changes require nvwb build):
apt.txt— system packagesrequirements.txt— pip packagespreBuild.bash/postBuild.bash— custom build scripts- Package manager entries in
spec.yaml
Runtime (changes require container restart: nvwb close + nvwb open):
variables.env— environment variables- Mount configuration changes
- App definitions in
spec.yaml
No action needed:
- Code in layout directories (code/, data/, models/) — live-mounted at
/project/
Key Environment Variables
| Variable | Available | Description |
$NVWB_UID | Build-time | User ID for file ownership in build scripts |
$NVWB_GID | Build-time | Group ID for file ownership in build scripts |
$PROXY_PREFIX | Runtime | URL prefix for proxied web apps |
Error Handling
When a build fails:
- Read the build output carefully for the error message
- Common causes: bad package version in
requirements.txt, missing apt dependency, bash syntax error in build scripts - For deeper logs, check
project-runtime-info/inside the context's workbench directory — this is on the machine running the Workbench service, not necessarily the local machine. Find the right path first:cat ~/.nvwb/contexts.json # workbenchDir field for each context- Local context:
~/.nvwb/project-runtime-info/ - Remote context (SSH or Brev):
<workbenchDir>/project-runtime-info/on the remote — access viassh <context-name> "ls <workbenchDir>/project-runtime-info/"
- Local context:
- Fix the relevant config file
- Run
nvwb buildagain - For persistent issues, try
nvwb build --full-buildfor a clean rebuild
When to Rebuild vs Restart vs Do Nothing
| Change | Action |
| Edit code files | Nothing |
Edit apt.txt, requirements.txt, build scripts | nvwb build |
Edit variables.env | nvwb close then nvwb open |
Change mounts or app config in spec.yaml | nvwb close then nvwb open |
| Change compose services | nvwb compose down then nvwb compose up |
References
See the reference files for detailed information:
references/cli-reference.md— Complete CLI command referencereferences/spec-reference.md— spec.yaml structure and fieldsreferences/project-structure.md— Project file layout and rolesreferences/workflows.md— Multi-step workflow recipesreferences/nvwb-brev.md— Brev cloud GPU integration: stoppability, interactive vs manual bootstrap, org management, Brev CLI referencereferences/codex-in-container.md— Running Codex inside the container, credential persistence, and the host↔container bridge pattern
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

