| name | nemotron-add-model |
| description | Onboard a new model family (Nemotron or third-party) into skills/ — paper chunks, recipe summaries, context packs, and model card. Use when a contributor wants downstream skills like /nemotron-customize to be able to route to a new model. |
nemotron-add-model
Invocation: /nemotron-add-model.
You help contributors add a new model-family knowledge base to the Nemotron plugin ecosystem without getting the paper chunks, recipe summaries, context pack, or registration wrong.
Tone
Concise. Checklist-first. Ask for missing facts before writing files.
- Status updates: ≤2 lines
- Prefer bullets and tables over long prose
- Say exactly which files you will create or change
- Do not guess model sizes, architecture labels, recipe coverage, or benchmark claims
- Always prefer the tech report HTML page over a PDF when both exist
- Never skip validation
Workflow
Four phases. Always in this order.
1. Orient
Read these first:
skills/nemotron-add-step/SKILL.mdskills/nemotron-nano3/SKILL.mdskills/nemotron-nano3/INDEX.mdskills/nemotron-nano3/paper/_overview.mdskills/nemotron-nano3/recipes/overview.mdskills/nemotron-nano3/context/index.tomlskills/nemotron-nano3/context/quick-reference.mdskills/nemotron-super3/SKILL.mdskills/nemotron-super3/INDEX.md.claude-plugin/marketplace.json
Then ask the contributor:
- What is the model family name? (slug used in
skills/nemotron-{model}/, for example ultra or nano4)
- What is the tech report URL? (prefer arXiv HTML or another HTML page)
- Does it have recipes in
src/nemotron/recipes/?
- What is the architecture type? (
dense, MoE, hybrid Mamba-Transformer, or another precise label)
- What sizes are available?
- Which existing steps support this model? (Do any
step.toml files need new [[models]] entries later?)
Use these repo conventions:
- The skill directory is
skills/nemotron-{model}/.
SKILL.md is a retrieval skill, not a code generator.- Follow the same Locate → Retrieve → Cite pattern used by
nemotron-nano3 and nemotron-super3.
INDEX.md is the knowledge map for the whole skill.paper/*.md files use YAML frontmatter with at least: paper, model, section, paper_sections, title, summary, key_facts, related_steps, currency.- Paper chunks are question-oriented summaries of the report, not raw pasted sections.
recipes/*.md files summarize the public repo path, what it reproduces, what it does not, and include source_path plus a Reproduce with nemotron-customize section.context/index.toml maps intents to the smallest useful file; context/quick-reference.md is the compact handoff sheet.currency is frozen for paper chunks and evolving for recipe summaries.- Adding
[[models]] entries to step manifests is a separate task. Do not modify step manifests here.
2. Generate
Create the skill directory:
Create these files:
skills/nemotron-{model}/SKILL.mdskills/nemotron-{model}/INDEX.mdskills/nemotron-{model}/model-card.mdskills/nemotron-{model}/paper/ question-oriented report chunksskills/nemotron-{model}/recipes/ recipe summaries if recipes existskills/nemotron-{model}/context/index.tomlskills/nemotron-{model}/context/quick-reference.md.claude-plugin/marketplace.json entry for the new skill
Generation rules:
- Copy the live structure and tone from
nemotron-nano3 or nemotron-super3; do not invent a new layout.
- Start
paper/ with _overview.md, then split the rest by question type: architecture, data, pretraining, SFT, RL, evaluation, safety, quantization, or another report-faithful grouping.
- Base the paper chunks on the HTML report when available. Only fall back to PDF if no HTML source exists.
model-card.md should cover identity, released sizes/checkpoints, intended use, and headline results or deployment notes.- If recipes exist, add
recipes/overview.md plus one file per public stage or major sub-stage.
- If recipes do not exist, still create
recipes/overview.md, but make it explicit that no reproduction recipes are available yet.
- Each recipe summary should include:
source_path- what the repo exposes today
- what it does not reproduce from the paper
- a
## Reproduce with nemotron-customize section
context/index.toml should include at least: identity, architecture, one training intent, one evaluation intent, and a build/customize handoff intent.context/quick-reference.md should include model identity, sizes, architecture, public checkpoints, recipe map, and a /nemotron-customize step map or Explorer-mode fallback notes.- Register the new skill in
.claude-plugin/marketplace.json.
3. Validate
Check all of these before finishing:
- Every
paper/*.md file has valid YAML frontmatter
- Every paper chunk sets
currency: "frozen"
INDEX.md references all paper/ and recipes/ filescontext/index.toml and context/quick-reference.md both existrecipes/overview.md exists even if no recipes are available- If recipe stage files exist, each one includes
source_path and Reproduce with nemotron-customize
.claude-plugin/marketplace.json is valid JSON
If validation fails:
- Fix the missing file, frontmatter, or index/reference issue
- Re-check the specific failure
- Do not present the result until the knowledge base is internally consistent
4. Summarize
Show:
- What was created
- Every file added or changed
- Whether recipe summaries were created or intentionally kept minimal
- Which paper chunks were added
- The new marketplace entry name and description
- Any follow-up work deferred, such as future
[[models]] entries in step manifests
Boundaries
Do
- Reuse the live Nano3/Super3 knowledge-base structure
- Prefer HTML report sources
- Keep paper chunks question-oriented and recipe summaries repo-oriented
- Create the context pack files every time
- Register the new skill in the marketplace metadata
Don’t
- Don’t modify existing model skills just to normalize wording
- Don’t modify
step.toml files here
- Don’t invent benchmark numbers, checkpoints, or unsupported recipe stages
- Don’t skip
recipes/overview.md when recipes are missing
- Don’t blur paper claims and public recipe behavior
- Don’t use the PDF when a good HTML source exists
When Stuck
- If the model slug is unclear, stop and ask what the invocation should be.
- If the report has no obvious section structure, chunk by user question type rather than mirroring section numbers mechanically.
- If recipe coverage is partial, document the real public stages and say what is missing.
- If step support is unclear, list the likely step ids in
quick-reference.md but leave step.toml edits for a separate task.
- If the only source is a PDF, confirm that no HTML version exists before using it.
- After two failed validation loops, stop and report the exact file inconsistency.
Calibration Examples
Example 1 — model with recipes
User:
Add a new model-family knowledge base for Nano4. It has an arXiv HTML report and public recipes under src/nemotron/recipes/nano4/.
Assistant:
I’ll confirm the model slug, report URL, architecture type, released sizes, and which existing steps already support Nano4.
Then I’ll create:
skills/nemotron-nano4/SKILL.mdskills/nemotron-nano4/INDEX.mdskills/nemotron-nano4/model-card.mdskills/nemotron-nano4/paper/*.mdskills/nemotron-nano4/recipes/overview.md plus stage summariesskills/nemotron-nano4/context/index.tomlskills/nemotron-nano4/context/quick-reference.md- a marketplace entry
I’ll keep paper chunks frozen, recipe summaries evolving, and I will not edit any step.toml files in this task.
Example 2 — model without recipes
User:
Add a paper-only knowledge base for Ultra. There is no public src/nemotron/recipes/ultra/ directory yet.
Assistant:
I’ll still build the full knowledge base shell, but recipes/ will stay minimal.
I’ll create:
skills/nemotron-ultra/SKILL.mdskills/nemotron-ultra/INDEX.mdskills/nemotron-ultra/model-card.mdskills/nemotron-ultra/paper/*.mdskills/nemotron-ultra/recipes/overview.md stating that no reproduction recipes are available yetskills/nemotron-ultra/context/index.tomlskills/nemotron-ultra/context/quick-reference.md- a marketplace entry
I will not invent stage summaries or pretend the paper is already reproducible from the public repo.
