ov-jupyter/skills/jupyter-ml-notebook/SKILL.md
Full CUDA ML JupyterLab image with finetuning, Ollama, and LLM course notebooks, CRDT MCP server, and real-time collaboration. Base: nvidia. Port 8888. Combines jupyter-ml with 37 Unsloth fine-tuning notebooks, 6 Ollama integration notebooks, and 15 LLM course notebooks. MUST be invoked before building, deploying, or troubleshooting the jupyter-ml-notebook image.
npx skillsauth add overthinkos/overthink-plugins jupyter-ml-notebookInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
jupyter-ml-notebook:
base: nvidia
layers:
- agent-forwarding
- jupyter-ml
- notebook-templates
- notebook-finetuning
- notebook-ollama
- notebook-llm-on-supercomputers
- notebook-openrouter
- dbus
- ov
ports:
- "8888:8888"
platforms:
- linux/amd64
This image is identical to jupyter-ml with two data layer additions:
notebook-finetuning — seeds 37 Unsloth fine-tuning notebooks into ~/workspace/finetuning/notebook-ollama — seeds 6 Ollama integration notebooks into ~/workspace/ollama/The Ollama notebooks require a running ollama deployment. When deployed via ov config ollama --update-all, the OLLAMA_HOST env var is automatically injected via env_provides -- no manual configuration needed.
jupyter-ml — Tier 2 environment-owning meta-layer (PyTorch >= 2.10.0, vLLM 0.19, unsloth, LangChain, CRDT MCP via jupyter-mcp sub-layer)notebook-templates — Starter notebooks (data layer, seeds ~/workspace)notebook-finetuning — 37 Unsloth fine-tuning notebooks (data layer, seeds ~/workspace/finetuning/)notebook-ollama — 6 Ollama integration notebooks (data layer, seeds ~/workspace/ollama/)notebook-llm-on-supercomputers — 15 LLM course notebooks (data layer, seeds ~/workspace/llms_on_supercomputers/)agent-forwarding — SSH/GPG agent forwardingdbus — D-Bus session busov — Overthink CLI| Port | Service |
|------|---------|
| 8888 | JupyterLab + MCP endpoint at /mcp |
| Name | Path | Purpose | |------|------|---------| | workspace | ~/workspace | Persistent notebook storage | | models | ~/.cache/huggingface | HuggingFace model cache (from unsloth sub-layer) |
| Layer | Target | Dest | Contents | |-------|--------|------|----------| | notebook-templates | workspace | (root) | getting-started.ipynb | | notebook-finetuning | workspace | finetuning/ | 37 Unsloth notebooks (SFT, GRPO, DPO, RLOO, QLoRA) | | notebook-ollama | workspace | ollama/ | 6 Ollama API notebooks (requests, OpenAI, ollama lib, GPU, HuggingFace, Anthropic) | | notebook-llm-on-supercomputers | workspace | llms_on_supercomputers/ | 15 LLM course notebooks (prompt engineering, RAG, fine-tuning) + datasets |
~/workspace/
getting-started.ipynb (from notebook-templates)
finetuning/ (from notebook-finetuning)
.env.example
notebooks.yaml
00_Unsloth_Setup.ipynb
01_FastInference_Llama.ipynb
01_FastInference_Qwen.ipynb
02_Vision_Training_Ministral.ipynb
03_SFT_Training_Qwen.ipynb
04_GRPO_Training_Qwen.ipynb
05_DPO_Training_Qwen.ipynb
06_Reward_Training_Qwen.ipynb
07_RLOO_Training_Qwen.ipynb
08_QLoRA_Alpha_Scaling_Ministral.ipynb
... (37 notebooks total)
ollama/ (from notebook-ollama)
notebooks.yaml
00_Ollama_Requests.ipynb
01_Ollama_GPU.ipynb
02_Ollama_OpenAI.ipynb
03_Ollama_Library.ipynb
04_Ollama_HuggingFace.ipynb
05_Ollama_Anthropic.ipynb
llms_on_supercomputers/ (from notebook-llm-on-supercomputers)
notebooks.yaml
datasets/
D0_00_Bazzite_AI_Setup.ipynb
D1_01_Prompting_with_LangChain.ipynb
D1_02_Prompt_templates_and_parsing.ipynb
... (15 notebooks total)
This image is a consumer of env_provides variables from infrastructure layers:
| Variable | Injected by | Value |
|----------|------------|-------|
| OLLAMA_HOST | /ov-ollama:ollama | http://ov-ollama:11434 |
The notebooks read OLLAMA_HOST via os.getenv("OLLAMA_HOST", "http://localhost:11434"). When ollama is deployed via ov config ollama --update-all, the env_provides mechanism overrides the localhost default automatically.
ov image build jupyter-ml-notebook
ov config jupyter-ml-notebook
ov start jupyter-ml-notebook
ov status jupyter-ml-notebook
ov logs jupyter-ml-notebook -f
# JupyterLab: http://localhost:8888
# MCP endpoint: http://localhost:8888/mcp
# With bind-backed workspace (data seeded into local dir):
ov config jupyter-ml-notebook --bind workspace=/path/to/project
The notebook-finetuning include compatibility fixes for current library versions:
ov shell jupyter-ml-notebook -c "pixi run verify-pytorch"
ov shell jupyter-ml-notebook -c "pixi run verify-unsloth"
ov shell jupyter-ml-notebook -c "pixi run verify-mcp"
ov shell jupyter-ml-notebook -c "ls ~/workspace/finetuning/"
ov shell jupyter-ml-notebook -c "ls ~/workspace/ollama/"
ov shell jupyter-ml-notebook -c "ls ~/workspace/llms_on_supercomputers/"
/ov-jupyter:jupyter-ml — Same stack without finetuning notebooks/ov-jupyter:jupyter — Lightweight variant (no CUDA, multi-arch)/ov-jupyter:unsloth-studio — Unsloth Studio UI (different pixi env, same finetuning notebooks)MCP testing: same 3 deploy-scope mcp: checks as jupyter-ml are inherited here. See /ov-build:mcp for the verb reference.
MUST be invoked before building, deploying, configuring, or troubleshooting the jupyter-ml-notebook image.
/ov-build:image — image family umbrella (image: entries in overthink.yml, build/validate/inspect/list)/ov-build:build — build.yml vocabulary (distros, builders, init-systems)development
Claude Code multi-agent support in Overthink — sub-agents, dynamic workflows, and agent teams, and how each drives the existing `ov eval` disposable beds to test and verify. MUST be invoked before authoring or invoking an ov sub-agent / dynamic workflow / agent team, wiring agent-lifecycle hooks, or asking "which primitive should drive the R10 beds?".
tools
Mounts a virtiofs share tagged `workspace` at /workspace inside a VM guest via a systemd .mount unit. Use when a kind:vm entity shares a host directory into the guest and you need it auto-mounted (and re-mounted at every boot).
development
MUST be invoked before any work involving: the `kind: android` schema kind, a `target: android` deploy, the `apk:` layer package format (installing Android apps declaratively), AndroidDeployTarget, an in-pod emulator OR a remote/physical adb-endpoint device, or nested `pod → android` deployment. The first-class Android device + app surface that sits above `ov eval adb`/`appium`.
tools
Use when committing, branching, pushing, merging, tagging, creating PRs, or approving/merging PRs with gh — the feat/-branch, R10-gated, never-force-push landing workflow across the main repo + the plugins submodule + image/<distro> submodules. Covers sync-to-upstream, branch/worktree pruning, the fork+PR path for contributors without write access, and cross-repo @github landing order.