Nemo Skill Selection

NeMo Platform skill selection

Decide which downstream NeMo Platform skill should run. Bash access is unrestricted at runtime and can execute state-changing commands; the scope below is a behavioral constraint, not an enforced allowlist. Execute only the host scan in this skill's Pre-flight section, then announce the choice and hand off. Never run downstream workflow or state-changing platform commands from this skill.

New NeMo Platform agent builds use a Platform-managed agent.yaml with config_format: nemo-agents-spec-v1 and a supported harness. NVIDIA NeMo Agent Toolkit (NAT) workflow YAML remains a compatibility path. Do not describe NAT as the only supported implementation model.

If an existing agent does not fit a supported harness contract, route based on the user's goal: preserve an existing NAT workflow, identify a custom adapter, or use nemo-agent-config for a best-effort migration. Do not promise that an arbitrary Python entrypoint can be converted mechanically.

Decision table

Match the user's intent to one downstream skill. Pick exactly one.

Optimize vs build: Do NOT route optimize asks to nemo-build-agent. Build is for creating new agents from a spec. Use agents-optimize for a deployed agent's routing, prompts, skills, cost, or latency; use nemo-experimentalist when the requested improvement changes the agent's own source or harness and is evaluated with candidate code changes. If the user says "make my agent faster" or "use a cheaper model," that is agents-optimize, not nemo-build-agent.

If a request includes both config authoring and deployment, choose nemo-build-agent; it delegates the config portion to nemo-agent-config. Choose nemo-agent-config when the requested output stops at a validated config or migration. Otherwise, if two rows fit, pick the earliest one in the lifecycle. If nothing matches, ask one disambiguating question with the relevant rows as a numbered list.

Pre-flight

Before handing off, run a host-wide platform scan. Three signals, in order — the first one that fires wins:

# 1. Ground truth: is anything listening on the canonical port?
lsof -iTCP:8080 -sTCP:LISTEN 2>/dev/null

# 2. Functional check: does the platform readiness endpoint answer?
curl -sS --connect-timeout 2 --max-time 5 http://localhost:8080/health/ready -o /dev/null -w "%{http_code}\n" 2>/dev/null || echo "no-response"

# 3. Conflict check: other platform processes / data dirs / configs on this host?
ps -eo pid=,user=,comm=,args= 2>/dev/null \
  | awk '$0 ~ /[n]emo services (run|start)|[n]emo-platform run/ {print $1, $2, $3}'
ls -d ~/.local/share/nemo* 2>/dev/null
ls ~/.config/nmp*/config.yaml 2>/dev/null

Interpretation:

Read-only callers (this skill, nemo-status, the build/try pre-flights) should not trust nemo services status or nemo services ls as an up-check. Both report stale "running" from a held instance lock after the underlying process has died. The lock reconciles automatically the next time nemo services run is invoked, but until that happens, lsof is ground truth. (Tracking a CLI-side fix for this so we can drop the workaround from skills.)

What to announce

Tell the user, in one sentence, which skill is next and what it will do. For example: "Handing off to setup to verify the platform is installed and running. If it isn't, the skill will tell you the CLI command to run; install is a 5-minute shell step that this skill cannot do reliably for you."

Then hand off. Do not run downstream workflow or state-changing platform commands from this skill.

If nothing matches

If the user's intent doesn't fit any row, do not guess. Read out the available skills and ask which one they want:

NeMo Platform skills I can route to:
  setup           verify install or get the CLI install command
  nemo-explore    design conversation: capture goal, audience, tools, constraints
  nemo-ethos      write the design to agents/<name>-ethos/ETHOS.md
  nemo-agent-config  author, validate, or migrate Platform agent.yaml
  nemo-build-agent  build from the Ethos, register, deploy, evaluate, and sign off
  nemo-try-agent  invoke a named deployment or local agent YAML config
  nemo-intake     instrument agents, ingest/query telemetry, attach scores
  nemo-experiments-upload  publish named evaluation runs to an Experiments leaderboard
  nemo-status     read-only platform health dashboard
  nemo-teardown   guided shutdown

Plugin-owned skills:
  agents-optimize   cost / latency / quality optimization for a deployed agent
  agents-secure     safety and security audit for a deployed agent
  nemo-evaluator    evaluation metrics, LLM-judge, benchmark jobs
  nemo-customizer   fine-tuning of models
  nemo-analyst      analyze agent telemetry and file recurring problems as Insights
  nemo-experimentalist  source/harness optimization from Insights or evaluation datasets
  guardrails        content-safety middleware via virtual models
  auditor           red-team vulnerability scanning (garak)
  data-designer     synthetic dataset generation
  anonymizer        PII handling for datasets

Which one fits what you're trying to do?

For things outside this catalog (for example, "show me how Switchyard routes between models"), point at the relevant repo skill (nemo-evaluator, nemo-auditor, etc.) or tell the user no skill claims that intent yet. Do not invent a path.

If the pre-flight finds no platform but the user insists they have installed one: ask them to report the output of lsof -iTCP:8080 -sTCP:LISTEN and the redacted scan below from the shell where they ran setup. The platform may be bound to a non-default port, or the install may be in a venv whose nemo binary is not on PATH.

ps -eo pid=,user=,comm=,args= 2>/dev/null \
  | awk '$0 ~ /[n]emo services|[n]emo-platform run/ {print $1, $2, $3}'

If the user asks about Studio (web UI)

Skills route through CLI commands, not Studio. But customers ask "what's Studio?" or "do you have a web UI?" Answer honestly, do not invent capabilities, and do not steer users into the experimental flows.

What to say:

• Studio is the NeMo Platform web UI. When the platform is running locally, it serves at http://localhost:8080/studio.
• Documentation: docs/studio/index.md in this repo covers the stable views (Agents, Optimizations, Monitor, Workspaces, Datasets). Point users there rather than enumerating features in-conversation — the docs stay up to date, this skill won't.
• Honest caveats to flag every time:
  • The Optimizations "Apply suggestion" flow is incomplete today. Suggestions render, but the apply action is not reliable end-to-end. Tell the user to apply optimizer suggestions via the CLI (nemo agents …) instead, using the suggestion's apply block as the source of truth — see agents-optimize.
  • Other views may evolve; refer to the docs for the current state rather than promising specific behavior.
• For local development on Studio itself, the source lives at web/packages/studio/. The studio-dev skill (if available) covers that workflow.

Do not proactively suggest Studio as the path for anything a skill already covers (chat, deploy, status, teardown, optimization). The CLI path is what these skills verify and what we can confidently support.

Gotchas

• One skill at a time. Do not load more than one downstream skill in the same turn. Each downstream skill is a full procedure with its own context budget.
• Install must happen before any skill can do useful work. Build, try, and status all assume the platform is up. If the user has not run the CLI install (make bootstrap + nemo setup), the skills cannot work around that; hand them to setup for instructions.
• NeMo Platform is the product name. Capital N, e, M, o, P. Not "nemo" or "Nemo." NAT on first mention is "NVIDIA NeMo Agent Toolkit (NAT)."
• Model customization goes to the nemo-customizer plugin skill when nemo-customizer-plugin (and a training backend) are installed. If that skill is not available, tell the user to enable customization plugins and install skills — do not improvise training with an external library.
• Execution compatibility. New Platform configs must select a supported harness. Existing NAT workflows may remain on the NAT compatibility path. For another framework or an arbitrary Python entrypoint, inspect whether a supported harness owns its lifecycle; otherwise identify a custom adapter or NAT wrapper instead of claiming direct support.