[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NMAW7E3Y6SA4PZKFDJVM3":3,"skill-same:01M71NMAW7E3Y6SA4PZKFDJVM3":100},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71NMAW7E3Y6SA4PZKFDJVM3","jetson-init-target",null,"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.","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\u002Fjetson-init-target\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"init","jetson init target","target","reference","public","devkit","update","active","create","author","team","switching","Existing","use","new","custom","profiles","Meta","for","platform","2026-11-10 10:56:23",false,"---\nname: jetson-init-target\ndescription: >-\n  Author a new Jetson target-platform profile (reference_devkit +\n  optional custom_carrier) and update the active pointer. Use to\n  create a target; not for switching existing profiles.\nversion: 0.0.1\nlicense: \"Apache-2.0\"\nmetadata:\n  data-classification: public\n  author: \"Jetson Team\"\n  tags:\n    - target-platform\n    - configuration\n    - meta\n  domain: meta\n---\n\n# Initialize Target Platform\n\n## Overview\n\nThis skill **authors** a new target-platform profile YAML — the\nwrite-side of the contract in\n[`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md). It uses\n[`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md)\nas the canonical product \u002F flash-config catalogue and\n[`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml)\nas the field schema.\n\nFlow is linear: pick a reference product + flash config, then\n**optionally** add custom-carrier details. The two contract cases —\nreference-only vs reference + custom carrier — are distinguished only\nby whether the user provides custom-carrier details; there is no\nup-front mode prompt.\n\n**Scope is `reference_devkit:` and `custom_carrier:` only.** Sibling\nskills own the other blocks: `bsp_image:` →\n[`jetson-init-image`](..\u002Fjetson-init-image\u002FSKILL.md); `source:` →\n[`jetson-init-source`](..\u002Fjetson-init-source\u002FSKILL.md); `documents:` →\n[`jetson-link-docs`](..\u002Fjetson-link-docs\u002FSKILL.md).\n\nOutputs: a new `target-platform\u002F\u003Cname>.yaml` and (by default) an\nupdated `active_target.yml` pointing at it. To switch among\nalready-authored profiles, use sibling `jetson-set-target`.\n\n## When to invoke\n\n- The user asks to create \u002F author \u002F add a new target platform profile.\n- A downstream skill refused with \"no active target\" **and**\n  `target-platform\u002F` contains no profile YAML files yet (otherwise\n  prefer `jetson-set-target`).\n- The user wants a target whose profile does not yet exist on disk.\n\n## Procedure\n\n### Quick-start prefill mapping\n\nFollow the shared\n[`quick_start_prefill` contract](..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md#quick_start_prefill-contract).\nThis skill consumes:\n\n- `quick_start_prefill.target.active_platform` as the selected catalogue\n  row when it resolves to exactly one product.\n- `quick_start_prefill.target.custom_carrier` as the custom-carrier\n  intent.\n\nIf `active_platform` resolves to one catalogue row, use it directly. Do\nnot re-ask reference-product or flash-config questions; use the row's\ndefault flash config unless the prefill names a catalogue variant. Ask\nonly when the prefill is missing, invalid, ambiguous, or names an unknown\nvariant.\n\n### How the skill consumes the template\n\nLoad\n[`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml)\nonce at skill startup and treat it as the schema for prompted blocks.\nEach placeholder value carries one of three sentinel markers:\n\n| Marker | Behavior |\n|---|---|\n| `\u003CREQUIRED: description>` | Prompt the user. Value must be provided; `NA` is accepted with a warning that downstream skills may refuse. |\n| `\u003COPTIONAL: 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). |\n| `\u003CDERIVED: description>` | Filled programmatically from `bsp-platforms-catalogue.md` and the user's product \u002F flash-config choice in the \"Pick the reference product\" and \"Pick the flash config\" steps. **Not prompted.** |\n\nUse the marker description as the prompt text verbatim. Match markers\nwith the regex `^\u003C(REQUIRED|OPTIONAL|DERIVED):\\s*(.*)>$` after YAML\nparsing strips the surrounding quotes.\n\nBlock-level inclusion (`custom_carrier`) is decided by the skill\nflow, not by markers — adding\u002Fremoving fields **inside** a block is\na template-only change.\n\n### Survey current state\n\n1. If `target-platform\u002F` does not exist, create it and copy\n   [`..\u002F..\u002Freferences\u002Factive_target_template.yaml`](..\u002F..\u002Freferences\u002Factive_target_template.yaml)\n   to `target-platform\u002Factive_target.yml` (note `.yml` extension).\n2. Read `target-platform\u002Factive_target.yml`.\n3. List `target-platform\u002F*.yaml` (excluding `active_target.yml`).\n\n| Situation | Action |\n|---|---|\n| 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). |\n| 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`). |\n| 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`. |\n| `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. |\n\n### Read the platforms catalogue\n\nRead [`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md).\nParse the **\"Product \u002F Chip \u002F SKU \u002F Flash Config Mapping\"** table — that\nis the source of truth for product names, CVM\u002FCVB SKUs, default flash\nconfs, and variant suffixes. Do **not** scan `Linux_for_Tegra\u002F*.conf`\nor parse conf filenames; the catalogue already collapses that.\n\n### Pick the reference product (baseline)\n\nPrint the full catalogue list before asking. Group rows by chip family\nand number every entry with stable indexes for this run. Build the list\nonly from `bsp-platforms-catalogue.md`; do not copy platform rows from\nexamples or other docs.\n\nBuild explicit shortcut choices from the printed list by taking the first\nrow in each chip-family group. Each shortcut label must include the\nfull-list index and product name, for example `Index 1 — Jetson AGX Orin\n64GB`. Do not hard-code product names; derive shortcuts from the parsed\ncatalogue rows. These shortcuts are the only explicit choices for this\nquestion. Manual index entry must use the tool's built-in `Type something`\ninput; do not add a third custom choice for manual entry.\n\nPrompt text:\n\n> Pick a platform shortcut, or choose Type something and type the numeric\n> index from the full platform list printed above. If your hardware is a\n> custom carrier with one of these Jetson modules, pick the closest\n> matching reference devkit as the baseline. Type cancel to cancel this\n> run.\n\nDo not show chip-family choices such as `T234 \u002F Orin family` or\n`T264 \u002F Thor family`. Do not show `Type index`, `Manual entry`, `Other\nplatform`, or any custom manual-entry choice. The only manual-entry path\nis the tool-provided `Type something` row. Do not add `Other` as a choice\nor paraphrase `Type something` as `Other` in prompt text. Do not accept\nproduct-name substring matches in this step; typed input must be a numeric\nindex from the printed full list or `cancel`. `skip` is not allowed\nbecause this skill cannot author a target profile without a reference\nplatform.\n\nResolve the shortcut or typed index to exactly one catalogue row. If the\ntyped index is out of range or invalid, show the valid index range and ask\nagain. If the user types `skip`, explain that `jetson-init-target`\nrequires a reference platform and ask again. If the user types `cancel`,\nstop without writing a profile.\n\n### Pick the flash config\n\nFrom the catalogue row, the **Default flash conf** is option `1`; the\n**Variants** column lists suffixes — option `2..N`. Reconstruct each\nvariant's full conf filename by appending the suffix to the default\nconf base. If a row says `(same as \u003Cother>)` in the Variants column,\nreuse the referenced row's variant list verbatim. Build this list only\nfrom the selected catalogue row.\n\nPrompt:\n\n> Pick a number, or press Enter to accept the default (`1`).\n\nIf the chosen row has no variants (`—` in the catalogue), proceed to\nthe \"Optional: add custom carrier details\" step with the default conf.\n\n**Edge cases:**\n\n- **Raw-conf variants** (catalogue marks `(raw)`). For Orin Nano,\n  `-a0-maxn (raw)` → `p3768-0000-p3767-0000-a0-maxn.conf`. Use the raw\n  filename verbatim.\n- **`(same as \u003Cother>)` placeholders.** Reuse the referenced row's\n  variants verbatim.\n\n### Optional: add custom carrier details\n\nAfter the baseline + flash config are chosen, resolve whether the profile\nshould record a custom carrier on top. If\n`quick_start_prefill.target.custom_carrier` is a valid concrete intent,\nconsume it directly:\n\n- `add_custom_carrier` → record `custom_carrier:` and collect the missing\n  carrier metadata below.\n- `no_custom_carrier` → omit `custom_carrier:` and proceed to the\n  \"Confirm\" step.\n- `keep_existing_custom_carrier` is valid only when editing an existing\n  active profile that already has `custom_carrier:`. Because this skill\n  authors a new profile, treat it as ambiguous and ask the custom-carrier\n  intent question below.\n- `skip` or a missing prefill value → ask the custom-carrier intent\n  question below.\n\nWhen intent is not already concrete, ask the user whether they also want\nto record a custom carrier on top using the `AskUserQuestions` UI. This\nis a bounded choice; show `add` and `skip` only:\n\n> Optionally add custom-carrier details for a customer-designed carrier\n> using this Jetson module? (`add` \u002F `skip`, default `skip`)\n\nIf the resolved intent is `skip`, proceed to the \"Confirm\" step with the\n`custom_carrier:` block omitted.\n\nIf the resolved intent is `add`, collect every still-missing\n`custom_carrier:` value through the `AskUserQuestions` UI. Do not collect\ncustom-carrier metadata with plain-text prompts, inline chat questions,\nfreeform summary confirmation, inferred defaults, or example values\npresented as selectable options. Split the collection into multiple\n`AskUserQuestions` forms if the UI question limit would otherwise be\nexceeded.\n\nFor the first `AskUserQuestions` form, ask `custom_carrier.name`,\n`custom_carrier.id`, `custom_carrier.sku`, and\n`custom_carrier.revision` in template document order. For these four\nfields, the only selectable path shown to the user must be the tool's\nbuilt-in `Type something` row. Do not add example values, \"Other\",\nguessed board IDs, guessed SKUs, common revision strings, or any explicit\ndomain options. These are customer-provided metadata: preserve them\nexactly as entered and do not require or validate any naming convention,\nprefix, case, character set, digit count, or SKU format. Validate only\nthat required fields are non-empty unless the user explicitly enters\n`NA`. `NA` is accepted per the contract for required fields; warn that\ndownstream skills may refuse if a missing field is required for their\nedit.\n\nAfter `custom_carrier.name` is known, collect\n`custom_carrier.flash_config` through a second `AskUserQuestions` form if\nit is still missing. Show the suggested default as the only explicit\nchoice and allow the built-in `Type something` row for a custom `.conf`\nfilename. Require a non-empty filename ending in `.conf`; do not derive\nit from board ID, SKU, or any guessed convention.\n\nField-specific behavior (defaults \u002F suggestions not expressible via\nmarkers alone):\n\n- `custom_carrier.flash_config` — suggest a default of kebab-cased\n  `custom_carrier.name + \".conf\"` (e.g. \"Acme Vision X1\" →\n  `acme-vision-x1.conf`).\n- `custom_carrier.name` — prompt: \"Type the customer-facing custom\n  carrier or product name exactly as you want it recorded. No format is\n  required.\" Use `Type something` only.\n- `custom_carrier.id` — prompt: \"Type the custom carrier board ID or\n  project ID exactly as you want it recorded. No format is required.\"\n  Use `Type something` only.\n- `custom_carrier.sku` — prompt: \"Type the custom carrier SKU or variant\n  identifier exactly as you want it recorded. No format is required.\"\n  Use `Type something` only; quote in the written YAML so numeric-looking\n  values and leading zeros survive.\n- `custom_carrier.revision` — prompt: \"Type the custom carrier revision\n  or build identifier exactly as you want it recorded, or press Enter to\n  omit it. No format is required.\" Use `Type something` only; omit when\n  skipped.\n\nIf the user does not know a value, suggest reading\n`\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids` on the booted target. If genuinely\nunavailable, accept `NA` for required fields or omit optional fields.\n\nThe template intentionally omits `custom_carrier.module` and\n`custom_carrier.chip_family` — module identity comes from\n`reference_devkit.module` (the same physical Jetson module plugs into\nboth carriers). Don't add them back.\n\n### Confirm\n\nShow the proposed YAML. Shape depends on whether the user added\ncustom-carrier details in the \"Optional: add custom carrier details\"\nstep. **Example:** see\n[`references\u002Fui-samples.md`](references\u002Fui-samples.md) for the\nreference-only and reference + custom-carrier YAML shapes, plus the\nnote on which sibling skill appends which block.\n\nSuggested filename:\n\n- **Reference-only:** kebab-cased product name from the selected\n  catalogue row, with `.yaml` appended. E.g. `Jetson AGX Thor T5000` →\n  `jetson-agx-thor-t5000.yaml`; `Jetson AGX Orin 32GB` →\n  `jetson-agx-orin-32gb.yaml`. Do not derive the filename from\n  `flash_config`; multiple products can share one default conf.\n- **With custom carrier:** kebab-cased `custom_carrier.name`. E.g.\n  \"Acme Vision X1\" → `acme-vision-x1.yaml`.\n\nUse the suggested filename without asking when it is unique and was\ngenerated from the selected platform or custom-carrier name. Print the\nfilename and continue. Ask only on collision, empty generated name,\nambiguous input, or explicit custom-filename request. Then handle\nactivation:\n\n- **Bootstrap case** (no profile YAMLs existed at the \"Survey current state\" step): **do not\n  prompt.** The new profile is the first one, so it is auto-activated\n  in the \"Write\" step. Tell the user this is happening so the auto-activation is\n  not silent.\n- **Profiles already exist**: ask whether to **activate** the new\n  profile (default: yes). Decline only if the user is authoring\n  multiple profiles to choose from later — they can activate any of\n  them with `jetson-set-target`.\n\n### Write (and optionally activate)\n\n1. Write `target-platform\u002F\u003Cfilename>.yaml`. If the file already\n   exists, ask before overwriting; never silently clobber.\n2. Edit `target-platform\u002Factive_target.yml` to set\n   `active: \u003Cfilename>.yaml` when **either** of the following holds:\n   - This was the bootstrap case from the \"Survey current state\" step (no profile YAMLs existed\n     before this run) — activation is automatic, regardless of any\n     prior user input.\n   - Profiles already existed and the user accepted activation in\n     the \"Confirm\" step.\n\n   Preserve the header comment block; only modify the `active:` line.\n   If profiles already existed and the user declined activation, leave\n   `active_target.yml` untouched.\n\n### Confirm\n\nPrint a summary: profile path, active pointer (or \"unchanged\" if\nactivation was declined), Tegra family (T234 \u002F T264), whether\n`custom_carrier:` was recorded, and a reminder that downstream skills\nwill resolve to whichever profile is active. If the user authored\nmultiple profiles without activating, point them at `jetson-set-target`\nto pick one.\n\n**Next steps** (Setup → Customize chain):\n\n1. `\u002Fjetson-init-image` — extract the BSP and append `bsp_image:`.\n2. `\u002Fjetson-init-source` — clone the shared repos (and optionally\n   override `\u003Cworkspace>\u002FSource` if the user wants `source.root_path`\n   written into the profile).\n3. `\u002Fjetson-link-docs` *(optional)* — register paths to\n   pre-downloaded BSP \u002F schematic \u002F pinmux documents in the profile's\n   `documents:` block.\n\nThen, before any `customize-*` skill (Customize):\n\n4. `\u002Fjetson-generate-kb` — KB that customize-* skills consult for\n   target-specific file locations.\n5. `\u002Fjetson-derive-carrier` *(custom carriers only)* — materialize the\n   custom carrier's flash conf + supporting DTSIs from the reference\n   devkit. Required before per-knob customize-* on a custom carrier.\n\nIf a downstream skill triggered this run, tell the user to re-issue\ntheir original request; do not silently re-trigger it.\n\n## Prerequisites\n\n- `bsp-platforms-catalogue.md` and `platform_template.yaml` reachable\n  via the relative paths in the References section.\n- Write access to `target-platform\u002F` (and `target-platform\u002Factive_target.yml`\n  if activation is requested).\n- For \"what module\u002Fcarrier is this?\" lookups: `\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids`\n  on the booted device.\n\n## Limitations\n\n- Owns only `reference_devkit:`, `custom_carrier:`, and the\n  `active_target.yml` pointer; refuses to write `bsp_image:`,\n  `source:`, or `documents:`.\n- Will not invent SKUs, module IDs, custom carrier metadata, or flash\n  configs — records `NA` or aborts when the user does not know a\n  required value.\n\n## Troubleshooting\n\n- **User asks to switch instead of author** — refuse and route to\n  `jetson-set-target`; do not re-author an existing profile.\n- **Catalogue row not found for the product the user named** —\n  add the row to `bsp-platforms-catalogue.md` first; do not patch the\n  product list inside this skill.\n- **Required field stuck at `NA`** — downstream `customize-*` skills\n  may refuse; capture the missing value (read\n  `\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids`) and rerun.\n- **`active_target.yml` lost its comment block after activation** — a\n  non-round-tripping YAML writer was used; switch to `ruamel.yaml` and\n  restore from the template.\n\nSee [`references\u002Fgotchas.md`](references\u002Fgotchas.md) for the full\npitfalls list (catalogue\u002Ftemplate separation, NA handling, conf\ncollision rules, etc.).\n\n## References\n\n- [`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md) — product \u002F flash conf catalogue (the source of truth for the \"Pick the reference product\" and \"Pick the flash config\" steps).\n- [`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md) — the contract this skill writes to.\n- [`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml) — schema starter for a target profile (the source of truth for the \"Optional: add custom carrier details\" step).\n- [`..\u002F..\u002Freferences\u002Factive_target_template.yaml`](..\u002F..\u002Freferences\u002Factive_target_template.yaml) — schema starter for the active-target pointer.\n- [`..\u002Fjetson-set-target\u002FSKILL.md`](..\u002Fjetson-set-target\u002FSKILL.md) — sibling skill: switch the active pointer among already-authored profiles.\n- [`..\u002Fjetson-init-image\u002FSKILL.md`](..\u002Fjetson-init-image\u002FSKILL.md) — sibling skill: extract BSP image and author the `bsp_image:` block.\n- [`..\u002Fjetson-init-source\u002FSKILL.md`](..\u002Fjetson-init-source\u002FSKILL.md) — sibling skill: clone shared repos and (optionally) author the `source:` block.\n- [`..\u002Fjetson-link-docs\u002FSKILL.md`](..\u002Fjetson-link-docs\u002FSKILL.md) — sibling skill: author the `documents:` block by registering pre-downloaded files.\n","# Initialize Target Platform\n\n## Overview\n\nThis skill **authors** a new target-platform profile YAML — the\nwrite-side of the contract in\n[`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md). It uses\n[`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md)\nas the canonical product \u002F flash-config catalogue and\n[`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml)\nas the field schema.\n\nFlow is linear: pick a reference product + flash config, then\n**optionally** add custom-carrier details. The two contract cases —\nreference-only vs reference + custom carrier — are distinguished only\nby whether the user provides custom-carrier details; there is no\nup-front mode prompt.\n\n**Scope is `reference_devkit:` and `custom_carrier:` only.** Sibling\nskills own the other blocks: `bsp_image:` →\n[`jetson-init-image`](..\u002Fjetson-init-image\u002FSKILL.md); `source:` →\n[`jetson-init-source`](..\u002Fjetson-init-source\u002FSKILL.md); `documents:` →\n[`jetson-link-docs`](..\u002Fjetson-link-docs\u002FSKILL.md).\n\nOutputs: a new `target-platform\u002F\u003Cname>.yaml` and (by default) an\nupdated `active_target.yml` pointing at it. To switch among\nalready-authored profiles, use sibling `jetson-set-target`.\n\n## When to invoke\n\n- The user asks to create \u002F author \u002F add a new target platform profile.\n- A downstream skill refused with \"no active target\" **and**\n  `target-platform\u002F` contains no profile YAML files yet (otherwise\n  prefer `jetson-set-target`).\n- The user wants a target whose profile does not yet exist on disk.\n\n## Procedure\n\n### Quick-start prefill mapping\n\nFollow the shared\n[`quick_start_prefill` contract](..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md#quick_start_prefill-contract).\nThis skill consumes:\n\n- `quick_start_prefill.target.active_platform` as the selected catalogue\n  row when it resolves to exactly one product.\n- `quick_start_prefill.target.custom_carrier` as the custom-carrier\n  intent.\n\nIf `active_platform` resolves to one catalogue row, use it directly. Do\nnot re-ask reference-product or flash-config questions; use the row's\ndefault flash config unless the prefill names a catalogue variant. Ask\nonly when the prefill is missing, invalid, ambiguous, or names an unknown\nvariant.\n\n### How the skill consumes the template\n\nLoad\n[`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml)\nonce at skill startup and treat it as the schema for prompted blocks.\nEach placeholder value carries one of three sentinel markers:\n\n| Marker | Behavior |\n|---|---|\n| `\u003CREQUIRED: description>` | Prompt the user. Value must be provided; `NA` is accepted with a warning that downstream skills may refuse. |\n| `\u003COPTIONAL: 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). |\n| `\u003CDERIVED: description>` | Filled programmatically from `bsp-platforms-catalogue.md` and the user's product \u002F flash-config choice in the \"Pick the reference product\" and \"Pick the flash config\" steps. **Not prompted.** |\n\nUse the marker description as the prompt text verbatim. Match markers\nwith the regex `^\u003C(REQUIRED|OPTIONAL|DERIVED):\\s*(.*)>$` after YAML\nparsing strips the surrounding quotes.\n\nBlock-level inclusion (`custom_carrier`) is decided by the skill\nflow, not by markers — adding\u002Fremoving fields **inside** a block is\na template-only change.\n\n### Survey current state\n\n1. If `target-platform\u002F` does not exist, create it and copy\n   [`..\u002F..\u002Freferences\u002Factive_target_template.yaml`](..\u002F..\u002Freferences\u002Factive_target_template.yaml)\n   to `target-platform\u002Factive_target.yml` (note `.yml` extension).\n2. Read `target-platform\u002Factive_target.yml`.\n3. List `target-platform\u002F*.yaml` (excluding `active_target.yml`).\n\n| Situation | Action |\n|---|---|\n| 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). |\n| 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`). |\n| 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`. |\n| `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. |\n\n### Read the platforms catalogue\n\nRead [`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md).\nParse the **\"Product \u002F Chip \u002F SKU \u002F Flash Config Mapping\"** table — that\nis the source of truth for product names, CVM\u002FCVB SKUs, default flash\nconfs, and variant suffixes. Do **not** scan `Linux_for_Tegra\u002F*.conf`\nor parse conf filenames; the catalogue already collapses that.\n\n### Pick the reference product (baseline)\n\nPrint the full catalogue list before asking. Group rows by chip family\nand number every entry with stable indexes for this run. Build the list\nonly from `bsp-platforms-catalogue.md`; do not copy platform rows from\nexamples or other docs.\n\nBuild explicit shortcut choices from the printed list by taking the first\nrow in each chip-family group. Each shortcut label must include the\nfull-list index and product name, for example `Index 1 — Jetson AGX Orin\n64GB`. Do not hard-code product names; derive shortcuts from the parsed\ncatalogue rows. These shortcuts are the only explicit choices for this\nquestion. Manual index entry must use the tool's built-in `Type something`\ninput; do not add a third custom choice for manual entry.\n\nPrompt text:\n\n> Pick a platform shortcut, or choose Type something and type the numeric\n> index from the full platform list printed above. If your hardware is a\n> custom carrier with one of these Jetson modules, pick the closest\n> matching reference devkit as the baseline. Type cancel to cancel this\n> run.\n\nDo not show chip-family choices such as `T234 \u002F Orin family` or\n`T264 \u002F Thor family`. Do not show `Type index`, `Manual entry`, `Other\nplatform`, or any custom manual-entry choice. The only manual-entry path\nis the tool-provided `Type something` row. Do not add `Other` as a choice\nor paraphrase `Type something` as `Other` in prompt text. Do not accept\nproduct-name substring matches in this step; typed input must be a numeric\nindex from the printed full list or `cancel`. `skip` is not allowed\nbecause this skill cannot author a target profile without a reference\nplatform.\n\nResolve the shortcut or typed index to exactly one catalogue row. If the\ntyped index is out of range or invalid, show the valid index range and ask\nagain. If the user types `skip`, explain that `jetson-init-target`\nrequires a reference platform and ask again. If the user types `cancel`,\nstop without writing a profile.\n\n### Pick the flash config\n\nFrom the catalogue row, the **Default flash conf** is option `1`; the\n**Variants** column lists suffixes — option `2..N`. Reconstruct each\nvariant's full conf filename by appending the suffix to the default\nconf base. If a row says `(same as \u003Cother>)` in the Variants column,\nreuse the referenced row's variant list verbatim. Build this list only\nfrom the selected catalogue row.\n\nPrompt:\n\n> Pick a number, or press Enter to accept the default (`1`).\n\nIf the chosen row has no variants (`—` in the catalogue), proceed to\nthe \"Optional: add custom carrier details\" step with the default conf.\n\n**Edge cases:**\n\n- **Raw-conf variants** (catalogue marks `(raw)`). For Orin Nano,\n  `-a0-maxn (raw)` → `p3768-0000-p3767-0000-a0-maxn.conf`. Use the raw\n  filename verbatim.\n- **`(same as \u003Cother>)` placeholders.** Reuse the referenced row's\n  variants verbatim.\n\n### Optional: add custom carrier details\n\nAfter the baseline + flash config are chosen, resolve whether the profile\nshould record a custom carrier on top. If\n`quick_start_prefill.target.custom_carrier` is a valid concrete intent,\nconsume it directly:\n\n- `add_custom_carrier` → record `custom_carrier:` and collect the missing\n  carrier metadata below.\n- `no_custom_carrier` → omit `custom_carrier:` and proceed to the\n  \"Confirm\" step.\n- `keep_existing_custom_carrier` is valid only when editing an existing\n  active profile that already has `custom_carrier:`. Because this skill\n  authors a new profile, treat it as ambiguous and ask the custom-carrier\n  intent question below.\n- `skip` or a missing prefill value → ask the custom-carrier intent\n  question below.\n\nWhen intent is not already concrete, ask the user whether they also want\nto record a custom carrier on top using the `AskUserQuestions` UI. This\nis a bounded choice; show `add` and `skip` only:\n\n> Optionally add custom-carrier details for a customer-designed carrier\n> using this Jetson module? (`add` \u002F `skip`, default `skip`)\n\nIf the resolved intent is `skip`, proceed to the \"Confirm\" step with the\n`custom_carrier:` block omitted.\n\nIf the resolved intent is `add`, collect every still-missing\n`custom_carrier:` value through the `AskUserQuestions` UI. Do not collect\ncustom-carrier metadata with plain-text prompts, inline chat questions,\nfreeform summary confirmation, inferred defaults, or example values\npresented as selectable options. Split the collection into multiple\n`AskUserQuestions` forms if the UI question limit would otherwise be\nexceeded.\n\nFor the first `AskUserQuestions` form, ask `custom_carrier.name`,\n`custom_carrier.id`, `custom_carrier.sku`, and\n`custom_carrier.revision` in template document order. For these four\nfields, the only selectable path shown to the user must be the tool's\nbuilt-in `Type something` row. Do not add example values, \"Other\",\nguessed board IDs, guessed SKUs, common revision strings, or any explicit\ndomain options. These are customer-provided metadata: preserve them\nexactly as entered and do not require or validate any naming convention,\nprefix, case, character set, digit count, or SKU format. Validate only\nthat required fields are non-empty unless the user explicitly enters\n`NA`. `NA` is accepted per the contract for required fields; warn that\ndownstream skills may refuse if a missing field is required for their\nedit.\n\nAfter `custom_carrier.name` is known, collect\n`custom_carrier.flash_config` through a second `AskUserQuestions` form if\nit is still missing. Show the suggested default as the only explicit\nchoice and allow the built-in `Type something` row for a custom `.conf`\nfilename. Require a non-empty filename ending in `.conf`; do not derive\nit from board ID, SKU, or any guessed convention.\n\nField-specific behavior (defaults \u002F suggestions not expressible via\nmarkers alone):\n\n- `custom_carrier.flash_config` — suggest a default of kebab-cased\n  `custom_carrier.name + \".conf\"` (e.g. \"Acme Vision X1\" →\n  `acme-vision-x1.conf`).\n- `custom_carrier.name` — prompt: \"Type the customer-facing custom\n  carrier or product name exactly as you want it recorded. No format is\n  required.\" Use `Type something` only.\n- `custom_carrier.id` — prompt: \"Type the custom carrier board ID or\n  project ID exactly as you want it recorded. No format is required.\"\n  Use `Type something` only.\n- `custom_carrier.sku` — prompt: \"Type the custom carrier SKU or variant\n  identifier exactly as you want it recorded. No format is required.\"\n  Use `Type something` only; quote in the written YAML so numeric-looking\n  values and leading zeros survive.\n- `custom_carrier.revision` — prompt: \"Type the custom carrier revision\n  or build identifier exactly as you want it recorded, or press Enter to\n  omit it. No format is required.\" Use `Type something` only; omit when\n  skipped.\n\nIf the user does not know a value, suggest reading\n`\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids` on the booted target. If genuinely\nunavailable, accept `NA` for required fields or omit optional fields.\n\nThe template intentionally omits `custom_carrier.module` and\n`custom_carrier.chip_family` — module identity comes from\n`reference_devkit.module` (the same physical Jetson module plugs into\nboth carriers). Don't add them back.\n\n### Confirm\n\nShow the proposed YAML. Shape depends on whether the user added\ncustom-carrier details in the \"Optional: add custom carrier details\"\nstep. **Example:** see\n[`references\u002Fui-samples.md`](references\u002Fui-samples.md) for the\nreference-only and reference + custom-carrier YAML shapes, plus the\nnote on which sibling skill appends which block.\n\nSuggested filename:\n\n- **Reference-only:** kebab-cased product name from the selected\n  catalogue row, with `.yaml` appended. E.g. `Jetson AGX Thor T5000` →\n  `jetson-agx-thor-t5000.yaml`; `Jetson AGX Orin 32GB` →\n  `jetson-agx-orin-32gb.yaml`. Do not derive the filename from\n  `flash_config`; multiple products can share one default conf.\n- **With custom carrier:** kebab-cased `custom_carrier.name`. E.g.\n  \"Acme Vision X1\" → `acme-vision-x1.yaml`.\n\nUse the suggested filename without asking when it is unique and was\ngenerated from the selected platform or custom-carrier name. Print the\nfilename and continue. Ask only on collision, empty generated name,\nambiguous input, or explicit custom-filename request. Then handle\nactivation:\n\n- **Bootstrap case** (no profile YAMLs existed at the \"Survey current state\" step): **do not\n  prompt.** The new profile is the first one, so it is auto-activated\n  in the \"Write\" step. Tell the user this is happening so the auto-activation is\n  not silent.\n- **Profiles already exist**: ask whether to **activate** the new\n  profile (default: yes). Decline only if the user is authoring\n  multiple profiles to choose from later — they can activate any of\n  them with `jetson-set-target`.\n\n### Write (and optionally activate)\n\n1. Write `target-platform\u002F\u003Cfilename>.yaml`. If the file already\n   exists, ask before overwriting; never silently clobber.\n2. Edit `target-platform\u002Factive_target.yml` to set\n   `active: \u003Cfilename>.yaml` when **either** of the following holds:\n   - This was the bootstrap case from the \"Survey current state\" step (no profile YAMLs existed\n     before this run) — activation is automatic, regardless of any\n     prior user input.\n   - Profiles already existed and the user accepted activation in\n     the \"Confirm\" step.\n\n   Preserve the header comment block; only modify the `active:` line.\n   If profiles already existed and the user declined activation, leave\n   `active_target.yml` untouched.\n\n### Confirm\n\nPrint a summary: profile path, active pointer (or \"unchanged\" if\nactivation was declined), Tegra family (T234 \u002F T264), whether\n`custom_carrier:` was recorded, and a reminder that downstream skills\nwill resolve to whichever profile is active. If the user authored\nmultiple profiles without activating, point them at `jetson-set-target`\nto pick one.\n\n**Next steps** (Setup → Customize chain):\n\n1. `\u002Fjetson-init-image` — extract the BSP and append `bsp_image:`.\n2. `\u002Fjetson-init-source` — clone the shared repos (and optionally\n   override `\u003Cworkspace>\u002FSource` if the user wants `source.root_path`\n   written into the profile).\n3. `\u002Fjetson-link-docs` *(optional)* — register paths to\n   pre-downloaded BSP \u002F schematic \u002F pinmux documents in the profile's\n   `documents:` block.\n\nThen, before any `customize-*` skill (Customize):\n\n4. `\u002Fjetson-generate-kb` — KB that customize-* skills consult for\n   target-specific file locations.\n5. `\u002Fjetson-derive-carrier` *(custom carriers only)* — materialize the\n   custom carrier's flash conf + supporting DTSIs from the reference\n   devkit. Required before per-knob customize-* on a custom carrier.\n\nIf a downstream skill triggered this run, tell the user to re-issue\ntheir original request; do not silently re-trigger it.\n\n## Prerequisites\n\n- `bsp-platforms-catalogue.md` and `platform_template.yaml` reachable\n  via the relative paths in the References section.\n- Write access to `target-platform\u002F` (and `target-platform\u002Factive_target.yml`\n  if activation is requested).\n- For \"what module\u002Fcarrier is this?\" lookups: `\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids`\n  on the booted device.\n\n## Limitations\n\n- Owns only `reference_devkit:`, `custom_carrier:`, and the\n  `active_target.yml` pointer; refuses to write `bsp_image:`,\n  `source:`, or `documents:`.\n- Will not invent SKUs, module IDs, custom carrier metadata, or flash\n  configs — records `NA` or aborts when the user does not know a\n  required value.\n\n## Troubleshooting\n\n- **User asks to switch instead of author** — refuse and route to\n  `jetson-set-target`; do not re-author an existing profile.\n- **Catalogue row not found for the product the user named** —\n  add the row to `bsp-platforms-catalogue.md` first; do not patch the\n  product list inside this skill.\n- **Required field stuck at `NA`** — downstream `customize-*` skills\n  may refuse; capture the missing value (read\n  `\u002Fproc\u002Fdevice-tree\u002Fchosen\u002Fids`) and rerun.\n- **`active_target.yml` lost its comment block after activation** — a\n  non-round-tripping YAML writer was used; switch to `ruamel.yaml` and\n  restore from the template.\n\nSee [`references\u002Fgotchas.md`](references\u002Fgotchas.md) for the full\npitfalls list (catalogue\u002Ftemplate separation, NA handling, conf\ncollision rules, etc.).\n\n## References\n\n- [`..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md`](..\u002F..\u002Freferences\u002Fbsp-platforms-catalogue.md) — product \u002F flash conf catalogue (the source of truth for the \"Pick the reference product\" and \"Pick the flash config\" steps).\n- [`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md) — the contract this skill writes to.\n- [`..\u002F..\u002Freferences\u002Fplatform_template.yaml`](..\u002F..\u002Freferences\u002Fplatform_template.yaml) — schema starter for a target profile (the source of truth for the \"Optional: add custom carrier details\" step).\n- [`..\u002F..\u002Freferences\u002Factive_target_template.yaml`](..\u002F..\u002Freferences\u002Factive_target_template.yaml) — schema starter for the active-target pointer.\n- [`..\u002Fjetson-set-target\u002FSKILL.md`](..\u002Fjetson-set-target\u002FSKILL.md) — sibling skill: switch the active pointer among already-authored profiles.\n- [`..\u002Fjetson-init-image\u002FSKILL.md`](..\u002Fjetson-init-image\u002FSKILL.md) — sibling skill: extract BSP image and author the `bsp_image:` block.\n- [`..\u002Fjetson-init-source\u002FSKILL.md`](..\u002Fjetson-init-source\u002FSKILL.md) — sibling skill: clone shared repos and (optionally) author the `source:` block.\n- [`..\u002Fjetson-link-docs\u002FSKILL.md`](..\u002Fjetson-link-docs\u002FSKILL.md) — sibling skill: author the `documents:` block by registering pre-downloaded files.\n",{"name":5,"license":15,"version":44,"metadata":45,"description":7},"0.0.1",{"tags":46,"author":50,"domain":49,"data-classification":23},[47,48,49],"target-platform","configuration","meta","Jetson Team","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fjetson-init-target","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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add pattanation\u002FNorvik --skill jetson-init-target",{"tool":64,"command":65},"bunx","bunx skills add pattanation\u002FNorvik --skill jetson-init-target",{"tool":67,"command":68},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill jetson-init-target","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002FSKILL.md",true,[72,78,82,86,90,94],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"BENCHMARK.md","REFERENCE","参考文档",3812,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002FBENCHMARK.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fevals.json",4075,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002Fevals\u002Fevals.json",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fgotchas.md",3493,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002Freferences\u002Fgotchas.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fui-samples.md",1330,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002Freferences\u002Fui-samples.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"skill-card.md",3922,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002Fskill-card.md",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"skill.oms.sig","OTHER","其他",5057,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-init-target\u002Fskill.oms.sig",[101,134,159,183,205,220],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":116,"publishedAt":133},"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",[108,113],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000009","前端开发",[117,118,119,37,120,121,122,123,124,125,126,127,128,129,130,131,132],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":138,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":133},"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",[141],{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},[143,144,145,129,146,147,148,37,149,150,122,151,32,152,153,154,155,156,157,158],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":163,"licenseFileUrl":164,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":133},"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",[167],{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},[169,170,171,172,173,174,175,176,177,178,179,180,181,182],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":163,"licenseFileUrl":187,"sourceHtmlUrl":188,"categories":189,"keywords":192,"publishedAt":133},"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",[190,191],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},[193,118,194,180,195,128,196,197,198,175,199,37,200,201,202,32,203,181,204],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":163,"licenseFileUrl":209,"sourceHtmlUrl":210,"categories":211,"keywords":213,"publishedAt":133},"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",[212],{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},[214,180,215,195,216,198,217,175,203,218,219],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":163,"licenseFileUrl":224,"sourceHtmlUrl":225,"categories":226,"keywords":228,"publishedAt":133},"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",[227],{"categoryNo":114,"categoryName":115,"taxonomyType":111,"taxonomyTypeDesc":112},[229,180,195,230,172,231,232,233,214,234,235,236,237,238,239,37,240,32,241,242],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]