/jetson-derive-carrier
Bootstrap a custom carrier board by forking carrier files and scaffolding a DT overlay from the reference devkit. Use after jetson-init-source; not for module-level or kernel-DTB changes.
$ npx -y skills add NVIDIA/skills --skill jetson-derive-carrier --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/jetson-derive-carrier
Context preview
The summary Claude sees to decide when to auto-load this skill.
Bootstrap a custom carrier board by forking carrier files and scaffolding a DT overlay from the reference devkit. Use after jetson-init-source; not for module-level or kernel-DTB changes.
SKILL.md
jetson-derive-carrier.SKILL.mdname: jetson-derive-carrier
description: >-
Bootstrap a custom carrier board by forking carrier files and
scaffolding a DT overlay from the reference devkit. Use after
jetson-init-source; not for module-level or kernel-DTB changes.
version: 0.0.1
license: "Apache-2.0"
metadata:
data-classification: public
author: "Jetson Team"
tags:
- target-platform
- custom-carrier
- bring-up
- setup
domain: metajetson-derive-carrier
Customize first-run gate for any `customize-*` skill on a custom carrier. Resolve the active target per [`target-platform-contract.md`](../../context/target-platform-contract.md). **Refuse** if no `custom_carrier:` block, or if `<source.root_path>/Linux_for_Tegra/.git` is missing (`jetson-init-source` first). Template file create/copy rows land in a single overlay-tracker commit and copy **directly** to the custom-carrier-renamed target path — reference-named pristine files are never staged (see [Fork plan](#fork-plan) for the local rule, which overrides the standard pristine + customization split from the [workflow](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker)); conf-chain discovery follows [per-board conf dispatch](../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common). Kernel base DTB is **not** forked — carrier deltas layer as a DT overlay wired via `OVERLAY_DTB_FILE`.
**Identifiers** (from active profile): `<chip>` from `reference_devkit.module.id` via [catalogue](../../references/bsp-platforms-catalogue.md) (unknown → warn, fallback `tegra234`); `<module-id>`/`<module-sku>` from `reference_devkit.module`; `<carrier-id>`/`<carrier-sku>` from `reference_devkit.carrier`; `<custom-id>`/`<custom-sku>`/ `<custom-flash-conf>` from `custom_carrier`. `<real-conf>` = `readlink <bsp_image.root_path>/Linux_for_Tegra/<reference_devkit.flash_config>` (NVIDIA convention `<devkit>.conf` → `<carrier>-<module>-a<rev>.conf`; warn + treat top-level as real + skip symlink-wrapper row if not a symlink).
`<custom-id>` is a custom carrier board token, not necessarily an NVIDIA-style `pNNNN` ID. Use it verbatim in dash-form filenames and DT compatible strings. When a target file family uses p-stripped numeric tokens, derive `<custom-id-file-token>` as `NNNN` only if `<custom-id>` matches `^p[0-9]{4}$`; otherwise use `<custom-id>` unchanged. Do not reject custom carrier IDs merely because they do not start with `p`.
Instructions
The fork plan below is the instruction set: one discovery pass, then a row-by-row fork of the per-board fileset, gated by the commit-message preview before each `git commit`.
Fork plan
Every `git commit` produced by this skill — in the overlay tracker (`Linux_for_Tegra/`) or the `hardware/` source repo — runs through the [commit message preview gate](../../context/bsp-customization-workflow.md#commit-message-preview-gate). Surface the staged file list + proposed message to the operator and require accept / edit / cancel before each `git commit`; on **cancel** leave the index staged for manual resolution.
**Materialize renamed forks even when bytes do not change.** For every accepted fork-plan row, create and track the custom-carrier target path; do not skip a missing target because the fork is only a rename/copy or is byte-identical to the reference. This includes BCT forks such as pinmux, GPIO/GPIOINT, padvoltage/PMC, misc, and MB2 misc. Skip only when the Acceptance column allows it, the source is an explicit warn-and-skip miss, or the expected target path is already tracked; in the last case, report it as already derived and do not create an empty commit.
**Template file create/copy rows squash into one overlay-tracker commit, and reference-named pristine files are never staged.** All rows that materialize a new (template-derived) file in the overlay tracker — board flash-conf, flash-conf symlink, MB1 BCT (pinmux, GPIO/GPIOINT, padvoltage/PMC, misc), MB2 BCT (misc), BPMP DTB (when opted in), nvpmodel, nvfancontrol — copy **directly** from `<bsp_image.root_path>/Linux_for_Tegra/<rel>/<reference-name>` to `<source.root_path>/Linux_for_Tegra/<rel>/<custom-name>` with any content edits applied before staging. The reference-named (`<carrier-id>-<carrier-sku>`-keyed) filename is never staged or committed in the overlay tracker — only the custom-carrier-renamed file is tracked. This overrides the standard pristine + customization split from [commit batching](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker). All such rows land in a **single** overlay-tracker commit that adds: (i) the custom-carrier-named files at their target paths with content already applied, (ii) the flash-conf symlink, and (iii) the targeted flash-conf content rewrites inside the renamed flash-conf for `PINMUX_CONFIG` / `GPIO_CONFIG` / `GPIOINT_CONFIG` / `PMC_CONFIG` / `MISC_CONFIG` / `MB2_BCT` (plus `BPFDTB_FILE` when BPMP DTB is opted in). Rows that edit existing upstream files instead of creating templates — the `nvpower.sh` patch — and the overlay wire-up (`OVERLAY_DTB_FILE+=` append to the just-created flash-conf fork, treated as a temporally distinct phase per [commit batching](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker)) remain separate commits per their own rows. The DT overlay skeleton commits in `bsp_sources/hardware/`, not the overlay tracker, so it is unaffected. The commit message preview gate fires once on the squashed commit; warn-and-skipped rows do not contribute, and if every row in the bundle is already tracked the commit is omitted entirely.
Discovery (single batched pass)
Run **one** discovery pass; do not interleave with staging. **Do not truncate listings** — every candidate filename in each scanned directory must be visible to the matcher. `head`, `tail`, `| head -N`, `| tail -N`, and any other row-limiting filter are out of bounds for this step; use `ls -1`
Read more
name: jetson-derive-carrier
description: >-
Bootstrap a custom carrier board by forking carrier files and
scaffolding a DT overlay from the reference devkit. Use after
jetson-init-source; not for module-level or kernel-DTB changes.
version: 0.0.1
license: "Apache-2.0"
metadata:
data-classification: public
author: "Jetson Team"
tags:
- target-platform
- custom-carrier
- bring-up
- setup
domain: metajetson-derive-carrier
Customize first-run gate for any `customize-*` skill on a custom carrier. Resolve the active target per [`target-platform-contract.md`](../../context/target-platform-contract.md). **Refuse** if no `custom_carrier:` block, or if `<source.root_path>/Linux_for_Tegra/.git` is missing (`jetson-init-source` first). Template file create/copy rows land in a single overlay-tracker commit and copy **directly** to the custom-carrier-renamed target path — reference-named pristine files are never staged (see [Fork plan](#fork-plan) for the local rule, which overrides the standard pristine + customization split from the [workflow](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker)); conf-chain discovery follows [per-board conf dispatch](../../context/bsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common). Kernel base DTB is **not** forked — carrier deltas layer as a DT overlay wired via `OVERLAY_DTB_FILE`.
**Identifiers** (from active profile): `<chip>` from `reference_devkit.module.id` via [catalogue](../../references/bsp-platforms-catalogue.md) (unknown → warn, fallback `tegra234`); `<module-id>`/`<module-sku>` from `reference_devkit.module`; `<carrier-id>`/`<carrier-sku>` from `reference_devkit.carrier`; `<custom-id>`/`<custom-sku>`/ `<custom-flash-conf>` from `custom_carrier`. `<real-conf>` = `readlink <bsp_image.root_path>/Linux_for_Tegra/<reference_devkit.flash_config>` (NVIDIA convention `<devkit>.conf` → `<carrier>-<module>-a<rev>.conf`; warn + treat top-level as real + skip symlink-wrapper row if not a symlink).
`<custom-id>` is a custom carrier board token, not necessarily an NVIDIA-style `pNNNN` ID. Use it verbatim in dash-form filenames and DT compatible strings. When a target file family uses p-stripped numeric tokens, derive `<custom-id-file-token>` as `NNNN` only if `<custom-id>` matches `^p[0-9]{4}$`; otherwise use `<custom-id>` unchanged. Do not reject custom carrier IDs merely because they do not start with `p`.
Instructions
The fork plan below is the instruction set: one discovery pass, then a row-by-row fork of the per-board fileset, gated by the commit-message preview before each `git commit`.
Fork plan
Every `git commit` produced by this skill — in the overlay tracker (`Linux_for_Tegra/`) or the `hardware/` source repo — runs through the [commit message preview gate](../../context/bsp-customization-workflow.md#commit-message-preview-gate). Surface the staged file list + proposed message to the operator and require accept / edit / cancel before each `git commit`; on **cancel** leave the index staged for manual resolution.
**Materialize renamed forks even when bytes do not change.** For every accepted fork-plan row, create and track the custom-carrier target path; do not skip a missing target because the fork is only a rename/copy or is byte-identical to the reference. This includes BCT forks such as pinmux, GPIO/GPIOINT, padvoltage/PMC, misc, and MB2 misc. Skip only when the Acceptance column allows it, the source is an explicit warn-and-skip miss, or the expected target path is already tracked; in the last case, report it as already derived and do not create an empty commit.
**Template file create/copy rows squash into one overlay-tracker commit, and reference-named pristine files are never staged.** All rows that materialize a new (template-derived) file in the overlay tracker — board flash-conf, flash-conf symlink, MB1 BCT (pinmux, GPIO/GPIOINT, padvoltage/PMC, misc), MB2 BCT (misc), BPMP DTB (when opted in), nvpmodel, nvfancontrol — copy **directly** from `<bsp_image.root_path>/Linux_for_Tegra/<rel>/<reference-name>` to `<source.root_path>/Linux_for_Tegra/<rel>/<custom-name>` with any content edits applied before staging. The reference-named (`<carrier-id>-<carrier-sku>`-keyed) filename is never staged or committed in the overlay tracker — only the custom-carrier-renamed file is tracked. This overrides the standard pristine + customization split from [commit batching](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker). All such rows land in a **single** overlay-tracker commit that adds: (i) the custom-carrier-named files at their target paths with content already applied, (ii) the flash-conf symlink, and (iii) the targeted flash-conf content rewrites inside the renamed flash-conf for `PINMUX_CONFIG` / `GPIO_CONFIG` / `GPIOINT_CONFIG` / `PMC_CONFIG` / `MISC_CONFIG` / `MB2_BCT` (plus `BPFDTB_FILE` when BPMP DTB is opted in). Rows that edit existing upstream files instead of creating templates — the `nvpower.sh` patch — and the overlay wire-up (`OVERLAY_DTB_FILE+=` append to the just-created flash-conf fork, treated as a temporally distinct phase per [commit batching](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker)) remain separate commits per their own rows. The DT overlay skeleton commits in `bsp_sources/hardware/`, not the overlay tracker, so it is unaffected. The commit message preview gate fires once on the squashed commit; warn-and-skipped rows do not contribute, and if every row in the bundle is already tracked the commit is omitted entirely.
Discovery (single batched pass)
Run **one** discovery pass; do not interleave with staging. **Do not truncate listings** — every candidate filename in each scanned directory must be visible to the matcher. `head`, `tail`, `| head -N`, `| tail -N`, and any other row-limiting filter are out of bounds for this step; use `ls -1`
Official, NVIDIA-verified Agent Skills for Claude Code, Codex, and other coding agents.
Other skills on nvidia-skills.
- /nvidia-skill-finder
Use for NVIDIA-related requests where an NVIDIA skill might help, even if the user did not ask for a skill. Trigger on NVIDIA products, hardware, software, SDKs, GPUs, Jetson/JetPack/L4T/BSP/SDK Manager/driver/flashing/setup, CUDA, NIM, NeMo, Omniverse/OpenUSD/SimReady,
Open skill - /accelerated-computing-cudf
Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV/Parquet I/O, nullable semantics, and multi-GPU DataFrame workloads.
Open skill - /aiq-deploy
Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.
Open skill - /aiq-research
Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.
Open skill - /amc-run-sample-calibration
Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.
Open skill - /amc-run-video-calibration
Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP/live streams, use amc-run-rtsp-calibration instead.
Open skill

