/jetson-init-target

name: jetson-init-target
description: >-
  Author a new Jetson target-platform profile (reference_devkit +
  optional custom_carrier) and update the active pointer. Use to
  create a target; not for switching existing profiles.
version: 0.0.1
license: "Apache-2.0"
metadata:
  data-classification: public
  author: "Jetson Team"
  tags:
    - target-platform
    - configuration
    - meta
  domain: meta

Initialize Target Platform

Overview

This skill **authors** a new target-platform profile YAML — the write-side of the contract in [`../../context/target-platform-contract.md`](../../context/target-platform-contract.md). It uses [`../../references/bsp-platforms-catalogue.md`](../../references/bsp-platforms-catalogue.md) as the canonical product / flash-config catalogue and [`../../references/platform_template.yaml`](../../references/platform_template.yaml) as the field schema.

Flow is linear: pick a reference product + flash config, then **optionally** add custom-carrier details. The two contract cases — reference-only vs reference + custom carrier — are distinguished only by whether the user provides custom-carrier details; there is no up-front mode prompt.

**Scope is `reference_devkit:` and `custom_carrier:` only.** Sibling skills own the other blocks: `bsp_image:` → [`jetson-init-image`](../jetson-init-image/SKILL.md); `source:` → [`jetson-init-source`](../jetson-init-source/SKILL.md); `documents:` → [`jetson-link-docs`](../jetson-link-docs/SKILL.md).

Outputs: a new `target-platform/<name>.yaml` and (by default) an updated `active_target.yml` pointing at it. To switch among already-authored profiles, use sibling `jetson-set-target`.

When to invoke

• The user asks to create / author / add a new target platform profile.
• A downstream skill refused with "no active target" **and**

`target-platform/` contains no profile YAML files yet (otherwise prefer `jetson-set-target`).

• The user wants a target whose profile does not yet exist on disk.

Procedure

Quick-start prefill mapping

Follow the shared [`quick_start_prefill` contract](../../context/bsp-customization-workflow.md#quick_start_prefill-contract). This skill consumes:

• `quick_start_prefill.target.active_platform` as the selected catalogue

row when it resolves to exactly one product.

• `quick_start_prefill.target.custom_carrier` as the custom-carrier

intent.

If `active_platform` resolves to one catalogue row, use it directly. Do not re-ask reference-product or flash-config questions; use the row's default flash config unless the prefill names a catalogue variant. Ask only when the prefill is missing, invalid, ambiguous, or names an unknown variant.

How the skill consumes the template

Load [`../../references/platform_template.yaml`](../../references/platform_template.yaml) once at skill startup and treat it as the schema for prompted blocks. Each placeholder value carries one of three sentinel markers:

| Marker | Behavior | |---|---| | `<REQUIRED: description>` | Prompt the user. Value must be provided; `NA` is accepted with a warning that downstream skills may refuse. | | `<OPTIONAL: description>` | Prompt the user. Value may be skipped (Enter or `NA`); skipped fields are **omitted** from the written profile (no empty key, no `NA` placeholder). | | `<DERIVED: description>` | Filled programmatically from `bsp-platforms-catalogue.md` and the user's product / flash-config choice in the "Pick the reference product" and "Pick the flash config" steps. **Not prompted.** |

Use the marker description as the prompt text verbatim. Match markers with the regex `^<(REQUIRED|OPTIONAL|DERIVED):\s*(.*)>$` after YAML parsing strips the surrounding quotes.

Block-level inclusion (`custom_carrier`) is decided by the skill flow, not by markers — adding/removing fields **inside** a block is a template-only change.

Survey current state

1. If `target-platform/` does not exist, create it and copy [`../../references/active_target_template.yaml`](../../references/active_target_template.yaml) to `target-platform/active_target.yml` (note `.yml` extension). 2. Read `target-platform/active_target.yml`. 3. List `target-platform/*.yaml` (excluding `active_target.yml`).

| Situation | Action | |---|---| | No profile YAMLs exist | Proceed — this is the bootstrap case. The new profile will be set as `active_target` automatically in the "Write" step (no activation prompt in the "Confirm" step). | | Profiles exist, `active: NA` | Show the list of existing profiles and confirm the user wants to author a new one (rather than activate one of the existing profiles via `jetson-set-target`). | | Profiles exist, `active:` names a present file | Show the active profile and the full list. Ask whether the user wants to (a) author a new profile alongside, or (b) switch to one of the existing profiles via `jetson-set-target`. If (b), stop and tell the user to run `jetson-set-target`. | | `active:` names a missing file | Tell the user the pointer is broken; offer to author a new profile (and replace the pointer) or to fix the pointer manually. |

Read the platforms catalogue

Read [`../../references/bsp-platforms-catalogue.md`](../../references/bsp-platforms-catalogue.md). Parse the **"Product / Chip / SKU / Flash Config Mapping"** table — that is the source of truth for product names, CVM/CVB SKUs, default flash confs, and variant suffixes. Do **not** scan `Linux_for_Tegra/*.conf` or parse conf filenames; the catalogue already collapses that.

Pick the reference product (baseline)

Print the full catalogue list before asking. Group rows by chip family and number every entry with stable indexes for this run. Build the list only from `bsp-platforms-catalogue.md`; do not copy platform rows from examples or other docs.

Build explicit shortcut choices from the printed list by taking the first row in each chip-family group. Each shortcut label must include the full-list index and product name, for example `Index 1 — Jets