accessing-mlflow
Query and browse evaluation results stored in MLflow. Use when the user wants to look up runs…
Monitor submitted jobs (PTQ, evaluation, deployment) on SLURM clusters. Use when the user asks "check job status", "is my job done", "monitor my evaluation", "what's the status of the PTQ", "check on job <slurm_job_id>", or after any skill submits a long-running job. Also
$ npx -y skills add nvidia/model-optimizer --skill monitor --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/monitorContext preview
The summary Claude sees to decide when to auto-load this skill.
Monitor submitted jobs (PTQ, evaluation, deployment) on SLURM clusters. Use when the user asks "check job status", "is my job done", "monitor my evaluation", "what's the status of the PTQ", "check on job <slurm_job_id>", or after any skill submits a long-running job. Also
name: monitor description: Monitor submitted jobs (PTQ, evaluation, deployment) on SLURM clusters. Use when the user asks "check job status", "is my job done", "monitor my evaluation", "what's the status of the PTQ", "check on job <slurm_job_id>", or after any skill submits a long-running job. Also triggers on "nel status", "squeue", or any request to check progress of a previously submitted job.
Monitor jobs submitted to SLURM clusters — PTQ quantization, NEL evaluation, model deployment, or raw SLURM jobs.
1. **Auto-monitor** — another skill (PTQ, evaluation, deployment) just submitted a job. Register the job and set up monitoring immediately. 2. **User-initiated** — user asks about a job status. Check the current session registry first; if the job is not registered there, use the discovery steps below.
---
Active jobs are tracked in per-session registries under `.claude/agents/`. This avoids multiple agents clobbering one shared registry when they run at the same time.
Use the current agent session id as `<session_id>`:
Registry layout:
.claude/agents/
<session_id>/
active_jobs.jsonEach session's `active_jobs.json` is a JSON array:
[
{
"type": "nel",
"id": "<invocation_id or slurm_job_id>",
"host": "<cluster_hostname>",
"user": "<ssh_user>",
"submitted": "YYYY-MM-DD HH:MM",
"description": "<what this job does>",
"last_status": "<last known status>",
"owner": {
"agent": "claude-code|codex|manual",
"session_id": "<session_id>"
}
}
]`type` is one of: `nel`, `slurm`, `launcher`.
---
Every time a job is submitted (by any skill or manually):
1. **Add an entry** to `.claude/agents/<session_id>/active_jobs.json`. Create the session directory and file if they don't exist. 2. **Start a durable monitor** (if one isn't already watching the registry) that polls this session's registered jobs until they reach terminal status. Prefer the Claude Code `Monitor` tool when it is available: write a small watcher that reads `.claude/agents/<session_id>/active_jobs.json`, checks every job with the appropriate method below, prints state-change events, updates `last_status`, removes terminal jobs from the session registry, and exits when no active jobs remain for this session.
The monitor should terminate naturally when every registered job has reached a terminal state. If the `Monitor` tool is not available in the current harness, run an equivalent background process that implements the same loop and lets the agent resume/restart when the process exits.
Always do both steps. Don't try to predict job duration.
---
Whether triggered by monitor output or by the user asking "check status":
1. **Read the registry** from `.claude/agents/<session_id>/active_jobs.json` 2. **Check each job** using the appropriate method (see below) 3. **Report only state changes** — compare against `last_status` in registry 4. **Update `last_status`** in the session registry 5. **Remove completed jobs** — any job in a terminal state (COMPLETED, FAILED, CANCELLED, KILLED, TIMEOUT, NODE_FAIL, OUT_OF_MEMORY, PREEMPTED, BOOT_FAIL, DEADLINE) 6. **If no active jobs remain** — let the monitor exit
---
Each check method has its **own** status vocabulary. A watcher that mixes them (e.g. uses SLURM's `COMPLETED` terminal-state regex against `nel status` output) will silently never fire terminal transitions. Always match against the vocabulary of the source you're polling.
extract_nel_state() {
local jid="$1" nel_bin="${NEL:-nel}" output state_col
output=$("$nel_bin" status "$jid" 2>&1)
state_col=$(echo "$output" \
| awk -F'|' -v prefix="$jid." 'index($1, prefix) == 1 { print $2; exit }')
[ -z "$state_col" ] && state_col="$output"
echo "$state_col" \
| LC_ALL=C tr '[:lower:]' '[:upper:]' \
| awk 'match($0, /(PENDING|RUNNING|SUCCESS|FAILED|KILLED|ERROR|NOT[[:space:]]+FOUND)/) { print substr($0, RSTART, RLENGTH); exit }' \
| sed 's/[[:space:]][[:space:]]*/ /g'
}
is_nel_terminal() {
case "$(extract_nel_state "$1")" in
SUCCESS|FAILED|KILLED|ERROR|"NOT FOUND") return 0 ;;
*) return 1 ;;
esac
}can lag in `COMPLETING` after `sacct` reports a terminal state.
extract_slurm_state() {
local jid="$1" host="$2"
ssh "$host" "sacct -j $jid -X --format=State --noheader -P 2>/dev/null | head -1" \
| sed 's/^[[:space:]]*//;s/[[:space:]]*$//' \
| sed 's/^CANCELLED by .*/CANCELLED/'
}
is_slurm_terminal() {
case "$(extract_slurm_state "$1" "$2")" in
COMPLETED|FAILED|CANCELLED|TIMEOUT|NODE_FAIL|OUT_OF_MEMORY|PREEMPTED|BOOT_FAIL|DEADLINE) return 0 ;;
*) return 1 ;;
esac
}---
When the user asks about a job without specifying an ID, check in order:
1. `.claude/agents/<current_session_id>/ac
Documentation | Roadmap | NVIDIA Model Optimizer (referred to as Model Optimizer, or ModelOpt) is a library comprising state-of-the-art model optimization techniques including quantization, pruning, Neural Architecture Search (NAS), distillation, speculative
Query and browse evaluation results stored in MLflow. Use when the user wants to look up runs…
Inspect Hugging Face decoder layers on meta tensors and plan or run per-rank BF16, FP8, and…
Shared ModelOpt support files. Use only when another ModelOpt skill directs you here.
Establish baseline-vs-candidate evaluation plans, delegate missing evaluations, compare…
Deterministic end-to-end driver for day-0 quantized-checkpoint releases — chains PTQ →…