/nemotron-add-model

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.md`
• `skills/nemotron-nano3/SKILL.md`
• `skills/nemotron-nano3/INDEX.md`
• `skills/nemotron-nano3/paper/_overview.md`
• `skills/nemotron-nano3/recipes/overview.md`
• `skills/nemotron-nano3/context/index.toml`
• `skills/nemotron-nano3/context/quick-reference.md`
• `skills/nemotron-super3/SKILL.md`
• `skills/nemotron-super3/INDEX.md`
• `.claude-plugin/marketplace.json`

Then ask the contributor: 1. What is the model family name? (slug used in `skills/nemotron-{model}/`, for example `ultra` or `nano4`) 2. What is the tech report URL? (prefer arXiv HTML or another HTML page) 3. Does it have recipes in `src/nemotron/recipes/`? 4. What is the architecture type? (`dense`, `MoE`, `hybrid Mamba-Transformer`, or another precise label) 5. What sizes are available? 6. 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:

• `skills/nemotron-{model}/`

Create these files:

• `skills/nemotron-{model}/SKILL.md`
• `skills/nemotron-{model}/INDEX.md`
• `skills/nemotron-{model}/model-card.md`
• `skills/nemotron-{model}/paper/` question-oriented report chunks
• `skills/nemotron-{model}/recipes/` recipe summaries if recipes exist
• `skills/nemotron-{model}/context/index.toml`
• `skills/nemotron-{model}/context/quick-reference.md`
• `.claude-plugin/marketplace.json` entry for the new skill

Generation rules: 1. Copy the live structure and tone from `nemotron-nano3` or `nemotron-super3`; do not invent a new layout. 2. 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. 3. Base the paper chunks on the HTML report when available. Only fall back to PDF if no HTML source exists. 4. `model-card.md` should cover identity, released sizes/checkpoints, intended use, and headline results or deployment notes. 5. If recipes exist, add `recipes/overview.md` plus one file per public stage or major sub-stage. 6. If recipes do not exist, still create `recipes/overview.md`, but make it explicit that no reproduction recipes are available yet. 7. 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

8. `context/index.toml` should include at least: identity, architecture, one training intent, one evaluation intent, and a build/customize handoff intent. 9. `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. 10. 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/` files
• `context/index.toml` and `context/quick-reference.md` both exist
• `recipes/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: 1. Fix the missing file, frontmatter, or index/reference issue 2. Re-check the specific failure 3. 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-or