[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSS9WSKSCM06EVP9MMBQTM":3,"skill-same:01M7CSS9WSKSCM06EVP9MMBQTM":195},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":39,"updatedAt":40,"install":41,"resources":54},"01M7CSS9WSKSCM06EVP9MMBQTM","nemotron-customize",null,"Plan, configure, and chain repo-native Nemotron customization steps into single-step or multi-step pipelines: curation, translation, SFT\u002FPEFT (AutoModel or Megatron-Bridge), pretraining\u002FCPT, RL alignment (DPO\u002FRLVR\u002FGRPO\u002FRLHF), BYOB\u002FMCQ benchmarks, checkpoint conversion, ModelOpt optimization, env profiles, and evaluation of trained checkpoints or existing\u002Fhosted endpoints. Use when a request names a Nemotron step or workflow, or asks to clean, translate, train, fine-tune, align, convert, optimize, evaluate, or compose these into a pipeline. Do NOT use for frontend\u002Fdashboard\u002Fvisualization work, generic ML advice, billing\u002Faccess, or non-Nemotron coding tasks.","YYC-Cube\u002FYYC3-Knowledge-Base","YYC-Cube","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235006543?v=4","01M79J2PH4SWD2X0825X6PN748","yyc3","01M79J2PHVK3F6ZBYT8K2SCZCW",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: nemotron-customize\ndescription: \"Plan, configure, and chain repo-native Nemotron customization steps into single-step or multi-step pipelines: curation, translation, SFT\u002FPEFT (AutoModel or Megatron-Bridge), pretraining\u002FCPT, RL alignment (DPO\u002FRLVR\u002FGRPO\u002FRLHF), BYOB\u002FMCQ benchmarks, checkpoint conversion, ModelOpt optimization, env profiles, and evaluation of trained checkpoints or existing\u002Fhosted endpoints. Use when a request names a Nemotron step or workflow, or asks to clean, translate, train, fine-tune, align, convert, optimize, evaluate, or compose these into a pipeline. Do NOT use for frontend\u002Fdashboard\u002Fvisualization work, generic ML advice, billing\u002Faccess, or non-Nemotron coding tasks.\"\nversion: 0.1.1\nlicense: Apache-2.0\nmetadata:\n  version: 0.1.1\n  author: NVIDIA Nemotron Team \u003Cnoreply@nvidia.com>\n  tags:\n    - nemotron\n    - customization\n    - training\n    - pipelines\n---\n\n# nemotron-customize\n\nIMPORTANT: Read this file before answering any `nemotron-customize`,\nNemotron customization, Curator curation, translation, SFT, PEFT, RL,\nconversion, optimization, checkpoint or existing\u002Fhosted-endpoint evaluation, or\nmulti-step pipeline request. This applies whether the user names one step or\nasks you to compose several steps into a pipeline.\n\nEvaluation requests count even when no training is involved: \"evaluate\",\n\"benchmark\", \"smoke test\", or \"score\" an existing\u002Fhosted endpoint, an API\u002Fmodel\nID, or a deployed model all route to `eval\u002Fmodel_eval`. Read this skill for\nthose too.\n\n## Purpose\n\nTurn a model-customization request into a repo-native Nemotron step pipeline.\nPlan the DAG, validate artifact wiring, and create only the YAML\u002Fconfig files\nneeded to run existing steps.\n\nUse this skill only for inspecting, configuring, validating, running, or\nsubmitting existing Nemotron steps or multi-step training\u002Fcustomization\npipelines. For frontend, dashboard, visualization, generic ML advice,\nbilling\u002Faccess, or unrelated coding tasks, stop with a short scope note and do\nnot inspect the step catalog or edit files in that turn.\n\n## Prerequisites\n\n- A checkout of the Nemotron repo with `src\u002Fnemotron\u002Fsteps\u002F` present; run from\n  the repo root.\n- `uv` available to invoke `uv run nemotron steps ...`.\n- For remote execution: an env profile TOML (`NEMOTRON_ENV_FILE` or\n  `env*.toml`) with a section matching the selected step.\n- For hosted services (translation, hosted eval): the auth environment variable\n  expected by the step (for example `NVIDIA_API_KEY`), exported in the\n  environment — never inlined or committed.\n- User-provided concrete values (model\u002Fcheckpoint, data paths, output dir,\n  hardware\u002FGPU count) before any command is presented as runnable.\n\n## Limitations\n\n- Does not invent new catalog steps. When no existing step, runner, recipe, CLI,\n  or config can satisfy the request, it names the gap (Explorer mode) instead of\n  fabricating a step.\n- Produces YAML\u002Fconfig for existing steps; new Python\u002Fshell is out of scope\n  except in Explorer mode after the gap is approved.\n- Not for deployment-only\u002Fserving, frontend, dashboards, generic ML advice, or\n  non-Nemotron tasks.\n- Does not guess concrete values (paths, model IDs, GPU counts, profiles); it\n  asks or returns `Blocked` when they are missing.\n\n## Core Rule\n\nUse bundled references first. The `references\u002F` folder is the first decision\nsurface for routing, artifacts, patterns, hardware heuristics, and command\nshape. Use `src\u002Fnemotron\u002Fsteps\u002F...` only as a live verification\u002Ffallback source\nwhen you need exact current config fields, manifests, runner imports, or details\nmissing from bundled references.\n\nIf sources disagree:\n\n1. Checked live repo files win for exact execution.\n2. Bundled references win for initial routing and planning.\n3. Upstream docs\u002Fcontext packs are used only for exceptional code generation\n   or library API details.\n\n## Before You Begin\n\n- Read this `SKILL.md` workflow and the relevant bundled reference before\n  opening repo source files.\n- Route from `references\u002FCATALOG.md` and `references\u002FARTIFACTS.md` before any\n  broad repo exploration. Once a route is determined, verify only the selected\n  live step\u002Fconfig\u002Fenv files needed for the answer.\n- Do not emit commands with fake paths, placeholder model IDs, guessed task IDs,\n  guessed batch profiles, or default auth variable names presented as facts.\n  Ask for missing concrete values or return a `Blocked` handoff.\n- Use `references\u002FCOMMANDS.md` as the authoritative checklist before\n  finalizing configs or execution commands.\n- For pipeline requests, plan before editing. Do not create or modify files\n  until the DAG, artifact edges, required inputs, and validation checks are\n  stated and approved.\n- For one-shot command requests, prefer a complete parameterized command in one\n  response over exploratory prose, but only after required inputs are known.\n  If the user already provides the needed values and asks for only a command,\n  answer with the command first and keep explanation minimal.\n- Output discipline (keeps responses tight): emit one command block per step,\n  include only flags the step actually defines, and add no speculative or\n  invented flags. Keep narrative to a few lines — the command plus the required\n  safety\u002Fprofile callouts, not a tutorial. Do not restate reference content the\n  user did not ask for.\n- Do not spawn subagents for one-shot command lookup. Use the bundled command\n  reference directly; verify only the selected step if needed.\n\n## Safety\n\nKeep Bash scoped to repo-safe commands such as `uv run nemotron steps ...`,\ntargeted tests, `git status\u002Fdiff`, and config validation. Never run environment\ndumps (`env`, `printenv`, broad `export`) or commands that expose secret values.\nFor remote submissions, destructive changes, or expensive launches, confirm\nbefore execution.\n\nWhen inspecting env\u002Fconfig files, avoid printing whole files that may contain\nsecrets. Use targeted reads, report only section names and env-var names, and\nredact values for fields containing `token`, `key`, `secret`, `password`,\n`credential`, or `auth`.\n\n## Reference Map\n\n| Question | Read first | Live fallback \u002F verification |\n|---|---|---|\n| Which step or category fits? | `references\u002FCATALOG.md` | `uv run nemotron steps list\u002Fshow`, then selected `step.toml` |\n| Do artifacts chain? | `references\u002FARTIFACTS.md` | `src\u002Fnemotron\u002Fsteps\u002Ftypes.toml` |\n| What run shape should I emit? | `references\u002FCOMMANDS.md` | checked-in config YAML plus active profile TOML |\n| Remote profile generation or selection | `references\u002FCOMMANDS.md` | active `NEMOTRON_ENV_FILE`, `env.toml`, or `env.*.toml` |\n| What hardware\u002Fbackend should I recommend? | `references\u002FHARDWARE.md` | selected step `[[models]]` and `[[strategies]]` |\n| Which cross-step guardrails apply? | `references\u002FPATTERNS.md` | `src\u002Fnemotron\u002Fsteps\u002Fpatterns\u002F\u003Cid>.md` |\n| How do I run the full workflow? | `references\u002FWORKFLOW.md` | selected step configs, `step.py`, and runners |\n| Which upstream library API should generated code use? | `references\u002Fcontext\u002Findex.toml` -> matching pack | selected `step.py`, `_runners\u002F`, upstream docs |\n| New project scaffold, only when existing repo code cannot support the request | `references\u002Fact\u002FPROJECT.md` | existing repo project\u002Frecipe shape |\n| Per-stage code rules, only when existing repo code cannot support the request | `references\u002Fact\u002FSTAGE.md` | selected `step.py` and shared runner |\n\nDo not start by reading category READMEs or `step.toml` for ordinary decisions.\nSelect candidates from bundled references, then verify exact live details before\nwriting configs or final commands.\n\n## Routing\n\nUse `references\u002FCATALOG.md` as the authoritative home for step selection and\nroute-specific fast paths. Use `ARTIFACTS.md`, `PATTERNS.md`, and `HARDWARE.md`\nonly to resolve artifact, cross-step, or hardware constraints after the catalog\nnarrows the route.\n\nEach step is independent and stitching steps together is your job. Compose any\npipeline by artifact matching from the user's end goal: chain a step only when\nthe next step consumes an artifact type nothing upstream already produces. Do\nnot rely on fixed, named step combinations.\n\n## Instructions\n\nFollow the flow that matches the request: a recommendation\u002Fplan, a single-step\ncommand, or a multi-step pipeline. In all cases, route from the bundled\nreferences first, gather required inputs, and verify the selected live step\nbefore presenting anything as runnable.\n\n### Recommendation Response\n\nUse this shape for planning answers:\n\n`Decision`, `Why`, `Required inputs`, `Config\u002Fcommand`, `Avoid`, and `Next step`.\nCall out the stack to avoid when the user's constraints make it a poor fit.\n\nWhenever the answer includes a command that touches a hosted service or remote\nexecution, also state, in the answer:\n\n- The auth env-var name and that its value must be exported in the environment,\n  never inlined or committed (never print the value).\n- For `--batch`\u002F`--run`, the env TOML profile prerequisite; if no profile\n  exists, mark the command `Blocked` or give the local `--dry-run` shape.\n\n### Single-Step Command Flow\n\n1. Confirm repo root has `pyproject.toml` and `src\u002Fnemotron\u002Fsteps\u002F`.\n2. Read `references\u002FCATALOG.md` and the selected section of\n   `references\u002FCOMMANDS.md`.\n3. Verify the selected live step with `uv run nemotron steps show \u003Cstep_id>`\n   when available, or the selected `step.toml` when the CLI is unavailable.\n4. Read the requested checked-in config or user overlay before emitting the\n   command.\n5. For remote execution, read `NEMOTRON_ENV_FILE` or repo-root `env*.toml` and\n   pick an actual section whose profile matches the step.\n6. Emit the full command in one reply with the source tier:\n   `Verified`, `Repo-grounded`, `Reference-grounded`, or `Blocked`.\n\nCanonical command shapes live in `references\u002FCOMMANDS.md`.\n\n### Pipeline Workflow\n\nFor pipelines with two or more stages, use **Orient -> Plan -> Act -> Verify**.\nRead `references\u002FWORKFLOW.md` for the phase checklist.\n\n- Orient from bundled references and user constraints.\n- Plan a DAG with artifact types, configs, patterns, and validation checks.\n- Wait for approval before writing configs or code.\n- Act with YAML\u002Fconfig-only changes whenever an existing step can satisfy the\n  request.\n- Verify every generated YAML, artifact edge, command, and README command\n  before reporting completion.\n\n### Catalog Mode\n\nUse when the request maps to existing steps. Fast path:\n\n`references\u002FCATALOG.md` -> `references\u002FARTIFACTS.md` ->\n`references\u002FCOMMANDS.md` -> verify selected live manifest\u002Fconfig\u002Fprofile ->\nadd a new named config under the selected step's `config\u002F` directory.\n\n## Customization Surface\n\n- Always customize through the step catalog under `src\u002Fnemotron\u002Fsteps\u002F`. Never\n  divert to alternate recipe CLIs such as `src\u002Fnemotron\u002Fcli\u002Fcommands\u002Fsuper3\u002F` or\n  `...\u002Fnano3\u002F`, even for Super3\u002FNano3 work. If a request seems to need those,\n  map it back to the equivalent catalog step (e.g. `sft\u002Fmegatron_bridge`).\n- Make customizations as NEW config files inside the selected step's\n  `src\u002Fnemotron\u002Fsteps\u002F\u003Ccat>\u002F\u003Cstep>\u002Fconfig\u002F` directory, for example\n  `src\u002Fnemotron\u002Fsteps\u002Fsft\u002Fmegatron_bridge\u002Fconfig\u002Fmy_super3.yaml`.\n- Never edit the checked-in `default.yaml`, `tiny.yaml`, other shipped configs,\n  `step.toml`, `step.py`, or shared runners. Adding a new config file beside\n  them is the expected and only customization write.\n- Base new configs on the checked-in `default.yaml` schema (read it, copy the\n  needed fields), then override only what the request requires.\n\n### Explorer Mode\n\nUse only after confirming no existing step, runner, recipe, CLI, or YAML config\nsurface can satisfy the request. Full procedure lives in\n`references\u002FWORKFLOW.md`.\n\n## Configuration Alignment\n\nSurface these constraints before commands or config writes:\n\n- SFT packing `pack_size`, Megatron-Bridge `seq_length`, packed sequence size,\n  tokenizer, and chat template must match.\n- Prepared `packed_parquet` and `binidx` are tokenizer-locked; rebuild after\n  tokenizer, chat-template, sequence-length, split, or blend changes.\n- Megatron-Bridge global batch size must be divisible by data-parallel size;\n  start distributed validation with micro batch size 1.\n- TP\u002FPP\u002FCP\u002FEP choices must fit GPU count, memory, topology, and model divisibility.\n- LoRA merge requires the exact base checkpoint\u002Fmodel and tokenizer used during\n  adapter training.\n- Conversion\u002Feval of Megatron checkpoints should point at a concrete `iter_*`\n  checkpoint, not a parent run directory.\n- Hosted eval and translation configs store auth env-var names only, not values.\n\n## Operational Nuances\n\n- Smoke configs (`tiny.yaml`, `tiny_chat.yaml`) are wiring tests, not quality\n  evidence.\n- `${art:...}` references belong in recipe-backed configs; standalone YAML uses\n  plain paths.\n- Keep pretraining `bin\u002Fidx` data and `blend.json` from the same run\u002Frelease.\n- Write customized configs as new files in the step's\n  `src\u002Fnemotron\u002Fsteps\u002F\u003Ccat>\u002F\u003Cstep>\u002Fconfig\u002F` directory; never modify the\n  checked-in `default.yaml` or other shipped configs.\n- For LoRA, preserve the exact base checkpoint and tokenizer\u002Ftemplate metadata\n  needed by later merge\u002Feval.\n- For translation and hosted eval, mention auth environment variable names only,\n  never values.\n\n## Boundaries\n\nDo:\n\n- Always route through the step catalog under `src\u002Fnemotron\u002Fsteps\u002F`; never use\n  alternate recipe CLIs (`src\u002Fnemotron\u002Fcli\u002Fcommands\u002Fsuper3|nano3\u002F...`).\n- Reuse repo CLIs, runners, recipes, steps, and checked-in configs first.\n- Customize by adding a new config under the step's `config\u002F` directory; base it\n  on `default.yaml` rather than copying it blindly.\n- Validate artifact edges and cite patterns that changed the plan.\n- Ask about hardware\u002Fdata\u002Fbackend\u002Foutput path when missing.\n- Surface tradeoffs such as AutoModel vs Megatron-Bridge and full SFT vs LoRA.\n\nDo not:\n\n- Invent steps when a catalog step fits.\n- Skip Plan for pipelines with two or more stages.\n- Generate Python or shell when YAML is enough.\n- Add monitoring\u002FW&B unless asked.\n- Assume GPU count, env profile, endpoint type, task ID, or auth value.\n- Generate Slurm\u002FAirflow\u002FKubeflow wrappers unless the request explicitly needs\n  deployment scaffolding.\n- Edit checked-in step files (`default.yaml`\u002F`tiny.yaml`, other shipped configs,\n  `step.toml`, `step.py`, runners); only add a new config beside them.\n- Restate all per-step rules in `SKILL.md`; use bundled references and source\n  fallback.\n\n## Examples\n\n**Single-step routing (LoRA on a small box).** User: \"LoRA fine-tune a HF model\non 2 GPUs.\" Route per `CATALOG.md` -> `peft\u002Fautomodel` (HF base + small GPU\ncount); do not offer Megatron-Bridge. Collect base model, JSONL data path,\noutput dir, LoRA rank\u002Falpha, then emit one `uv run nemotron steps run\npeft\u002Fautomodel -c \u003Cconfig> --dry-run ...` command.\n\n**Multi-step pipeline (Super3 SFT).** User: \"data prep + SFT for Super3.\" This is\ntwo stages, so plan first: SFT on Super3 -> Megatron-Bridge, which consumes\n`packed_parquet`, so `data_prep\u002Fsft_packing` is required upstream. Present the\nDAG (`sft_packing -> sft\u002Fmegatron_bridge`), align `pack_size`\u002F`seq_length`\u002F\ntokenizer, wait for approval, then add new configs under\n`src\u002Fnemotron\u002Fsteps\u002F\u003Cstep>\u002Fconfig\u002F\u003Cname>.yaml`. Super3 needs a remote profile;\nstate the env TOML prerequisite or mark `Blocked`.\n\n**Hosted-endpoint evaluation (no training).** User: \"benchmark my hosted model\nendpoint.\" Route to `eval\u002Fmodel_eval` with `-c tiny_chat`. Collect endpoint URL,\nmodel id, task IDs, and the auth env-var name (value exported, never inlined).\nSee `references\u002FCOMMANDS.md` Evaluation Examples.\n\n## Troubleshooting\n\n| Situation | Action |\n|---|---|\n| Artifact types do not chain | Recheck `references\u002FARTIFACTS.md`; insert a converter or change the DAG before writing configs. |\n| Remote profile or `--batch` is unclear | Read active env TOML; do not guess profile names. |\n| Config key is unclear | Verify selected checked-in config, `step.py`, and shared runner before editing. |\n| Strategy points to a missing context pack | Skip the pack, use catalog\u002Fpattern text, and flag the plan with `WARNING: \u003Ctopic> docs unavailable`. |\n| Hardware looks too small | Use `references\u002FHARDWARE.md`; suggest smaller model, AutoModel, then LoRA before full Megatron-Bridge. |\n| Two Act attempts fail | Stop, explain what was tried and failed, and ask how to proceed. |\n| No existing repo path matches | Check `references\u002Fcontext\u002Findex.toml` and selected source fallback; use Explorer mode only after naming the gap. |\n","# nemotron-customize\n\nIMPORTANT: Read this file before answering any `nemotron-customize`,\nNemotron customization, Curator curation, translation, SFT, PEFT, RL,\nconversion, optimization, checkpoint or existing\u002Fhosted-endpoint evaluation, or\nmulti-step pipeline request. This applies whether the user names one step or\nasks you to compose several steps into a pipeline.\n\nEvaluation requests count even when no training is involved: \"evaluate\",\n\"benchmark\", \"smoke test\", or \"score\" an existing\u002Fhosted endpoint, an API\u002Fmodel\nID, or a deployed model all route to `eval\u002Fmodel_eval`. Read this skill for\nthose too.\n\n## Purpose\n\nTurn a model-customization request into a repo-native Nemotron step pipeline.\nPlan the DAG, validate artifact wiring, and create only the YAML\u002Fconfig files\nneeded to run existing steps.\n\nUse this skill only for inspecting, configuring, validating, running, or\nsubmitting existing Nemotron steps or multi-step training\u002Fcustomization\npipelines. For frontend, dashboard, visualization, generic ML advice,\nbilling\u002Faccess, or unrelated coding tasks, stop with a short scope note and do\nnot inspect the step catalog or edit files in that turn.\n\n## Prerequisites\n\n- A checkout of the Nemotron repo with `src\u002Fnemotron\u002Fsteps\u002F` present; run from\n  the repo root.\n- `uv` available to invoke `uv run nemotron steps ...`.\n- For remote execution: an env profile TOML (`NEMOTRON_ENV_FILE` or\n  `env*.toml`) with a section matching the selected step.\n- For hosted services (translation, hosted eval): the auth environment variable\n  expected by the step (for example `NVIDIA_API_KEY`), exported in the\n  environment — never inlined or committed.\n- User-provided concrete values (model\u002Fcheckpoint, data paths, output dir,\n  hardware\u002FGPU count) before any command is presented as runnable.\n\n## Limitations\n\n- Does not invent new catalog steps. When no existing step, runner, recipe, CLI,\n  or config can satisfy the request, it names the gap (Explorer mode) instead of\n  fabricating a step.\n- Produces YAML\u002Fconfig for existing steps; new Python\u002Fshell is out of scope\n  except in Explorer mode after the gap is approved.\n- Not for deployment-only\u002Fserving, frontend, dashboards, generic ML advice, or\n  non-Nemotron tasks.\n- Does not guess concrete values (paths, model IDs, GPU counts, profiles); it\n  asks or returns `Blocked` when they are missing.\n\n## Core Rule\n\nUse bundled references first. The `references\u002F` folder is the first decision\nsurface for routing, artifacts, patterns, hardware heuristics, and command\nshape. Use `src\u002Fnemotron\u002Fsteps\u002F...` only as a live verification\u002Ffallback source\nwhen you need exact current config fields, manifests, runner imports, or details\nmissing from bundled references.\n\nIf sources disagree:\n\n1. Checked live repo files win for exact execution.\n2. Bundled references win for initial routing and planning.\n3. Upstream docs\u002Fcontext packs are used only for exceptional code generation\n   or library API details.\n\n## Before You Begin\n\n- Read this `SKILL.md` workflow and the relevant bundled reference before\n  opening repo source files.\n- Route from `references\u002FCATALOG.md` and `references\u002FARTIFACTS.md` before any\n  broad repo exploration. Once a route is determined, verify only the selected\n  live step\u002Fconfig\u002Fenv files needed for the answer.\n- Do not emit commands with fake paths, placeholder model IDs, guessed task IDs,\n  guessed batch profiles, or default auth variable names presented as facts.\n  Ask for missing concrete values or return a `Blocked` handoff.\n- Use `references\u002FCOMMANDS.md` as the authoritative checklist before\n  finalizing configs or execution commands.\n- For pipeline requests, plan before editing. Do not create or modify files\n  until the DAG, artifact edges, required inputs, and validation checks are\n  stated and approved.\n- For one-shot command requests, prefer a complete parameterized command in one\n  response over exploratory prose, but only after required inputs are known.\n  If the user already provides the needed values and asks for only a command,\n  answer with the command first and keep explanation minimal.\n- Output discipline (keeps responses tight): emit one command block per step,\n  include only flags the step actually defines, and add no speculative or\n  invented flags. Keep narrative to a few lines — the command plus the required\n  safety\u002Fprofile callouts, not a tutorial. Do not restate reference content the\n  user did not ask for.\n- Do not spawn subagents for one-shot command lookup. Use the bundled command\n  reference directly; verify only the selected step if needed.\n\n## Safety\n\nKeep Bash scoped to repo-safe commands such as `uv run nemotron steps ...`,\ntargeted tests, `git status\u002Fdiff`, and config validation. Never run environment\ndumps (`env`, `printenv`, broad `export`) or commands that expose secret values.\nFor remote submissions, destructive changes, or expensive launches, confirm\nbefore execution.\n\nWhen inspecting env\u002Fconfig files, avoid printing whole files that may contain\nsecrets. Use targeted reads, report only section names and env-var names, and\nredact values for fields containing `token`, `key`, `secret`, `password`,\n`credential`, or `auth`.\n\n## Reference Map\n\n| Question | Read first | Live fallback \u002F verification |\n|---|---|---|\n| Which step or category fits? | `references\u002FCATALOG.md` | `uv run nemotron steps list\u002Fshow`, then selected `step.toml` |\n| Do artifacts chain? | `references\u002FARTIFACTS.md` | `src\u002Fnemotron\u002Fsteps\u002Ftypes.toml` |\n| What run shape should I emit? | `references\u002FCOMMANDS.md` | checked-in config YAML plus active profile TOML |\n| Remote profile generation or selection | `references\u002FCOMMANDS.md` | active `NEMOTRON_ENV_FILE`, `env.toml`, or `env.*.toml` |\n| What hardware\u002Fbackend should I recommend? | `references\u002FHARDWARE.md` | selected step `[[models]]` and `[[strategies]]` |\n| Which cross-step guardrails apply? | `references\u002FPATTERNS.md` | `src\u002Fnemotron\u002Fsteps\u002Fpatterns\u002F\u003Cid>.md` |\n| How do I run the full workflow? | `references\u002FWORKFLOW.md` | selected step configs, `step.py`, and runners |\n| Which upstream library API should generated code use? | `references\u002Fcontext\u002Findex.toml` -> matching pack | selected `step.py`, `_runners\u002F`, upstream docs |\n| New project scaffold, only when existing repo code cannot support the request | `references\u002Fact\u002FPROJECT.md` | existing repo project\u002Frecipe shape |\n| Per-stage code rules, only when existing repo code cannot support the request | `references\u002Fact\u002FSTAGE.md` | selected `step.py` and shared runner |\n\nDo not start by reading category READMEs or `step.toml` for ordinary decisions.\nSelect candidates from bundled references, then verify exact live details before\nwriting configs or final commands.\n\n## Routing\n\nUse `references\u002FCATALOG.md` as the authoritative home for step selection and\nroute-specific fast paths. Use `ARTIFACTS.md`, `PATTERNS.md`, and `HARDWARE.md`\nonly to resolve artifact, cross-step, or hardware constraints after the catalog\nnarrows the route.\n\nEach step is independent and stitching steps together is your job. Compose any\npipeline by artifact matching from the user's end goal: chain a step only when\nthe next step consumes an artifact type nothing upstream already produces. Do\nnot rely on fixed, named step combinations.\n\n## Instructions\n\nFollow the flow that matches the request: a recommendation\u002Fplan, a single-step\ncommand, or a multi-step pipeline. In all cases, route from the bundled\nreferences first, gather required inputs, and verify the selected live step\nbefore presenting anything as runnable.\n\n### Recommendation Response\n\nUse this shape for planning answers:\n\n`Decision`, `Why`, `Required inputs`, `Config\u002Fcommand`, `Avoid`, and `Next step`.\nCall out the stack to avoid when the user's constraints make it a poor fit.\n\nWhenever the answer includes a command that touches a hosted service or remote\nexecution, also state, in the answer:\n\n- The auth env-var name and that its value must be exported in the environment,\n  never inlined or committed (never print the value).\n- For `--batch`\u002F`--run`, the env TOML profile prerequisite; if no profile\n  exists, mark the command `Blocked` or give the local `--dry-run` shape.\n\n### Single-Step Command Flow\n\n1. Confirm repo root has `pyproject.toml` and `src\u002Fnemotron\u002Fsteps\u002F`.\n2. Read `references\u002FCATALOG.md` and the selected section of\n   `references\u002FCOMMANDS.md`.\n3. Verify the selected live step with `uv run nemotron steps show \u003Cstep_id>`\n   when available, or the selected `step.toml` when the CLI is unavailable.\n4. Read the requested checked-in config or user overlay before emitting the\n   command.\n5. For remote execution, read `NEMOTRON_ENV_FILE` or repo-root `env*.toml` and\n   pick an actual section whose profile matches the step.\n6. Emit the full command in one reply with the source tier:\n   `Verified`, `Repo-grounded`, `Reference-grounded`, or `Blocked`.\n\nCanonical command shapes live in `references\u002FCOMMANDS.md`.\n\n### Pipeline Workflow\n\nFor pipelines with two or more stages, use **Orient -> Plan -> Act -> Verify**.\nRead `references\u002FWORKFLOW.md` for the phase checklist.\n\n- Orient from bundled references and user constraints.\n- Plan a DAG with artifact types, configs, patterns, and validation checks.\n- Wait for approval before writing configs or code.\n- Act with YAML\u002Fconfig-only changes whenever an existing step can satisfy the\n  request.\n- Verify every generated YAML, artifact edge, command, and README command\n  before reporting completion.\n\n### Catalog Mode\n\nUse when the request maps to existing steps. Fast path:\n\n`references\u002FCATALOG.md` -> `references\u002FARTIFACTS.md` ->\n`references\u002FCOMMANDS.md` -> verify selected live manifest\u002Fconfig\u002Fprofile ->\nadd a new named config under the selected step's `config\u002F` directory.\n\n## Customization Surface\n\n- Always customize through the step catalog under `src\u002Fnemotron\u002Fsteps\u002F`. Never\n  divert to alternate recipe CLIs such as `src\u002Fnemotron\u002Fcli\u002Fcommands\u002Fsuper3\u002F` or\n  `...\u002Fnano3\u002F`, even for Super3\u002FNano3 work. If a request seems to need those,\n  map it back to the equivalent catalog step (e.g. `sft\u002Fmegatron_bridge`).\n- Make customizations as NEW config files inside the selected step's\n  `src\u002Fnemotron\u002Fsteps\u002F\u003Ccat>\u002F\u003Cstep>\u002Fconfig\u002F` directory, for example\n  `src\u002Fnemotron\u002Fsteps\u002Fsft\u002Fmegatron_bridge\u002Fconfig\u002Fmy_super3.yaml`.\n- Never edit the checked-in `default.yaml`, `tiny.yaml`, other shipped configs,\n  `step.toml`, `step.py`, or shared runners. Adding a new config file beside\n  them is the expected and only customization write.\n- Base new configs on the checked-in `default.yaml` schema (read it, copy the\n  needed fields), then override only what the request requires.\n\n### Explorer Mode\n\nUse only after confirming no existing step, runner, recipe, CLI, or YAML config\nsurface can satisfy the request. Full procedure lives in\n`references\u002FWORKFLOW.md`.\n\n## Configuration Alignment\n\nSurface these constraints before commands or config writes:\n\n- SFT packing `pack_size`, Megatron-Bridge `seq_length`, packed sequence size,\n  tokenizer, and chat template must match.\n- Prepared `packed_parquet` and `binidx` are tokenizer-locked; rebuild after\n  tokenizer, chat-template, sequence-length, split, or blend changes.\n- Megatron-Bridge global batch size must be divisible by data-parallel size;\n  start distributed validation with micro batch size 1.\n- TP\u002FPP\u002FCP\u002FEP choices must fit GPU count, memory, topology, and model divisibility.\n- LoRA merge requires the exact base checkpoint\u002Fmodel and tokenizer used during\n  adapter training.\n- Conversion\u002Feval of Megatron checkpoints should point at a concrete `iter_*`\n  checkpoint, not a parent run directory.\n- Hosted eval and translation configs store auth env-var names only, not values.\n\n## Operational Nuances\n\n- Smoke configs (`tiny.yaml`, `tiny_chat.yaml`) are wiring tests, not quality\n  evidence.\n- `${art:...}` references belong in recipe-backed configs; standalone YAML uses\n  plain paths.\n- Keep pretraining `bin\u002Fidx` data and `blend.json` from the same run\u002Frelease.\n- Write customized configs as new files in the step's\n  `src\u002Fnemotron\u002Fsteps\u002F\u003Ccat>\u002F\u003Cstep>\u002Fconfig\u002F` directory; never modify the\n  checked-in `default.yaml` or other shipped configs.\n- For LoRA, preserve the exact base checkpoint and tokenizer\u002Ftemplate metadata\n  needed by later merge\u002Feval.\n- For translation and hosted eval, mention auth environment variable names only,\n  never values.\n\n## Boundaries\n\nDo:\n\n- Always route through the step catalog under `src\u002Fnemotron\u002Fsteps\u002F`; never use\n  alternate recipe CLIs (`src\u002Fnemotron\u002Fcli\u002Fcommands\u002Fsuper3|nano3\u002F...`).\n- Reuse repo CLIs, runners, recipes, steps, and checked-in configs first.\n- Customize by adding a new config under the step's `config\u002F` directory; base it\n  on `default.yaml` rather than copying it blindly.\n- Validate artifact edges and cite patterns that changed the plan.\n- Ask about hardware\u002Fdata\u002Fbackend\u002Foutput path when missing.\n- Surface tradeoffs such as AutoModel vs Megatron-Bridge and full SFT vs LoRA.\n\nDo not:\n\n- Invent steps when a catalog step fits.\n- Skip Plan for pipelines with two or more stages.\n- Generate Python or shell when YAML is enough.\n- Add monitoring\u002FW&B unless asked.\n- Assume GPU count, env profile, endpoint type, task ID, or auth value.\n- Generate Slurm\u002FAirflow\u002FKubeflow wrappers unless the request explicitly needs\n  deployment scaffolding.\n- Edit checked-in step files (`default.yaml`\u002F`tiny.yaml`, other shipped configs,\n  `step.toml`, `step.py`, runners); only add a new config beside them.\n- Restate all per-step rules in `SKILL.md`; use bundled references and source\n  fallback.\n\n## Examples\n\n**Single-step routing (LoRA on a small box).** User: \"LoRA fine-tune a HF model\non 2 GPUs.\" Route per `CATALOG.md` -> `peft\u002Fautomodel` (HF base + small GPU\ncount); do not offer Megatron-Bridge. Collect base model, JSONL data path,\noutput dir, LoRA rank\u002Falpha, then emit one `uv run nemotron steps run\npeft\u002Fautomodel -c \u003Cconfig> --dry-run ...` command.\n\n**Multi-step pipeline (Super3 SFT).** User: \"data prep + SFT for Super3.\" This is\ntwo stages, so plan first: SFT on Super3 -> Megatron-Bridge, which consumes\n`packed_parquet`, so `data_prep\u002Fsft_packing` is required upstream. Present the\nDAG (`sft_packing -> sft\u002Fmegatron_bridge`), align `pack_size`\u002F`seq_length`\u002F\ntokenizer, wait for approval, then add new configs under\n`src\u002Fnemotron\u002Fsteps\u002F\u003Cstep>\u002Fconfig\u002F\u003Cname>.yaml`. Super3 needs a remote profile;\nstate the env TOML prerequisite or mark `Blocked`.\n\n**Hosted-endpoint evaluation (no training).** User: \"benchmark my hosted model\nendpoint.\" Route to `eval\u002Fmodel_eval` with `-c tiny_chat`. Collect endpoint URL,\nmodel id, task IDs, and the auth env-var name (value exported, never inlined).\nSee `references\u002FCOMMANDS.md` Evaluation Examples.\n\n## Troubleshooting\n\n| Situation | Action |\n|---|---|\n| Artifact types do not chain | Recheck `references\u002FARTIFACTS.md`; insert a converter or change the DAG before writing configs. |\n| Remote profile or `--batch` is unclear | Read active env TOML; do not guess profile names. |\n| Config key is unclear | Verify selected checked-in config, `step.py`, and shared runner before editing. |\n| Strategy points to a missing context pack | Skip the pack, use catalog\u002Fpattern text, and flag the plan with `WARNING: \u003Ctopic> docs unavailable`. |\n| Hardware looks too small | Use `references\u002FHARDWARE.md`; suggest smaller model, AutoModel, then LoRA before full Megatron-Bridge. |\n| Two Act attempts fail | Stop, explain what was tried and failed, and ask how to proceed. |\n| No existing repo path matches | Check `references\u002Fcontext\u002Findex.toml` and selected source fallback; use Explorer mode only after naming the gap. |\n",{"name":5,"license":15,"version":24,"metadata":25,"description":7},"0.1.1",{"tags":26,"author":31,"version":24},[27,28,29,30],"nemotron","customization","training","pipelines","NVIDIA Nemotron Team \u003Cnoreply@nvidia.com>","main","87afe6ce96220accf50a345dea46784c8c9f210e","YYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize",0,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base","https:\u002F\u002Fkb.yyc3.top\u002F","https:\u002F\u002Fgithub.com\u002FYYC-Cube","万象归元于云枢 | 深栈智启新纪元","2026-11-10 10:37:32",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemotron-customize",{"tool":47,"command":48},"bunx","bunx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemotron-customize",{"tool":50,"command":51},"pnpm","pnpm dlx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemotron-customize","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002FSKILL.md",true,[55,61,65,69,73,77,81,85,89,93,97,101,105,109,113,117,121,125,129,133,137,141,145,149,153,157,161,165,169,173,177,181,185,189],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},".claude-plugin\u002Fplugin.json","REFERENCE","参考文档",639,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002F.claude-plugin\u002Fplugin.json",{"path":62,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":63,"sourceHtmlUrl":64},"BENCHMARK.md",3742,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002FBENCHMARK.md",{"path":66,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":67,"sourceHtmlUrl":68},"evals\u002Fevals.json",9921,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Fevals\u002Fevals.json",{"path":70,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fact\u002FPROJECT.md",7340,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fact\u002FPROJECT.md",{"path":74,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fact\u002FSTAGE.md",9078,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fact\u002FSTAGE.md",{"path":78,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002FARTIFACTS.md",4959,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FARTIFACTS.md",{"path":82,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002FCATALOG.md",13337,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FCATALOG.md",{"path":86,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002FCOMMANDS.md",9540,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FCOMMANDS.md",{"path":90,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fcontext\u002Fautomodel-launcher-executor-modes.txt",2445,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fautomodel-launcher-executor-modes.txt",{"path":94,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fcontext\u002Fautomodel-pretrain.txt",6146,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fautomodel-pretrain.txt",{"path":98,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fcontext\u002Fautomodel-sft-peft-core.txt",2200,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fautomodel-sft-peft-core.txt",{"path":102,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fcontext\u002Fbyob-benchmark-curator-translation.txt",5026,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fbyob-benchmark-curator-translation.txt",{"path":106,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fcontext\u002Fcheckpoint-conversion.txt",1822,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fcheckpoint-conversion.txt",{"path":110,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fcontext\u002Fcurator-data-acquisition.txt",2356,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fcurator-data-acquisition.txt",{"path":114,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fcontext\u002Fcurator-processing-language-quality.txt",1775,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fcurator-processing-language-quality.txt",{"path":118,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Fcontext\u002Fcurator-translation-faith.txt",4879,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fcurator-translation-faith.txt",{"path":122,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fcontext\u002Fdata-designer-sdg.txt",4711,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fdata-designer-sdg.txt",{"path":126,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Fcontext\u002Feval-deploy-formats.txt",1787,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Feval-deploy-formats.txt",{"path":130,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":131,"sourceHtmlUrl":132},"references\u002Fcontext\u002Feval-sovereign-benchmarks.txt",2090,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Feval-sovereign-benchmarks.txt",{"path":134,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":135,"sourceHtmlUrl":136},"references\u002Fcontext\u002Feval-standard-nlu.txt",1766,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Feval-standard-nlu.txt",{"path":138,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":139,"sourceHtmlUrl":140},"references\u002Fcontext\u002Findex.toml",7566,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Findex.toml",{"path":142,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":143,"sourceHtmlUrl":144},"references\u002Fcontext\u002Fmbridge-parallelism-performance.txt",2038,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fmbridge-parallelism-performance.txt",{"path":146,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":147,"sourceHtmlUrl":148},"references\u002Fcontext\u002Fmbridge-pretrain.txt",1831,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fmbridge-pretrain.txt",{"path":150,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":151,"sourceHtmlUrl":152},"references\u002Fcontext\u002Fmbridge-sft.txt",1883,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fmbridge-sft.txt",{"path":154,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":155,"sourceHtmlUrl":156},"references\u002Fcontext\u002Fmodelopt-optimization.txt",8498,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fmodelopt-optimization.txt",{"path":158,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":159,"sourceHtmlUrl":160},"references\u002Fcontext\u002Fnemo-rl-alignment.txt",5853,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fnemo-rl-alignment.txt",{"path":162,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":163,"sourceHtmlUrl":164},"references\u002Fcontext\u002Fnemotron-data-prep.txt",6203,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002Fnemotron-data-prep.txt",{"path":166,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":167,"sourceHtmlUrl":168},"references\u002Fcontext\u002FREADME.md",1658,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fcontext\u002FREADME.md",{"path":170,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":171,"sourceHtmlUrl":172},"references\u002Fexamples\u002FCALIBRATION.md",2588,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002Fexamples\u002FCALIBRATION.md",{"path":174,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":175,"sourceHtmlUrl":176},"references\u002FHARDWARE.md",3189,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FHARDWARE.md",{"path":178,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":179,"sourceHtmlUrl":180},"references\u002FPATTERNS.md",4080,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FPATTERNS.md",{"path":182,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":183,"sourceHtmlUrl":184},"references\u002FWORKFLOW.md",5307,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Freferences\u002FWORKFLOW.md",{"path":186,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":187,"sourceHtmlUrl":188},"skill-card.md",4187,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Fskill-card.md",{"path":190,"resourceType":191,"resourceTypeDesc":192,"sizeBytes":193,"sourceHtmlUrl":194},"skill.oms.sig","OTHER","其他",12201,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemotron-customize\u002Fskill.oms.sig",[196,204,211,218,225,232],{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":19},"01M7CTDWHERCXPQCP0K03A86AS","vercel-sandbox","Run agent-browser + Chrome inside Vercel Sandbox microVMs for browser automation from any Vercel-deployed app. Use when the user needs browser automation in a Vercel app (Next.js, SvelteKit, Nuxt, Remix, Astro, etc.), wants to run headless Chrome without binary size limits, needs persistent browser sessions across commands, or wants ephemeral isolated browser environments. Triggers include \"Vercel Sandbox browser\", \"microVM Chrome\", \"agent-browser in sandbox\", \"browser automation on Vercel\", or any task requiring Chrome in a Vercel Sandbox.","MIT","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fvercel-sandbox\u002FSKILL.md",[],[],{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"publishedAt":19},"01M7CTD8D2BNJY54S65M47HEJA","slack","Interact with Slack workspaces using browser automation. Use when the user needs to check unread channels, navigate Slack, send messages, extract data, find information, search conversations, or automate any Slack task. Triggers include \"check my Slack\", \"what channels have unreads\", \"send a message to\", \"search Slack for\", \"extract from Slack\", \"find who said\", or any task requiring programmatic Slack interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fslack\u002FSKILL.md",[],[],{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":19},"01M7CTCSSB8ZP3Q58C3YZDZK1W","electron","Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include \"automate Slack app\", \"control VS Code\", \"interact with Discord app\", \"test this Electron app\", \"connect to desktop app\", or any task requiring automation of a native Electron application.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Felectron\u002FSKILL.md",[],[],{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":224,"publishedAt":19},"01M7CTCBJY76688V4DCZGWFHGQ","dogfood","Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app\u002Fsite\u002Fplatform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fdogfood\u002FSKILL.md",[],[],{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":231,"publishedAt":19},"01M7CTC4H0FFGVEAQR9PA4GA1A","agent-browser","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fagent-browser\u002FSKILL.md",[],[],{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":200,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":238,"publishedAt":19},"01M7CTBKVFYBG78FDSABSDJTTQ","shadcn","Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn\u002Fui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for \"shadcn init\", \"create an app with --preset\", \"switch to --preset\", and for building a design system or applying a DESIGN.md or brand spec to shadcn\u002Fui.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-UI-界面组件\u002FYYC3-UI-界面组件-ui\u002Fskills\u002Fshadcn\u002FSKILL.md",[],[]]