菜单
Captures what a NeMo Platform agent should do before any code or YAML. Explores the user's codebase and docs first, fills in every spec field it can infer, then asks the user only for the gaps. Output feeds nemo-spec. Use over generic brainstorming for any NeMo Platform agent design conversation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/NVIDIA-NeMo/nemo-platform --skill nemo-explore命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | nemo-explore |
| description | Captures what a NeMo Platform agent should do before any code or YAML. Explores the user's codebase and docs first, then asks one intent question at a time for what source cannot supply. Output feeds nemo-ethos. Use over generic brainstorming for any NeMo Platform agent design conversation. |
| triggers | ["design my agent","what should my agent do","help me think through the agent","I want to build an agent","agent design","explore the agent","figure out what my agent needs","bootstrap AGENT_DESCRIPTION","onboard my existing agent"] |
| not-for | ["nemo-skill-selection (use to dispatch when intent is unclear)","nemo-ethos (use to write the Ethos file once explore is done)","nemo-build-agent (use after the Ethos exists)","nemo-model-selection (use for the model question in step 5; explore delegates to it)","superpowers:brainstorming (use for design work unrelated to NeMo Platform)"] |
| preconditions | ["nemo_cli_available"] |
| compatibility | nemo-platform >= 0.1.0; dialogue-driven with read-only pre-flight (`ls`, `find`, `Read`); one intent question per message after the codebase scan; at least three questions covering Purpose & Outcomes, Principles, and Vision; safe under any sandbox; works offline; output is a structured conversation handed to nemo-ethos. |
| maturity | active |
| license | Apache-2.0 |
| user-invocable | true |
| allowed-tools | ["Read","Glob","Grep","Bash"] |
Capture what the agent should do before any code or YAML. Product mission and
user goals matter more than implementation inventory. The output of this skill
is the data that nemo-ethos writes into agents/<name>-ethos/ETHOS.md —
the durable contract that downstream optimization agents read as their primary
context. Underspecified input here directly degrades the quality of generated
Insights and PRs downstream.
This skill is explore first, then a mandatory intent interview. Scan the codebase and docs, infer implementation-shaped fields, then ask the user for intent source cannot own. Do not skip the interview because the scan looked complete, and do not skip a question because you think you already know the answer. Do not dump the draft Ethos until that interview has asked at least three questions and received a reply to each.
The division of labor is: infer implementation, ask for intent. Almost everything about what the agent is can be read from source. Nothing about what the developer wants can be. Constraints, trade-offs, principles, mission, and change permissions live in the user's head, so they are the questions worth spending attention on.
The Ethos has five base front-matter fields, plus optional updated_timestamp,
and fifteen body sections. Every body section is required. One field is a
quality gate for handoff: nemo-ethos is blocked until Role is concrete.
For any other canonical section with nothing to say, write _(none)_ rather
than dropping the heading.
The fifteen headings are a floor, not a ceiling. Extra ## headings and extra
YAML front-matter keys are allowed. Keep them if the user adds them. Do not
strip custom sections to make the file look "strict."
Front matter
| Field | Required | Guidance |
|---|---|---|
schema_version | yes | Always 1 for new files. nemo-ethos fills this at write time. |
name | yes | Canonical agent name. Use the directory or workflow name if obvious; ask if not. |
created_timestamp |
| yes |
ISO 8601 timestamp for when the Ethos is created. nemo-ethos fills this at write time. |
author | yes | Human or agent that created the Ethos. nemo-ethos fills this from the current author context when known; ask only if ambiguous. |
owner | optional | Accountable human or team for the approvals named in Constraints or Change Scope. Ask only if those sections name an approval. |
updated_timestamp | conditional | Set on edits. Omit on first write. nemo-ethos fills this. |
Body sections (in canonical order)
| # | Section | What "good" looks like |
|---|---|---|
| 1 | Role | One concrete sentence describing the role this agent plays. Example: "answer IT helpdesk questions about VPN, password reset, and software access." Vague answers ("help with stuff") are useless downstream. |
| 2 | Purpose & Outcomes | Two labeled parts. Mission: why the agent exists, what user value it provides, and the product or workflow context it serves — not a restatement of implementation mechanics. Outcome: the external result it is accountable for, with the measurable target and who owns that number. A mission with no outcome cannot be optimized; an outcome with no mission gets optimized in the wrong direction. Say so plainly when the agent is internal tooling with no business metric. |
| 3 | Scope | Audience, 3-6 task categories, expected in-scope work, and explicit out-of-scope work/non-goals. |
| 4 | Tools | Tools, APIs, and knowledge sources the agent can use, or "Prompt-only." Group related helpers by capability or source. Capture only behaviorally important purpose, credentials/scopes, side effects, freshness, and expected failures. |
| 5 | Harness | How this agent actually runs: the loop, tool use, and runtime. Write what is true of this agent. Do not pick a named platform harness, and do not treat a framework import as a requirement. Write _(none)_ if you cannot describe how it runs. |
| 6 | Behavior | Behavioral rules and boundaries: refusal/escalation policy, tone, safety/compliance requirements, accepted limitations, and known non-goals. Hard external limits belong in Constraints. |
| 7 | Principles | How the agent should decide when no rule in Behavior covers the case: which way to err on an ambiguous request, what it protects even at some cost to the answer, and whose interest wins when the user and the business disagree. Two or three concrete judgment calls. "Helpful, harmless, and honest" is not an answer — it is true of every agent. Write _(none)_ if there is no judgment call beyond Behavior. |
| 8 | Success Criteria | What good production behavior looks like, independent of current evals: mission-level outcomes, quality standards, escalation quality, accuracy expectations, and examples of success. Rank them when some matter more. |
| 9 | Trade-offs | How to choose when two improvements conflict. Needs three things: hard gates never traded away, a priority order over the rest (quality, latency, cost, reliability), and regressions that are unacceptable even alongside a headline win. "Balance quality and cost" is not an answer. Write _(none)_ if the user cannot rank them. |
| 10 | Constraints | Hard external bounds no change may cross: approved providers/models/regions, data residency and handling, compliance obligations, production cost ceilings and latency SLOs, and changes that need human sign-off. Give the current measured figure next to a ceiling when you know it. Usually organizational, which is why the code cannot supply them. Write _(none)_ if unconstrained. |
| 11 | Evaluation Setup | Current validation setup: how to run it, what datasets/checks it uses, what scorers/metrics measure, pass/fail thresholds, and known coverage gaps relative to the success criteria. If no eval suite exists, say so explicitly. |
| 12 | Metric Semantics | What ambiguous or load-bearing metric and telemetry field names actually mean, and which claims they do not support. Write _(none)_ when every name means exactly what it says. |
| 13 | Change Scope | A permissions list — what may be modified. Each lever takes yes, no, or with-approval. Name levers that exist on this agent. Do not copy a platform catalog. The loop never edits the Ethos itself. |
| 14 | Vision | Where the agent is headed: an intention beyond today's job, plus one or two concrete use cases it should grow into but does not serve yet. That last part marks what Scope excludes for now rather than on principle. Write _(none)_ rather than pasting a dated backlog. |
| 15 | Open Questions | Open facts that affect safe use, evaluation, or modification of the agent. Write _(none)_ when there are none. Remove items once answered. |
Known issues / failure patterns are tracked as first-class Insight entities by the insights plugin — do not duplicate them into the Ethos.
Check whether an Ethos already exists for this agent. If agents/<name>-ethos/ETHOS.md
is present, ask the user whether they want to edit the existing Ethos or start
over. If they want to edit, route to nemo-ethos directly.
ls agents/*-ethos/ETHOS.md 2>/dev/null || echo "no ethos yet"
If agents/<name>-spec/AGENT-SPEC.md exists, the agent still has a spec
package. Read that file as prior answers. Scan the codebase, then still run
the intent interview for anything the spec never answered. Hand those
answers to nemo-ethos so it writes agents/<name>-ethos/ETHOS.md.
ls agents/*-spec/AGENT-SPEC.md 2>/dev/null && echo "spec package present"
After the Ethos is uploaded and the user confirms it, copy remaining package
files such as agent.yaml into agents/<name>-ethos/. Do that when those
files still live only in the spec package. Confirm, then delete
agents/<name>-spec/ and the <name>-spec Fileset:
nemo files filesets delete "${NAME}-spec"
Do not start a greenfield explore unless the spec is missing answers you still need.
Time-box this to ~5 minutes of tool use. Read first, ask second. Greenfield projects will turn up nothing here, which is fine — move to the intent interview and ask for Role first.
Find agent definitions and entry points. Look for Platform
agent.yaml, NAT workflow YAMLs, Python agent builders, system prompts,
skills, and tool definitions:
find . -maxdepth 5 -type f -name "agent.yaml" 2>/dev/null
find . -maxdepth 4 -type f \( -name "*.workflow.yaml" -o -name "*.workflow.yml" \) 2>/dev/null
find . -maxdepth 4 -type d -name "agents" 2>/dev/null
Then use Glob / Grep to find nemo-agents-spec-v1,
langgraph, StateGraph, create_react_agent, system_prompt, skills,
MCP servers, and tool definitions. Treat any harness or framework name you
find as a clue about how the agent runs, not as a value the Ethos must pick.
Find design context. Look for README.md, AGENTS.md,
product/design/planning docs, launch notes, and anything in docs/. Read
docs that describe goals and user value before implementation details when
they look agent-relevant.
Map findings to schema fields. As you scan, hold a running mental table of what you can fill from the code/docs. Be honest about confidence: "inferred from system prompt" is different from "confirmed by the user."
Choose the model. Hand off to nemo-model-selection after the
code/docs scan. That skill profiles the agent on tool density, primary
capability, and deployment, then recommends a specific NIM model with a
plain-English explanation grounded in what the model is actually good at.
Return here with the chosen model string, which nemo-build-agent writes
into agent.yaml. The Ethos has no Model section — record the permitted
providers and model families in Constraints instead, since the config
already carries the model in use and it changes without touching the Ethos.
If the user wants to skip the conversation, the default is cloud,
nvidia/llama-3.3-nemotron-super-49b-v1 — announce that and move on.
Local NIMs require host-gpu mode.
Typical inferences per field:
@tool decorators, NAT tool registry,
create_react_agent(tools=[...]), retrieval/corpus config, or API clients.
Group low-level helpers when they share credentials, side effects,
freshness, and failure modes._(none)_._(none)_ when every name is
obvious._(none)_ rather than guessing.The scan told you what the agent is. It cannot tell you what the developer wants. Run a real interview for that intent before you show a draft Ethos.
This step is a hard gate. Do not present the full draft, and do not hand off
to nemo-ethos, until you have asked at least three questions and received a
reply to each. "The scan filled everything" and "asking feels unnecessary"
are not reasons to skip it.
After the scan, split fields into two piles:
Tools, Harness, Evaluation Setup, Behavior copied from prompts,
Metric Semantics from scorer names.Purpose & Outcomes, Principles,
and Vision always; then Constraints, Trade-offs, Change Scope, and
a ranked Success Criteria when the repo only has eval wiring.Walk the intent pile. Skip a topic only when this conversation already
answered it. A README, prompt, or roadmap is not a substitute for a user
reply on the always-ask topics below. Keep every other unanswered intent
topic on the list. Greenfield work adds Role, Scope, and whether the
agent is prompt-only before that intent list.
Question count is at least three, then however many remaining intent topics still need a reply. Prefer fewer sharp questions over a long checklist, but never go below three.
Code and docs can look like they already answered them. They did not, until the user says so. Ask even when you have a high-confidence draft. Confirming an inference counts; silently filling the section does not.
Purpose & Outcomes (business objective). Confirm the mission and the
result the agent is accountable for. If you inferred a metric from a
README, show it and ask whether that is the target.Principles. The judgment call when Behavior runs out. Reject
generic virtues. Ask what this agent should do that a careless version
of it would not.Vision. Where the agent is headed, or an explicit _(none)_. Do
not copy a future-work section into Vision without asking. Speculative
vision is the usual failure.If Role is missing or vague, ask that first so the rest of the interview
is grounded. It does not replace one of the three always-ask topics.
Ask about remaining topics in this order, skipping any this conversation already answered:
Constraints — hard bounds no change may cross.Trade-offs — hard gates, then a ranking.Change Scope — which levers on this agent may move.Success Criteria when the repo only has eval wiring.Do not collect run limits. A per-experiment spend cap belongs to the optimizer. If the user volunteers one, keep the standing policy and drop the number.
Follow this Q&A pattern:
Something else or I don't know). Open-ended is fine when a lettered list would fake certainty._(none)_ and record the
gap in Open Questions. A fabricated constraint is worse than a missing
one.Purpose & Outcomes, Principles, or Vision, show the draft as an option. Do not
treat that draft as the answer.Example (one message, then stop):
The README says this agent exists to "cut ticket volume." Is that the business objective I should record in
Purpose & Outcomes?A. Yes — ticket volume is the outcome (tell me the target if you have one) B. Close, but the real objective is … (tell me) C. No business metric — internal tooling D. I don't know
A later Constraints example:
The scan shows a pinned NVIDIA gateway and no cost ceiling in docs.
Which hard bounds should
Constraintsrecord?A. Keep the gateway pin; no other bounds B. Gateway pin plus a production cost or latency ceiling (tell me the number) C. No hard bounds — write
_(none)_D. Something else
Reject generic virtues for Principles. "Helpful, harmless, and honest"
gives a downstream reader nothing. Ask for the judgment call: what does
this agent do that a careless version of it would not? If nothing comes
back, write _(none)_.
Push once on a non-answer for Trade-offs. "Balance quality and cost" is
not decidable. One concrete follow-up usually produces a ranking. If it
does not, record the ambiguity and move on.
If the user provides outside context, read it and update the inferred draft before the next question.
These mean you skipped the interview:
Purpose & Outcomes, Principles, or Vision from the scan
without a user replynemo-ethos with fewer than three Q&A replies in this
conversation| Excuse | Reality |
|---|---|
| The scan filled everything | Code never owns intent. Ask at least three questions. |
| I already know Purpose / Principles / Vision | Those answers belong to the user. Confirm the draft. |
| Asking feels unnecessary | Unnecessary-looking questions are the ones that catch speculative Vision. |
| Batching questions saves turns | One question gets a real answer. A dump gets shallow ones. |
| The draft review can collect intent | Review is for corrections. Ask intent first. |
| The user looks busy | One short multiple-choice question is enough to start. |
After the interview, present the entire Ethos at once — every field, with
inferred values shown inline and remaining gaps as _(none)_. Then ask
one question:
"Here's the full Ethos I'd write. Tell me what to change, and I need a concrete Role before I can hand off to
nemo-ethos."
Show the rendered Ethos inline in markdown (one ## section per field,
same shape as the on-disk file). For fields you defaulted, note the
default in parentheses so the user knows they can override:
Tools: Prompt-only. (default — say so if the agent needs tools)Purpose & Outcomes / Success Criteria inferred from implementation
(say so if there is outside context to incorporate)Change Scope: name the parts of this agent a change may touch
(default — call out anything you want to lock down, or mark it
with-approval)When the user could not answer a section, write _(none)_ and add the
gap to Open Questions. Say "Constraints: (none) — a later optimizer
might treat every provider and cost as fair game" so the consequence is
visible while it is still cheap to fix.
Do not walk the schema field by field in this review. Do not restart the intent interview here unless the reply surfaces a contradiction.
Do not use public-facing shorthand like AUT or "agent under test" in the
rendered Ethos. Use "this agent" for the agent being specified. Use
"target agent" only where the agent's purpose is explicitly to inspect or
modify another agent, and name optimizer helper agents only when they are
part of the actual product workflow.
Allowed follow-ups after the draft:
Role is missing or vague — ask for it before
handoff.After the user's reply, apply the corrections and check the one hard precondition:
If it is still unresolved, ask for it in one final message and stop until the
user provides it. Do not hand off with Role blank — the artifact is useless
downstream even though the parser accepts it.
Every body section heading must be present before handoff. Write _(none)_
for honest gaps, and note them in Open Questions when they affect safe
optimization. Do not drop a heading.
If the Role quality gate is satisfied, announce the handoff in one line
("Handing off to nemo-ethos to write agents/<name>-ethos/ETHOS.md and upload
the canonical copy to Filesets") and trigger it.
Purpose & Outcomes, Principles, and Vision. Treat
skipped topics as I don't know: write _(none)_, record them in
Open Questions, and say once what it costs. Then present the draft. Do
not re-open the full interview.nvidia/llama-3.3-nemotron-super-49b-v1. Tell me
to change if not." Never silently fill in. Prefer routing through
nemo-model-selection so the user gets a plain-English reason, not just a
name.Purpose & Outcomes. A guessed business objective is worse than
_(none)_._(none)_ and record the gap in Open Questions.Purpose & Outcomes,
Principles, and Vision, even when you think you already know. One at
a time. Multiple choice when you can._(none)_.langchain,
langgraph, crewai, autogen, or pydantic_ai say nothing about that.nemo-agent-config owns the
machine-readable Platform YAML after the Ethos is approved.with-approval for levers
the user wants available but not automatic. Do not copy a platform catalog.