Author and validate Platform-managed NeMo Agents agent.yaml files using the nemo-agents-spec-v1 format. Use when the user wants to create, edit, validate, or adapt an agent.yaml file, choose a supported harness, add instructions, skills, MCP servers, tools, environment, or telemetry.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Author and validate Platform-managed NeMo Agents agent.yaml files using the nemo-agents-spec-v1 format. Use when the user wants to create, edit, validate, or adapt an agent.yaml file, choose a supported harness, add instructions, skills, MCP servers, tools, environment, or telemetry.
["nemo-build-agent (use for full Ethos-to-deployed-agent build flows)","nemo-explore (use to design what the agent should do before writing config)","nemo-ethos (use to write ETHOS.md before implementation)","nemo-model-selection (use when the user only wants model recommendation)","generic YAML editing unrelated to NeMo Platform agents"]
preconditions
["nemo_setup_complete","agents_plugin_available"]
compatibility
nemo-platform >= 0.1.0; writes or edits agents/<name>-ethos/agent.yaml; validates through nemo agents create; supports nemo-agents-spec-v1 configs; safe under sandbox.
maturity
active
license
Apache-2.0
user-invocable
true
allowed-tools
["Read","Write","Edit","Bash"]
NeMo Platform agent config
Create or edit the Platform-managed agent.yaml for a NeMo Agent. This skill
owns the machine-readable config shape for nemo-agents-spec-v1; nemo-build-agent
owns the full build/deploy/eval workflow.
Use product-facing Platform language. Do not ask users to write raw Fabric SDK
configuration. Fabric is an implementation dependency behind the Platform-managed
agent config.
Storage model
The local config lives next to the human-readable Ethos:
agents/<agent-name>-ethos/
ETHOS.md
agent.yaml
The platform stores the parsed agent.yaml contents in the Agent.config
payload with:
config_format:nemo-agents-spec-v1
The canonical remote config location is derivable from workspace and agent name:
<workspace>/<agent-name>-ethos#agent.yaml. Do not invent a separate ref field.
What you do
Confirm the agent name and config path. Default to
agents/<agent-name>-ethos/agent.yaml.
Select one supported harness:
codex
hermes
deepagents
claude
Invoke nemo-model-selection to select and compatibility-test the model for
the chosen harness. Configure models.default only after that skill returns
a verified provider and exact model name. Add a harness-local model
override only when that harness intentionally uses a different verified
provider, model, credential env var, or base URL.
Start from references/templates/agent.yaml unless the user is editing an
existing file. Write only the verified model fields returned in Step 3.
Remove every unselected harness block and every remaining placeholder. Keep
an additional harness only when the user explicitly requests it and its
model configuration has been separately verified.
Add system instructions under instructions.system.content.
Add optional skills, MCP servers, blocked tools, environment directories, and
telemetry using only fields in the template.
Keep all local file paths relative to the directory containing agent.yaml.
Validate by running nemo agents create against the config. Do not treat a
successful create as validation of an unused or untested harness.
For the standard subprocess or default-image deployment path, keep
skills.paths empty. Registration validates relative skill paths against the
authoring directory, but these deployment paths currently materialize only
agent.yaml and do not stage the referenced directories.
When non-empty skills.paths are required, each path must be relative to
agent.yaml, remain inside its packaging context, and contain SKILL.md.
Require the explicit image-packaging path before deployment:
Deploy that image with --mode docker --image "$IMAGE_TAG"; publish it first
and use the published tag for Kubernetes. Do not use a subprocess or
default-image deployment for an agent with relative skills.paths.
Migrating from legacy NAT workflow YAML
If the user has an existing NAT workflow YAML and wants the new Platform-managed
agent.yaml format, treat the migration as best-effort authoring. Do not
overwrite the original NAT YAML unless the user explicitly asks.
Map only fields with a clear Platform equivalent:
NAT workflow concept
Platform agent.yaml target
LLM/provider/model block
models.default or a harness-local model
System prompt or workflow prompt
instructions.system.content
Workflow/tool loop choice
default_harness plus harnesses.<name>.kind
Tool/function references
skills.paths, mcp.servers, tools.blocked, or harness settings when clearly supported
Tracing or telemetry settings
telemetry
For a NAT codex_agent workflow, apply this mapping instead of copying the
workflow fields into harnesses.codex.settings:
NAT Codex field
Platform agent.yaml target
working_directory
environment.workspace
sandbox_mode
harnesses.codex.settings.sandbox
approval_policy: never
harnesses.codex.settings.approval_mode: deny_all when the installed descriptor declares it; otherwise omit
relay_atof_output_dir
environment.artifacts, telemetry.output_dir, and telemetry.atof
skip_git_repo_check
Omit; removed CLI-only setting
timeout_seconds
Omit unless the installed Codex adapter settings schema declares it
max_output_chars
Omit; no current Codex adapter setting
prefer_chatgpt_auth
Omit; authentication is selected by the Codex adapter and model configuration
Treat the installed Fabric adapter descriptor's settings_schema as
authoritative. Only place keys declared under its properties in
harnesses.<name>.settings; do not preserve an unsupported NAT setting merely
because it existed in the source workflow. Surface omitted behavior in the
migration summary. For Codex, map never to deny_all only when
settings_schema.properties.approval_mode.enum includes deny_all.
If behavior does not map cleanly, say so directly and choose one:
Keep the agent on the NAT compatibility path.
Preserve the original NAT YAML and create a partial agent.yaml starter for
manual completion.
Mark it as requiring a custom adapter or a manual harness-specific migration.
Never claim a mechanical one-to-one conversion for arbitrary NAT workflows.
Config shape
Use this structure. Keep unknown fields out of the YAML; the Platform validator
rejects unsupported fields instead of passing arbitrary execution config through.
If base_url is needed, put it directly in the model block, not under
settings.
Use nemo-model-selection for every harness. It must verify the exact model
against that harness's model contract before returning it: Responses for
codex, the selected provider's chat path for hermes and deepagents, and
the native Anthropic provider contract for claude. Do not route Claude
through Platform IGW. Do not write or finalize agent.yaml if model selection
cannot establish a compatible model. For Platform-routed models, availability,
provider metadata, config validation, and Fabric planning do not replace a
valid inference request through the required wire API.
Validate and register
Before registering, validate the YAML shape with the Platform create path.
Immediately before running nemo agents create, show the command to the user,
ask for explicit confirmation, and wait for approval.
For local one-shot validation without registering an Agent entity, use this
only when the selected model already has a directly usable provider endpoint
and credentials. Platform IGW normalization is applied by the registered
deployment path, not this local path:
