[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NTN4JKSW8GMDKERJ3GQKS":3,"skill-same:01M71NTN4JKSW8GMDKERJ3GQKS":112},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":14,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M71NTN4JKSW8GMDKERJ3GQKS","nemo-automodel-model-onboarding",null,"Guide for onboarding new model architectures into NeMo AutoModel, including architecture discovery, implementation patterns, registration, and validation.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"model","NeMo","onboarding","nemo automodel model onboarding","as","capability","guide","face","patterns","mapping","hugging face","registry","flags","dict","Model Architecture","config","support","architecture","files","new","2026-11-10 10:56:23",false,"---\nname: nemo-automodel-model-onboarding\ndescription: Guide for onboarding new model architectures into NeMo AutoModel, including architecture discovery, implementation patterns, registration, and validation.\nwhen_to_use: Adding or modifying model architecture support in NeMo AutoModel, such as LLM\u002FVLM\u002FMoE model files, custom layers, state-dict adapters, registry entries, Hugging Face config mapping, or capability flags.\nlicense: Apache-2.0\nmetadata:\n  author: NVIDIA\n  tags:\n    - nemo-automodel\n    - model-onboarding\n---\n\n# Adding Model Support to NeMo AutoModel\n\n## Purpose\n\nThis skill guides implementation of new model architectures in NeMo AutoModel. Follow the five phases in order.\n\u003C!-- NVSkills signature refresh requested for AM-519. -->\n\n## Instructions\n\nWhen answering an onboarding question, keep the response in this order:\n\n1. Classify the architecture from `config.json`.\n2. Name the exact implementation files under `components\u002Fmodels\u002F\u003Cname>\u002F`.\n3. Identify registry and optional custom-config updates.\n4. State the validation tests that must be added before full checkpoint use.\n\nFor conceptual onboarding questions, answer from this skill without opening the\npattern files unless the user asks you to edit code. Mention pattern filenames\nas references, then give the direct checklist.\n\nUse direct action verbs: classify the model, name the files, map the weights,\nregister the class, and add tests. Do not discuss distributed strategy,\nlauncher configuration, or general recipe authoring unless the user explicitly\nconnects it to onboarding a new architecture.\n\n## Examples\n\nUse these compact answer patterns for common questions:\n\n- Dense causal LM: classify as dense only when `architectures` contains a\n  `ForCausalLM` class and expert fields such as `num_local_experts`,\n  `n_routed_experts`, or `num_experts_per_tok` are absent. Create\n  `components\u002Fmodels\u002F\u003Cname>\u002Fmodel.py`, `state_dict_adapter.py`, `__init__.py`,\n  and optional `config.py`, register `MODEL_ARCH_MAPPING` in\n  `_transformers\u002Fregistry.py`, add example YAML, and add tiny-config unit tests\n  plus layer-equivalence tests for rewritten layers.\n- MoE state dict: identify expert fields in `config.json`, reference\n  `moe-patterns.md`, map router tensors separately, preserve routed-expert\n  index order, map routed experts, shared experts, and gate\u002Fup\u002Fdown projections,\n  add adapter key-map tests and tiny-config numerical equivalence tests, and do\n  not rely only on `from_pretrained()` or silent tensor reshapes.\n- VLM onboarding: classify as VLM only when `vision_config`, `text_config`, and\n  a `ForConditionalGeneration` architecture are present. Reference\n  `vlm-patterns.md` and existing VLM implementations such as `mistral4`,\n  `kimivl`, or `kimi_k25_vl`; check text backbone, vision tower, projector,\n  processor assumptions, text and vision `state_dict_adapter.py` mappings,\n  registry registration, and tiny image-text tests before full checkpoints.\n  Do not treat VLM onboarding as a pure causal-LM path or skip processor\u002Fimage\n  tests.\n\nFor MoE state-dict questions, always include the safety checklist:\n\n- Map router tensors separately from expert tensors.\n- Preserve routed-expert index order; never sort, drop, merge, or silently\n  reshape expert weights to make loading pass.\n- Map gate, up, and down projections explicitly, including combined projection\n  layouts and shared experts when present.\n- Add adapter key-map tests and tiny-config numerical equivalence tests before\n  relying on full checkpoint loading.\n\nFor VLM questions, explicitly check `vision_config`, `text_config`, the\nconditional-generation architecture, text backbone, vision tower, projector,\nprocessor assumptions, registry entry, and tiny image-text tests.\n\n## Routing Boundary\n\nUse this skill only when the user is adding or modifying model architecture support: model files, custom layers, state-dict adapters, Hugging Face config mapping, registry entries, or model capability flags.\n\nDo not use this skill for standalone training recipe YAML questions about optimizers, datasets, schedulers, validation datasets, or trainer wiring unless they are explicitly part of onboarding a new model architecture. Those recipe questions belong to the nemo-automodel-recipe-development skill.\n\nIn-scope examples:\n\n- \"Add support for a new Hugging Face causal LM architecture.\"\n- \"Map MoE router and expert weights from a Hugging Face checkpoint.\"\n- \"Register a new model class in NeMo AutoModel.\"\n\nOut-of-scope examples:\n\n- \"Write a finetuning recipe YAML with optimizer and dataset sections.\"\n- \"Choose FSDP2, DDP, tensor parallel, or context parallel settings.\"\n- \"Configure Slurm, SkyPilot, containers, mounts, or launch dispatch.\"\n\n## Phase 1: Discovery\n\nBefore writing code, gather information about the target model.\n\n### 1.1 Fetch HuggingFace config.json\n\nDownload the model's `config.json` from the HuggingFace Hub (or use `AutoConfig.from_pretrained`). Key fields to extract:\n\n- `architectures` -- determines the class name and registration key (e.g., `\"LlamaForCausalLM\"`, `\"Qwen3MoeForCausalLM\"`, `\"Mistral3ForConditionalGeneration\"`)\n- `model_type` -- used for custom config registration in `_CUSTOM_CONFIG_REGISTRATIONS` if HF does not have a built-in config class\n- `hidden_size`, `intermediate_size`, `num_hidden_layers`, `num_attention_heads`, `num_key_value_heads` -- sizing\n- `vocab_size` -- needed for tiny test configs\n- `tie_word_embeddings` -- whether lm_head shares weights with embed_tokens\n- `hidden_act` -- activation function (e.g., `\"silu\"` for SwiGLU)\n\n### 1.2 Determine model type\n\n| Type | Indicators | Pattern file |\n|------|-----------|-------------|\n| **Dense LLM** | `ForCausalLM` in architectures, no expert fields | [llm-patterns.md](.\u002Fllm-patterns.md) |\n| **MoE LLM** | `n_routed_experts`, `num_local_experts`, `num_experts_per_tok` in config | [moe-patterns.md](.\u002Fmoe-patterns.md) |\n| **VLM** | `ForConditionalGeneration` in architectures, has `vision_config` + `text_config` | [vlm-patterns.md](.\u002Fvlm-patterns.md) |\n\n### 1.3 Check for existing similar architectures\n\nLook in `components\u002Fmodels\u002F` for architectures with similar attention or MLP patterns:\n\n```\ncomponents\u002Fmodels\u002F\n  llama\u002F           # Standard GQA + SwiGLU (CombinedQKV + CombinedGateUpMLP)\n  qwen2\u002F           # Same as Llama but with attention bias + QKV bias\n  baichuan\u002F        # ALiBi attention variant\n  deepseek_v3\u002F     # MLA attention + MoE (DeepSeek-style grouped experts)\n  mistral4\u002F        # MLA + MoE + VLM (Pixtral vision)\n  kimivl\u002F          # DeepSeek-V3 backbone + MoonVit vision\n  kimi_k25_vl\u002F     # Updated KimiVL with different projector\n  qwen3_moe\u002F       # Qwen3 with MoE layers\n  nemotron_v3\u002F     # Hybrid mamba-attention\n```\n\n### 1.4 Identify custom components\n\nCheck whether the model needs:\n\n- **Custom attention**: GQA (standard), MLA (DeepSeek\u002FMistral4), sliding window, bidirectional\n- **Custom RoPE**: Standard (Llama), YaRN scaling, NTK-aware, complex-number (DeepSeek)\n- **Custom normalization**: RMSNorm (standard), LayerNorm, different eps values\n- **Custom MLP**: SwiGLU (standard), GeGLU, ReLU-squared, MoE routing\n- **Custom config class**: Needed only if HF `AutoConfig` cannot parse the model's `config.json` (check `auto_map` field)\n\n### 1.5 Note dimensions for test config\n\nFor unit tests, create a tiny config. Target: ~1M parameters or less.\n\n```python\n# Example tiny config for a Llama-like model:\ntiny_config = LlamaConfig(\n    hidden_size=64,\n    intermediate_size=128,\n    num_hidden_layers=2,\n    num_attention_heads=4,\n    num_key_value_heads=2,\n    vocab_size=256,\n    max_position_embeddings=128,\n)\n```\n\n---\n\n## Phase 2: Implementation\n\n### 2.1 Create directory structure\n\n```\ncomponents\u002Fmodels\u002F\u003Cname>\u002F\n  __init__.py\n  model.py\n  state_dict_adapter.py\n  config.py            # Only if HF config is insufficient\n  layers.py            # Only for MoE \u002F MLA \u002F other non-standard layers\n  rope_utils.py        # Only for custom RoPE\n```\n\n### 2.2 Implementation order\n\nImplement files in dependency order:\n\n1. **config.py** (if needed) -- Custom `PretrainedConfig` subclass\n2. **rope_utils.py** (if needed) -- RoPE implementation\n3. **layers.py** (if needed) -- Attention, MLP, decoder block classes\n4. **model.py** -- The main `ForCausalLM` (or `ForConditionalGeneration`) class\n5. **state_dict_adapter.py** -- HF weight conversion\n6. **__init__.py** -- Re-export the main model class\n\nSee the pattern files for detailed implementation guidance:\n\n- Dense LLM: [llm-patterns.md](.\u002Fllm-patterns.md)\n- MoE: [moe-patterns.md](.\u002Fmoe-patterns.md)\n- VLM: [vlm-patterns.md](.\u002Fvlm-patterns.md)\n- Capabilities and fp32 precision: [capabilities-and-precision.md](.\u002Fcapabilities-and-precision.md)\n\n### 2.3 Causal LM weight tying\n\nFor any CausalLM-style class whose config can enable `tie_word_embeddings`,\nmake tying explicit: declare `_tied_weights_keys`, implement `tie_weights()`\nwith the actual `lm_head` and input-embedding FQNs, and add tiny tests for\ntied and untied configs. Do not tie architectures with intentionally separate\nheads, asymmetric vocab sizes, or stages that do not own both tensors.\n\n### 2.4 MoE state-dict adapter checklist\n\nFor MoE models, do not stop at generic loading. The adapter must explicitly map:\n\n- Router weights, including gate bias or correction-bias tensors when the Hugging Face model has them.\n- Expert weights, preserving expert index order across local and routed experts.\n- Gate\u002Fup\u002Fdown projections, including combined or split projection layouts.\n- Shared experts separately from routed experts when the architecture has both.\n\nAdd tests that assert expected key mappings and run numerical equivalence with tiny configs before trying full checkpoints.\n\nDo not use these shortcuts:\n\n- Do not validate the adapter only by calling `from_pretrained()`.\n- Do not accept missing or extra expert keys without an explicit mapping reason.\n- Do not change dtype, transpose dimensions, or reshape tensors unless the HF\n  and NeMo layouts require it and a test proves the conversion is reversible.\n- Do not skip router or shared-expert tests because dense-layer tests pass.\n\n### 2.5 VLM onboarding checklist\n\nFor VLMs, confirm the Hugging Face config has `vision_config` and `text_config`\nand that `architectures` points to a conditional-generation class. Start from\nthe closest VLM pattern file, usually [vlm-patterns.md](.\u002Fvlm-patterns.md), and\ncompare existing implementations such as `mistral4`, `kimivl`, or\n`kimi_k25_vl`.\n\nThe implementation should explicitly cover:\n\n- Text backbone, vision tower, projector, and processor or image preprocessing assumptions.\n- Weight mapping for both text and vision modules in `state_dict_adapter.py`.\n- Registration of the `ForConditionalGeneration` class in `_transformers\u002Fregistry.py`.\n- Tiny tests that exercise image-text inputs and verify the adapter round-trip.\n\n### 2.6 Register in registry\n\nAdd the model to `MODEL_ARCH_MAPPING` in `_transformers\u002Fregistry.py`:\n\n```python\n# In _transformers\u002Fregistry.py\nMODEL_ARCH_MAPPING = OrderedDict([\n    # ... existing entries ...\n    (\n        \"NewModelForCausalLM\",\n        (\"nemo_automodel.components.models.new_model.model\", \"NewModelForCausalLM\"),\n    ),\n])\n```\n\nIf the model has a custom config class with `auto_map` in its `config.json`, also register in `_CUSTOM_CONFIG_REGISTRATIONS`:\n\n```python\n_CUSTOM_CONFIG_REGISTRATIONS: Dict[str, Tuple[str, str]] = {\n    # ... existing entries ...\n    \"new_model\": (\"nemo_automodel.components.models.new_model.configuration\", \"NewModelConfig\"),\n}\n```\n\n### 2.7 Declare capabilities and precision-sensitive params\n\nEvery class registered in `MODEL_ARCH_MAPPING` must declare parallelism\ncapabilities, either with a static nested `ModelCapabilities` dataclass or a\nvariant-aware `get_capabilities(cls, config)` method. Pick exactly one pattern.\nCapabilities should reflect recipe YAMLs that have been validated end to end.\n\nIf the model has precision-sensitive parameters such as Mamba `A_log` \u002F\n`dt_bias`, MoE sigmoid gate bias, attention-sink bias, or per-head `scale`,\ndeclare `_keep_in_fp32_modules_strict` so sharding keeps those params in fp32\ncompute. See [capabilities-and-precision.md](.\u002Fcapabilities-and-precision.md)\nfor examples, variant dispatch rules, and frozen-submodule dtype guidance.\n\n---\n\n## Phase 3: Onboarding Example Config\n\nThis phase is only for adding a minimal example config that proves the newly\nonboarded architecture can load and run. Use nemo-automodel-recipe-development for general\nrecipe authoring or existing recipe modifications.\n\n### 3.1 Create example YAML config\n\nCreate an example config under `examples\u002Fllm_finetune\u002F\u003Cname>\u002F` (or `examples\u002Fvlm_finetune\u002F\u003Cname>\u002F`):\n\n```yaml\nmodel:\n  _target_: nemo_automodel.NeMoAutoModelForCausalLM.from_pretrained\n  pretrained_model_name_or_path: \u003Corg>\u002F\u003Cmodel-name>\n\ntrainer:\n  max_steps: 100\n  gradient_clip_val: 1.0\n  accumulate_grad_batches: 1\n\n# ... data, optimizer config ...\n```\n\n### 3.2 Verify model loads\n\nTest that the model loads from a HuggingFace checkpoint:\n\n```python\nfrom nemo_automodel import NeMoAutoModelForCausalLM\n\nmodel = NeMoAutoModelForCausalLM.from_pretrained(\"\u003Corg>\u002F\u003Cmodel-name>\")\n```\n\n### 3.3 Test with tiny config first\n\nBefore using full-size models, verify with a tiny config (1-2 layers, small hidden dim) to catch shape mismatches early.\n\n## Phase 4: Tests\n\nCreate `tests\u002Funit_tests\u002Fmodels\u002F\u003Cname>\u002F` and cover the checks below before\nloading full checkpoints:\n\n- Forward-shape smoke test with a tiny config.\n- State-dict adapter round-trip: `from_hf -> to_hf` preserves mapped names,\n  shapes, dtypes, and values.\n- Layer equivalence tests for every rewritten attention, MLP, normalization,\n  RoPE, or MoE layer. Use the model dtype from config, identical seeded weights,\n  identical inputs, and dtype-appropriate `torch.allclose` tolerances.\n- Short functional test that verifies loss decreases over a few training steps.\n\n---\n\n## Phase 5: Documentation\n\n### 5.1 Update model coverage page\n\nEdit the appropriate file in `docs\u002Fmodel-coverage\u002F`:\n- LLM\u002FMoE: `docs\u002Fmodel-coverage\u002Fllm\u002Findex.md`\n- VLM: `docs\u002Fmodel-coverage\u002Fvlm\u002Findex.md`\n\nAdd a row with the model name, supported features (TP, PP, FSDP, LoRA, QLoRA), and any limitations.\n\n---\n\n## Phase 6: Parity Testing\n\nAfter implementation and unit tests are complete, run the full parity-testing\nworkflow to verify that the new model produces numerically equivalent results to\nthe reference HuggingFace implementation.\n\nRun three levels of comparison:\n\n1. State-dict round-trip: load a reference HuggingFace checkpoint, convert it\n   into the NeMo AutoModel layout, export it back, and verify that all mapped\n   tensors match the reference names, shapes, dtypes, and values within the\n   expected tolerance.\n2. Component-level parity: compare rewritten attention, MLP, normalization,\n   RoPE, and MoE components against the HuggingFace implementation with fixed\n   seeds and identical dtype.\n3. End-to-end forward pass: run the full NeMo AutoModel and HuggingFace model\n   on the same tokenized input and compare logits, hidden states, and loss.\n\nDo not skip this phase. A model that passes unit tests can still diverge from HF\ndue to subtle weight-conversion bugs, backend differences, or RoPE mismatches\nthat only surface in a full parity comparison.\n\n---\n\n## Key Files Reference\n\n| File | Purpose |\n|------|---------|\n| `_transformers\u002Fregistry.py` | `MODEL_ARCH_MAPPING` and `_CUSTOM_CONFIG_REGISTRATIONS` |\n| `components\u002Fmodels\u002Fcommon\u002F__init__.py` | Exports `CombinedQKVAttentionMixin`, `CombinedGateUpMLP`, `BackendConfig`, `HFCheckpointingMixin`, etc. |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fcombined_qkv.py` | `CombinedQKVAttentionMixin` with `setup_qkv_projection()` and `compute_qkv()` |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fcombined_mlp.py` | `CombinedGateUpMLP` with interleaved gate\u002Fup layout |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fstate_dict_adapter.py` | `CombinedProjectionStateDictAdapter` base class |\n| `components\u002Fmodels\u002Fcommon\u002Fhf_checkpointing_mixin.py` | `HFCheckpointingMixin` for save\u002Fload |\n| `components\u002Fmodels\u002Fcommon\u002Futils.py` | `BackendConfig`, `initialize_rms_norm_module`, `initialize_linear_module`, `get_rope_config` |\n| `components\u002Fmoe\u002Fconfig.py` | `MoEConfig` dataclass |\n| `components\u002Fmoe\u002Ffsdp_mixin.py` | `MoEFSDPSyncMixin` for distributed expert handling |\n| `components\u002Fmoe\u002Flayers.py` | `MoE` layer, `MLP` (dense) for MoE blocks |\n| `components\u002Fmoe\u002Fexperts.py` | `GroupedExperts`, `GroupedExpertsDeepEP`, `GroupedExpertsTE` |\n\n---\n\n## Checklist\n\n- [ ] Fetched and analyzed `config.json` from HuggingFace\n- [ ] Determined model type (dense LLM \u002F MoE \u002F VLM)\n- [ ] Identified custom components (attention, RoPE, normalization, MLP)\n- [ ] Created `components\u002Fmodels\u002F\u003Cname>\u002F` directory\n- [ ] Implemented config.py (if custom config needed)\n- [ ] Implemented layers.py (if custom layers needed)\n- [ ] Implemented rope_utils.py (if custom RoPE needed)\n- [ ] Implemented model.py with `HFCheckpointingMixin`\n- [ ] Implemented state_dict_adapter.py\n- [ ] Implemented __init__.py with re-export\n- [ ] Registered in `MODEL_ARCH_MAPPING` in `_transformers\u002Fregistry.py`\n- [ ] Registered custom config in `_CUSTOM_CONFIG_REGISTRATIONS` (if applicable)\n- [ ] Declared `ModelCapabilities` nested dataclass (static) OR `get_capabilities(cls, config)` classmethod (variant dispatch, e.g. ERNIE-4.5 MoE vs dense) — never both, never neither\n- [ ] Created example YAML config\n- [ ] Verified model loads via `NeMoAutoModelForCausalLM.from_pretrained()`\n- [ ] Created unit tests (forward shape, state_dict round-trip)\n- [ ] Declared `_keep_in_fp32_modules_strict` for every intrinsically-fp32 param (SSM `A_log`\u002F`dt_bias`, Mamba `D` when reference-fp32, MoE gate bias, attention-sink bias, `scale`, …) — see §2.7\n- [ ] Created layer equivalence tests for every rewritten layer (matching model dtype)\n- [ ] Created functional tests (training loss decreases)\n- [ ] Updated docs\u002Fmodel-coverage page\n- [ ] Ran state-dict round-trip, component parity, and E2E forward-pass parity checks\n- [ ] Set `ModelClass = \u003CName>ForCausalLM` at module bottom\n","# Adding Model Support to NeMo AutoModel\n\n## Purpose\n\nThis skill guides implementation of new model architectures in NeMo AutoModel. Follow the five phases in order.\n\u003C!-- NVSkills signature refresh requested for AM-519. -->\n\n## Instructions\n\nWhen answering an onboarding question, keep the response in this order:\n\n1. Classify the architecture from `config.json`.\n2. Name the exact implementation files under `components\u002Fmodels\u002F\u003Cname>\u002F`.\n3. Identify registry and optional custom-config updates.\n4. State the validation tests that must be added before full checkpoint use.\n\nFor conceptual onboarding questions, answer from this skill without opening the\npattern files unless the user asks you to edit code. Mention pattern filenames\nas references, then give the direct checklist.\n\nUse direct action verbs: classify the model, name the files, map the weights,\nregister the class, and add tests. Do not discuss distributed strategy,\nlauncher configuration, or general recipe authoring unless the user explicitly\nconnects it to onboarding a new architecture.\n\n## Examples\n\nUse these compact answer patterns for common questions:\n\n- Dense causal LM: classify as dense only when `architectures` contains a\n  `ForCausalLM` class and expert fields such as `num_local_experts`,\n  `n_routed_experts`, or `num_experts_per_tok` are absent. Create\n  `components\u002Fmodels\u002F\u003Cname>\u002Fmodel.py`, `state_dict_adapter.py`, `__init__.py`,\n  and optional `config.py`, register `MODEL_ARCH_MAPPING` in\n  `_transformers\u002Fregistry.py`, add example YAML, and add tiny-config unit tests\n  plus layer-equivalence tests for rewritten layers.\n- MoE state dict: identify expert fields in `config.json`, reference\n  `moe-patterns.md`, map router tensors separately, preserve routed-expert\n  index order, map routed experts, shared experts, and gate\u002Fup\u002Fdown projections,\n  add adapter key-map tests and tiny-config numerical equivalence tests, and do\n  not rely only on `from_pretrained()` or silent tensor reshapes.\n- VLM onboarding: classify as VLM only when `vision_config`, `text_config`, and\n  a `ForConditionalGeneration` architecture are present. Reference\n  `vlm-patterns.md` and existing VLM implementations such as `mistral4`,\n  `kimivl`, or `kimi_k25_vl`; check text backbone, vision tower, projector,\n  processor assumptions, text and vision `state_dict_adapter.py` mappings,\n  registry registration, and tiny image-text tests before full checkpoints.\n  Do not treat VLM onboarding as a pure causal-LM path or skip processor\u002Fimage\n  tests.\n\nFor MoE state-dict questions, always include the safety checklist:\n\n- Map router tensors separately from expert tensors.\n- Preserve routed-expert index order; never sort, drop, merge, or silently\n  reshape expert weights to make loading pass.\n- Map gate, up, and down projections explicitly, including combined projection\n  layouts and shared experts when present.\n- Add adapter key-map tests and tiny-config numerical equivalence tests before\n  relying on full checkpoint loading.\n\nFor VLM questions, explicitly check `vision_config`, `text_config`, the\nconditional-generation architecture, text backbone, vision tower, projector,\nprocessor assumptions, registry entry, and tiny image-text tests.\n\n## Routing Boundary\n\nUse this skill only when the user is adding or modifying model architecture support: model files, custom layers, state-dict adapters, Hugging Face config mapping, registry entries, or model capability flags.\n\nDo not use this skill for standalone training recipe YAML questions about optimizers, datasets, schedulers, validation datasets, or trainer wiring unless they are explicitly part of onboarding a new model architecture. Those recipe questions belong to the nemo-automodel-recipe-development skill.\n\nIn-scope examples:\n\n- \"Add support for a new Hugging Face causal LM architecture.\"\n- \"Map MoE router and expert weights from a Hugging Face checkpoint.\"\n- \"Register a new model class in NeMo AutoModel.\"\n\nOut-of-scope examples:\n\n- \"Write a finetuning recipe YAML with optimizer and dataset sections.\"\n- \"Choose FSDP2, DDP, tensor parallel, or context parallel settings.\"\n- \"Configure Slurm, SkyPilot, containers, mounts, or launch dispatch.\"\n\n## Phase 1: Discovery\n\nBefore writing code, gather information about the target model.\n\n### 1.1 Fetch HuggingFace config.json\n\nDownload the model's `config.json` from the HuggingFace Hub (or use `AutoConfig.from_pretrained`). Key fields to extract:\n\n- `architectures` -- determines the class name and registration key (e.g., `\"LlamaForCausalLM\"`, `\"Qwen3MoeForCausalLM\"`, `\"Mistral3ForConditionalGeneration\"`)\n- `model_type` -- used for custom config registration in `_CUSTOM_CONFIG_REGISTRATIONS` if HF does not have a built-in config class\n- `hidden_size`, `intermediate_size`, `num_hidden_layers`, `num_attention_heads`, `num_key_value_heads` -- sizing\n- `vocab_size` -- needed for tiny test configs\n- `tie_word_embeddings` -- whether lm_head shares weights with embed_tokens\n- `hidden_act` -- activation function (e.g., `\"silu\"` for SwiGLU)\n\n### 1.2 Determine model type\n\n| Type | Indicators | Pattern file |\n|------|-----------|-------------|\n| **Dense LLM** | `ForCausalLM` in architectures, no expert fields | [llm-patterns.md](.\u002Fllm-patterns.md) |\n| **MoE LLM** | `n_routed_experts`, `num_local_experts`, `num_experts_per_tok` in config | [moe-patterns.md](.\u002Fmoe-patterns.md) |\n| **VLM** | `ForConditionalGeneration` in architectures, has `vision_config` + `text_config` | [vlm-patterns.md](.\u002Fvlm-patterns.md) |\n\n### 1.3 Check for existing similar architectures\n\nLook in `components\u002Fmodels\u002F` for architectures with similar attention or MLP patterns:\n\n```\ncomponents\u002Fmodels\u002F\n  llama\u002F           # Standard GQA + SwiGLU (CombinedQKV + CombinedGateUpMLP)\n  qwen2\u002F           # Same as Llama but with attention bias + QKV bias\n  baichuan\u002F        # ALiBi attention variant\n  deepseek_v3\u002F     # MLA attention + MoE (DeepSeek-style grouped experts)\n  mistral4\u002F        # MLA + MoE + VLM (Pixtral vision)\n  kimivl\u002F          # DeepSeek-V3 backbone + MoonVit vision\n  kimi_k25_vl\u002F     # Updated KimiVL with different projector\n  qwen3_moe\u002F       # Qwen3 with MoE layers\n  nemotron_v3\u002F     # Hybrid mamba-attention\n```\n\n### 1.4 Identify custom components\n\nCheck whether the model needs:\n\n- **Custom attention**: GQA (standard), MLA (DeepSeek\u002FMistral4), sliding window, bidirectional\n- **Custom RoPE**: Standard (Llama), YaRN scaling, NTK-aware, complex-number (DeepSeek)\n- **Custom normalization**: RMSNorm (standard), LayerNorm, different eps values\n- **Custom MLP**: SwiGLU (standard), GeGLU, ReLU-squared, MoE routing\n- **Custom config class**: Needed only if HF `AutoConfig` cannot parse the model's `config.json` (check `auto_map` field)\n\n### 1.5 Note dimensions for test config\n\nFor unit tests, create a tiny config. Target: ~1M parameters or less.\n\n```python\n# Example tiny config for a Llama-like model:\ntiny_config = LlamaConfig(\n    hidden_size=64,\n    intermediate_size=128,\n    num_hidden_layers=2,\n    num_attention_heads=4,\n    num_key_value_heads=2,\n    vocab_size=256,\n    max_position_embeddings=128,\n)\n```\n\n---\n\n## Phase 2: Implementation\n\n### 2.1 Create directory structure\n\n```\ncomponents\u002Fmodels\u002F\u003Cname>\u002F\n  __init__.py\n  model.py\n  state_dict_adapter.py\n  config.py            # Only if HF config is insufficient\n  layers.py            # Only for MoE \u002F MLA \u002F other non-standard layers\n  rope_utils.py        # Only for custom RoPE\n```\n\n### 2.2 Implementation order\n\nImplement files in dependency order:\n\n1. **config.py** (if needed) -- Custom `PretrainedConfig` subclass\n2. **rope_utils.py** (if needed) -- RoPE implementation\n3. **layers.py** (if needed) -- Attention, MLP, decoder block classes\n4. **model.py** -- The main `ForCausalLM` (or `ForConditionalGeneration`) class\n5. **state_dict_adapter.py** -- HF weight conversion\n6. **__init__.py** -- Re-export the main model class\n\nSee the pattern files for detailed implementation guidance:\n\n- Dense LLM: [llm-patterns.md](.\u002Fllm-patterns.md)\n- MoE: [moe-patterns.md](.\u002Fmoe-patterns.md)\n- VLM: [vlm-patterns.md](.\u002Fvlm-patterns.md)\n- Capabilities and fp32 precision: [capabilities-and-precision.md](.\u002Fcapabilities-and-precision.md)\n\n### 2.3 Causal LM weight tying\n\nFor any CausalLM-style class whose config can enable `tie_word_embeddings`,\nmake tying explicit: declare `_tied_weights_keys`, implement `tie_weights()`\nwith the actual `lm_head` and input-embedding FQNs, and add tiny tests for\ntied and untied configs. Do not tie architectures with intentionally separate\nheads, asymmetric vocab sizes, or stages that do not own both tensors.\n\n### 2.4 MoE state-dict adapter checklist\n\nFor MoE models, do not stop at generic loading. The adapter must explicitly map:\n\n- Router weights, including gate bias or correction-bias tensors when the Hugging Face model has them.\n- Expert weights, preserving expert index order across local and routed experts.\n- Gate\u002Fup\u002Fdown projections, including combined or split projection layouts.\n- Shared experts separately from routed experts when the architecture has both.\n\nAdd tests that assert expected key mappings and run numerical equivalence with tiny configs before trying full checkpoints.\n\nDo not use these shortcuts:\n\n- Do not validate the adapter only by calling `from_pretrained()`.\n- Do not accept missing or extra expert keys without an explicit mapping reason.\n- Do not change dtype, transpose dimensions, or reshape tensors unless the HF\n  and NeMo layouts require it and a test proves the conversion is reversible.\n- Do not skip router or shared-expert tests because dense-layer tests pass.\n\n### 2.5 VLM onboarding checklist\n\nFor VLMs, confirm the Hugging Face config has `vision_config` and `text_config`\nand that `architectures` points to a conditional-generation class. Start from\nthe closest VLM pattern file, usually [vlm-patterns.md](.\u002Fvlm-patterns.md), and\ncompare existing implementations such as `mistral4`, `kimivl`, or\n`kimi_k25_vl`.\n\nThe implementation should explicitly cover:\n\n- Text backbone, vision tower, projector, and processor or image preprocessing assumptions.\n- Weight mapping for both text and vision modules in `state_dict_adapter.py`.\n- Registration of the `ForConditionalGeneration` class in `_transformers\u002Fregistry.py`.\n- Tiny tests that exercise image-text inputs and verify the adapter round-trip.\n\n### 2.6 Register in registry\n\nAdd the model to `MODEL_ARCH_MAPPING` in `_transformers\u002Fregistry.py`:\n\n```python\n# In _transformers\u002Fregistry.py\nMODEL_ARCH_MAPPING = OrderedDict([\n    # ... existing entries ...\n    (\n        \"NewModelForCausalLM\",\n        (\"nemo_automodel.components.models.new_model.model\", \"NewModelForCausalLM\"),\n    ),\n])\n```\n\nIf the model has a custom config class with `auto_map` in its `config.json`, also register in `_CUSTOM_CONFIG_REGISTRATIONS`:\n\n```python\n_CUSTOM_CONFIG_REGISTRATIONS: Dict[str, Tuple[str, str]] = {\n    # ... existing entries ...\n    \"new_model\": (\"nemo_automodel.components.models.new_model.configuration\", \"NewModelConfig\"),\n}\n```\n\n### 2.7 Declare capabilities and precision-sensitive params\n\nEvery class registered in `MODEL_ARCH_MAPPING` must declare parallelism\ncapabilities, either with a static nested `ModelCapabilities` dataclass or a\nvariant-aware `get_capabilities(cls, config)` method. Pick exactly one pattern.\nCapabilities should reflect recipe YAMLs that have been validated end to end.\n\nIf the model has precision-sensitive parameters such as Mamba `A_log` \u002F\n`dt_bias`, MoE sigmoid gate bias, attention-sink bias, or per-head `scale`,\ndeclare `_keep_in_fp32_modules_strict` so sharding keeps those params in fp32\ncompute. See [capabilities-and-precision.md](.\u002Fcapabilities-and-precision.md)\nfor examples, variant dispatch rules, and frozen-submodule dtype guidance.\n\n---\n\n## Phase 3: Onboarding Example Config\n\nThis phase is only for adding a minimal example config that proves the newly\nonboarded architecture can load and run. Use nemo-automodel-recipe-development for general\nrecipe authoring or existing recipe modifications.\n\n### 3.1 Create example YAML config\n\nCreate an example config under `examples\u002Fllm_finetune\u002F\u003Cname>\u002F` (or `examples\u002Fvlm_finetune\u002F\u003Cname>\u002F`):\n\n```yaml\nmodel:\n  _target_: nemo_automodel.NeMoAutoModelForCausalLM.from_pretrained\n  pretrained_model_name_or_path: \u003Corg>\u002F\u003Cmodel-name>\n\ntrainer:\n  max_steps: 100\n  gradient_clip_val: 1.0\n  accumulate_grad_batches: 1\n\n# ... data, optimizer config ...\n```\n\n### 3.2 Verify model loads\n\nTest that the model loads from a HuggingFace checkpoint:\n\n```python\nfrom nemo_automodel import NeMoAutoModelForCausalLM\n\nmodel = NeMoAutoModelForCausalLM.from_pretrained(\"\u003Corg>\u002F\u003Cmodel-name>\")\n```\n\n### 3.3 Test with tiny config first\n\nBefore using full-size models, verify with a tiny config (1-2 layers, small hidden dim) to catch shape mismatches early.\n\n## Phase 4: Tests\n\nCreate `tests\u002Funit_tests\u002Fmodels\u002F\u003Cname>\u002F` and cover the checks below before\nloading full checkpoints:\n\n- Forward-shape smoke test with a tiny config.\n- State-dict adapter round-trip: `from_hf -> to_hf` preserves mapped names,\n  shapes, dtypes, and values.\n- Layer equivalence tests for every rewritten attention, MLP, normalization,\n  RoPE, or MoE layer. Use the model dtype from config, identical seeded weights,\n  identical inputs, and dtype-appropriate `torch.allclose` tolerances.\n- Short functional test that verifies loss decreases over a few training steps.\n\n---\n\n## Phase 5: Documentation\n\n### 5.1 Update model coverage page\n\nEdit the appropriate file in `docs\u002Fmodel-coverage\u002F`:\n- LLM\u002FMoE: `docs\u002Fmodel-coverage\u002Fllm\u002Findex.md`\n- VLM: `docs\u002Fmodel-coverage\u002Fvlm\u002Findex.md`\n\nAdd a row with the model name, supported features (TP, PP, FSDP, LoRA, QLoRA), and any limitations.\n\n---\n\n## Phase 6: Parity Testing\n\nAfter implementation and unit tests are complete, run the full parity-testing\nworkflow to verify that the new model produces numerically equivalent results to\nthe reference HuggingFace implementation.\n\nRun three levels of comparison:\n\n1. State-dict round-trip: load a reference HuggingFace checkpoint, convert it\n   into the NeMo AutoModel layout, export it back, and verify that all mapped\n   tensors match the reference names, shapes, dtypes, and values within the\n   expected tolerance.\n2. Component-level parity: compare rewritten attention, MLP, normalization,\n   RoPE, and MoE components against the HuggingFace implementation with fixed\n   seeds and identical dtype.\n3. End-to-end forward pass: run the full NeMo AutoModel and HuggingFace model\n   on the same tokenized input and compare logits, hidden states, and loss.\n\nDo not skip this phase. A model that passes unit tests can still diverge from HF\ndue to subtle weight-conversion bugs, backend differences, or RoPE mismatches\nthat only surface in a full parity comparison.\n\n---\n\n## Key Files Reference\n\n| File | Purpose |\n|------|---------|\n| `_transformers\u002Fregistry.py` | `MODEL_ARCH_MAPPING` and `_CUSTOM_CONFIG_REGISTRATIONS` |\n| `components\u002Fmodels\u002Fcommon\u002F__init__.py` | Exports `CombinedQKVAttentionMixin`, `CombinedGateUpMLP`, `BackendConfig`, `HFCheckpointingMixin`, etc. |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fcombined_qkv.py` | `CombinedQKVAttentionMixin` with `setup_qkv_projection()` and `compute_qkv()` |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fcombined_mlp.py` | `CombinedGateUpMLP` with interleaved gate\u002Fup layout |\n| `components\u002Fmodels\u002Fcommon\u002Fcombined_projection\u002Fstate_dict_adapter.py` | `CombinedProjectionStateDictAdapter` base class |\n| `components\u002Fmodels\u002Fcommon\u002Fhf_checkpointing_mixin.py` | `HFCheckpointingMixin` for save\u002Fload |\n| `components\u002Fmodels\u002Fcommon\u002Futils.py` | `BackendConfig`, `initialize_rms_norm_module`, `initialize_linear_module`, `get_rope_config` |\n| `components\u002Fmoe\u002Fconfig.py` | `MoEConfig` dataclass |\n| `components\u002Fmoe\u002Ffsdp_mixin.py` | `MoEFSDPSyncMixin` for distributed expert handling |\n| `components\u002Fmoe\u002Flayers.py` | `MoE` layer, `MLP` (dense) for MoE blocks |\n| `components\u002Fmoe\u002Fexperts.py` | `GroupedExperts`, `GroupedExpertsDeepEP`, `GroupedExpertsTE` |\n\n---\n\n## Checklist\n\n- [ ] Fetched and analyzed `config.json` from HuggingFace\n- [ ] Determined model type (dense LLM \u002F MoE \u002F VLM)\n- [ ] Identified custom components (attention, RoPE, normalization, MLP)\n- [ ] Created `components\u002Fmodels\u002F\u003Cname>\u002F` directory\n- [ ] Implemented config.py (if custom config needed)\n- [ ] Implemented layers.py (if custom layers needed)\n- [ ] Implemented rope_utils.py (if custom RoPE needed)\n- [ ] Implemented model.py with `HFCheckpointingMixin`\n- [ ] Implemented state_dict_adapter.py\n- [ ] Implemented __init__.py with re-export\n- [ ] Registered in `MODEL_ARCH_MAPPING` in `_transformers\u002Fregistry.py`\n- [ ] Registered custom config in `_CUSTOM_CONFIG_REGISTRATIONS` (if applicable)\n- [ ] Declared `ModelCapabilities` nested dataclass (static) OR `get_capabilities(cls, config)` classmethod (variant dispatch, e.g. ERNIE-4.5 MoE vs dense) — never both, never neither\n- [ ] Created example YAML config\n- [ ] Verified model loads via `NeMoAutoModelForCausalLM.from_pretrained()`\n- [ ] Created unit tests (forward shape, state_dict round-trip)\n- [ ] Declared `_keep_in_fp32_modules_strict` for every intrinsically-fp32 param (SSM `A_log`\u002F`dt_bias`, Mamba `D` when reference-fp32, MoE gate bias, attention-sink bias, `scale`, …) — see §2.7\n- [ ] Created layer equivalence tests for every rewritten layer (matching model dtype)\n- [ ] Created functional tests (training loss decreases)\n- [ ] Updated docs\u002Fmodel-coverage page\n- [ ] Ran state-dict round-trip, component parity, and E2E forward-pass parity checks\n- [ ] Set `ModelClass = \u003CName>ForCausalLM` at module bottom\n",{"name":5,"license":15,"metadata":49,"description":7,"when_to_use":54},{"tags":50,"author":53},[51,52],"nemo-automodel","model-onboarding","NVIDIA","Adding or modifying model architecture support in NeMo AutoModel, such as LLM\u002FVLM\u002FMoE model files, custom layers, state-dict adapters, registry entries, Hugging Face config mapping, or capability flags.","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fnemo-automodel-model-onboarding","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add pattanation\u002FNorvik --skill nemo-automodel-model-onboarding",{"tool":68,"command":69},"bunx","bunx skills add pattanation\u002FNorvik --skill nemo-automodel-model-onboarding",{"tool":71,"command":72},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill nemo-automodel-model-onboarding","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002FSKILL.md",true,[76,82,86,90,94,98,102,108],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"BENCHMARK.md","REFERENCE","参考文档",4162,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002FBENCHMARK.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"capabilities-and-precision.md",4984,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fcapabilities-and-precision.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fevals.json",3803,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fevals\u002Fevals.json",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"llm-patterns.md",16015,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fllm-patterns.md",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"moe-patterns.md",18423,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fmoe-patterns.md",{"path":99,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":100,"sourceHtmlUrl":101},"skill-card.md",4200,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fskill-card.md",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"skill.oms.sig","OTHER","其他",5521,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fskill.oms.sig",{"path":109,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":110,"sourceHtmlUrl":111},"vlm-patterns.md",16920,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fnemo-automodel-model-onboarding\u002Fvlm-patterns.md",[113,147,173,197,218,233],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":117,"sourceHtmlUrl":118,"categories":119,"keywords":128,"publishedAt":146},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[120,125],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000009","前端开发",[129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145],"webapp","testing","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":151,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":146},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[154],{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},[156,157,158,142,159,160,161,132,162,163,135,164,165,166,167,168,169,170,171,172],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":177,"licenseFileUrl":178,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":146},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[181],{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},[183,184,185,186,187,188,189,190,191,192,193,194,195,196],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":177,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":206,"publishedAt":146},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[204,205],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},[207,130,208,194,209,141,210,211,212,189,213,132,214,215,216,165,32,195,217],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","e2e testing",{"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":177,"licenseFileUrl":222,"sourceHtmlUrl":223,"categories":224,"keywords":226,"publishedAt":146},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[225],{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},[227,194,228,209,229,212,230,189,32,231,232],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":177,"licenseFileUrl":237,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":146},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[240],{"categoryNo":126,"categoryName":127,"taxonomyType":123,"taxonomyTypeDesc":124},[242,194,209,243,186,42,244,245,227,246,247,248,249,250,28,132,251,165,252,253],"vue best practices","Composition","tasks","api","pinia","work","options","ssr","typescript","vite","load","standard"]