
Jetson Link Docs
OfficialFreeEasily bind Jetson reference docs to your profiles.
Free · Opens the source repo
What Jetson Link Docs does
The Jetson Link Docs skill facilitates the integration of pre-downloaded Jetson reference documents into the active profile documents block of Jetson/IGX target-platform profiles. This skill is particularly useful for developers and engineers working with NVIDIA Jetson platforms, as it allows them to register document paths for downstream skills that rely on these references. It streamlines the process of linking essential documentation such as developer guides, design guides, and schematics, ensuring that all necessary resources are readily accessible for further development tasks.
This skill operates by writing to the documents: block of the active profile's YAML file. It performs a series of automated checks to match document slots with files located in a specified directory on disk. Users must have their documents staged on disk prior to invoking this skill, as it does not handle downloading or fetching files. Instead, it focuses solely on registering pointers to existing files, which helps maintain an organized workflow when working with multiple documents.
To use Jetson Link Docs effectively, users should invoke it after initializing the target with /jetson-init-target and ensuring that the relevant documents are available on disk. The skill will walk users through the document registration process, attempting to auto-bind each document slot based on case-insensitive glob matching. If a document cannot be matched automatically, the skill provides manual prompts to assist users in completing the registration.
Overall, Jetson Link Docs is ideal for developers who need to manage documentation efficiently within their Jetson projects. By simplifying the process of linking documents, it allows users to focus on development tasks without the distraction of manual document management.
When to use it
Use this skill after staging Jetson documentation on disk and initializing the target profile.
When not to use it
Avoid using this skill if you need to download documents or if the required files are not present on disk.
What you can build with it
Registering New Documents
After adding new Jetson documentation to your workspace, use this skill to quickly register the document paths in your active profile.
Updating Existing Profiles
If you need to change or remove document references in an existing Jetson profile, this skill allows you to do so efficiently.
Resolving Missing Document Errors
When a downstream skill reports missing documents, invoke this skill to rectify the issue by ensuring all necessary documents are linked.
How to install Jetson Link Docs
View source1. Install with the skills CLI
npx skills add nvidia/skills/jetson-link-docs --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiajetson-link-docs
Overview
This skill writes the documents: block of the active Jetson /
IGX target-platform profile YAML so downstream skills
(/jetson-generate-kb, /jetson-customize-pinmux, camera / pcie /
uphy, etc.) can resolve doc paths by name. It walks the user through
every document slot in the profile schema, tries to auto-bind each
slot to a file under <documents.root_path>/ via case-insensitive
glob matching, and writes the resulting paths back into the active
profile.
Scope is registering pointers only — this skill does not fetch
or download. The files must already exist on disk under
<documents.root_path>/.
When to invoke
- After
/jetson-init-targetfinishes and the user has documents on disk to register. - The user wants to add, change, or remove document references on an existing profile.
- A downstream skill (e.g.
jetson-generate-kb) reports "no documents recorded" and the user wants to fix that.
Procedure
Resolve the active target
Resolve the active profile + <workspace> per the contract in
../../context/target-platform-contract.md.
Cache the loaded profile in memory — this skill mutates it in
the "Write the documents: block back to the profile" step.
Load the document-slot schema
Load
../../references/platform_template.yaml.
Parse the documents: block. Each per-document field is marked
<OPTIONAL: description>. Use the marker description as prompt text
verbatim. Match markers with the regex
^<(REQUIRED|OPTIONAL|DERIVED):\s*(.*)>$ after YAML parsing strips
surrounding quotes.
Skip custom_carrier_schematic and custom_carrier_pinmux_xls
entirely when the active profile has no custom_carrier: block —
both are meaningless without one. This filter applies through the "Scan and auto-match" and "Manual prompts for unmatched fields" steps.
Resolve documents.root_path
Default: <workspace>/Documents. If the profile already records
documents.root_path, use it. Otherwise, if <workspace>/Documents/
exists, use it (the field is omitted from the written profile —
downstream skills fall back to the workspace default). If neither is
available, prompt the user for an absolute path, or accept Enter /
cancel to skip the auto-scan. A user-provided path that doesn't
exist is treated as skipped (warn, don't refuse — the field is
OPTIONAL); manual prompts in the "Manual prompts for unmatched fields" step still run.
Resolve the product token
Read the Product Token column from
../../references/bsp-platforms-catalogue.md
for the row matching reference_devkit.name. The token is a
case-insensitive glob fragment (e.g. *orin*nano*, *agx*thor*)
consumed by the fallback patterns in the "Scan and auto-match" step.
If reference_devkit.name has no row in the catalogue, log a warning
and proceed without a product-token fallback — the "Scan and auto-match" step still works
with strictly SKU-keyed matching.
For custom carriers, derive <custom-token> from custom_carrier.name
using this recipe: lowercase, replace each space with *, wrap in
* on both ends. E.g. "Acme Vision X1" → *acme*vision*x1*.
Scan and auto-match
Skip this step entirely if documents.root_path did not resolve in
the "Resolve documents.root_path" step (no scan target → no auto-suggest; fall through to manual
prompts in the "Manual prompts for unmatched fields" step).
Scan the directory once (one level deep) and try to auto-match each
remaining <OPTIONAL:…> field using the case-insensitive globs below.
Use the lower-case module.id / carrier.id / custom_carrier.id
strings from the profile in the SKU column.
| Field | SKU glob (primary) | Product-token glob (fallback) |
|---|---|---|
bsp_developer_guide | *developer*guide*.pdf, *BSP*guide*.pdf | (no fallback — pattern is product-agnostic) |
soc_tech_ref_manual | *TRM*.pdf, *tech*ref*manual*.pdf | (no fallback — same) |
module_data_sheet | *<module.id>*data*sheet*.pdf, *<module.id>*datasheet*.pdf | <token>data*sheet*.pdf, <token>datasheet*.pdf |
module_design_guide | *<module.id>*design*guide*.pdf, *<module.id>*PDG*.pdf | <token>design*guide*.pdf, <token>PDG*.pdf |
module_thermal_design_guide | *<module.id>*thermal*.pdf (covers "Thermal Design Guide" / "TDG") | <token>thermal*.pdf |
module_schematic | *<module.id>*schem*.pdf | <token>schem*.pdf |
carrier_board_spec | *<carrier.id>*board*spec*.pdf, *<carrier.id>*spec*.pdf | <token>carrier*spec*.pdf |
carrier_schematic | *<carrier.id>*schem*.pdf | <token>carrier*schem*.pdf |
custom_carrier_schematic | *<custom_carrier.id>*schem*.pdf (only if custom carrier) | <custom-token>schem*.pdf (only if custom carrier) |
ref_devkit_pinmux_xls | *<carrier.id>*pinmux*.xls* (matches .xls, .xlsx, .xlsm) | <token>pinmux*.xls* |
custom_carrier_pinmux_xls | *<custom_carrier.id>*pinmux*.xls* (only if custom carrier) | <custom-token>pinmux*.xls* (only if custom carrier) |
<token> is the catalogue-resolved product token; <custom-token>
is derived from custom_carrier.name per the "Resolve the product token" step. Tokens already
include leading/trailing *, so the table does not repeat them.
Match policy per field
For each field that has auto-match results:
- Take the union of hits across the SKU glob and the product- token glob, then deduplicate by absolute path — a file matched by both globs counts once.
- Exactly 1 unique hit → show the path and prompt
use this? (yes/no, default yes). Onyes, record it and skip the manual prompt for that field. Onno, fall through to the manual prompt in the "Manual prompts for unmatched fields" step. - 0 hits → skip auto-suggest entirely for that field; fall through to the "Manual prompts for unmatched fields" step.
- 2+ unique hits → present them as a numbered list in the "Manual prompts for unmatched fields" step so
the user can pick by number rather than typing a path; include a
skip / NAoption. Never silently bind a multi-hit candidate. - Never silently bind without user confirmation — wrong-schematic / wrong-pinmux bindings are real and costly.
If documents.root_path is folder-organised one level deeper than
flat (NVIDIA archives often are: Schematics/, Design-Guides/,
Pinmux/, etc.), the file globs may return zero hits even when the
right documents exist. v0.2 only scans one level deep — when 0 hits
is suspicious (documents.root_path exists but no fields auto-bound),
surface the limitation to the user and offer to fall through to
manual prompts.
Manual prompts for unmatched fields
For every field that wasn't auto-bound (and wasn't filtered out in
the "Load the document-slot schema" step), prompt using the marker description from the "Load the document-slot schema" step as prompt
text, in document order. Accept Enter and NA interchangeably as
"skip this field". When the "Match policy per field" step produced 2+ candidate hits for a
field, present them as a numbered list with a skip / NA option
rather than asking for a free-text path.
Validate that user-provided paths exist on disk (warn if not, but do
not refuse — the user may be recording a planned path). URLs (values
starting with http://, https://, or ftp://) are accepted
verbatim and not validated.
Write the documents: block back to the profile
Edit target-platform/<active>.yaml in place. Preserve all other
top-level blocks (reference_devkit:, custom_carrier:,
bsp_image:, source:) and their comments verbatim. Write only the
fields the user provided — omit skipped / NA fields entirely (no
NA placeholders, no empty keys).
Edge behavior: when every field was skipped (including
documents.root_path), drop the documents: block entirely from
the profile — never write documents: {} or a block of NA values.
When only documents.root_path was provided (no per-document
binding), record it alone — the path has value as a hint for future
re-runs. On re-run with an existing documents: block, merge:
existing bindings are preserved unless the user picks a new file or
NA; newly bound fields are added.
Confirm
Print a summary:
- Profile path written.
documents.root_path— resolved value (or "default — omitted").- Auto-bound fields: count + per-field one-line list.
- Manually entered fields: count + list.
- Skipped fields: count.
- A reminder that
jetson-generate-kbre-readsdocuments.*and should be re-run if a KB exists.
If a downstream skill triggered this run, tell the user to re-issue their original request; do not silently re-trigger it.
Gotchas
- Active profile must exist. This skill writes back to whichever
profile is active. If no profile is active, refuse and route to
jetson-set-target/jetson-init-target. - Product-token globs are intentionally broad. A token like
*orin*nano*matches both Orin-Nano-specific docs and combined Orin-NX/Nano docs (e.g.Jetson-Orin-NX-Nano-Design-Guide_…). That is usually correct for module-side docs (NVIDIA ships combined manuals), but verify on schematic / pinmux / spec fields where wrong-product binding is costly. - Update
bsp-platforms-catalogue.mdwhen adding new product rows. The Product Token column is consumed by the "Resolve the product token" step; a missing token degrades the auto-scan to SKU-only matching (the skill warns and continues, but doc-richdocuments.root_pathscans will degrade silently from "5 auto-binds" to "fewer auto- binds"). - Use a round-tripping YAML loader. the "Write the
documents:block back to the profile" step mutates an existing YAML file. Plainyaml.safe_load+yaml.safe_dumploses comments, block ordering, and quoting style — useruamel.yamlor equivalent so hand-edited fields and comments survive. - Re-runnable. Re-running merges new bindings; existing bindings are preserved unless the user explicitly changes them. Safe to invoke as part of a profile refresh.
Prerequisites
- Active target profile resolved per
../../context/target-platform-contract.md. - Documents available either under the recorded
documents.root_path, under default<workspace>/Documents/, or as user-provided paths / URLs during manual prompts. A missing root only disables auto-scan; it is not a hard prerequisite. ruamel.yamlor another round-tripping YAML writer for the profile edit step.
Limitations
- Registers pointers only; never downloads, copies, or renames files.
- Per-document field set is fixed to the schema in
../../references/platform_template.yaml— no ad-hoc keys. - Glob matching is filename-only; bad filenames in
documents.root_pathwill under-bind and require manual selection.
Troubleshooting
documents.root_pathmissing — auto-scan is skipped. Provide an absolute root path, enter individual document paths / URLs manually, or skip the fields you do not want to bind.- Multiple files match a single slot — the skill stops and prompts;
pick or rename the file. Example: two
Jetson-Linux-Developer-Guide*.pdffiles → keep the active version, rename the stale one. - Profile comments lost after write — a non-round-tripping YAML
writer was used; switch to
ruamel.yamland rerun against a fresh pristine copy. - Validation fails because a binding points outside
documents.root_path—documents.*are relative paths only; move the file under the root and retry.
References
../../context/target-platform-contract.md— target-platform contract; this skill consumes and mutates the active profile.../../references/bsp-platforms-catalogue.md— source of the Product Token column for the "Resolve the product token" step.../../references/platform_template.yaml— schema for thedocuments:block (source of truth for prompts and field list).../jetson-init-target/SKILL.md— sibling skill that authors target identity (reference_devkit:, optionalcustom_carrier:).../jetson-init-image/SKILL.md— sibling skill that authorsbsp_image:.../jetson-init-source/SKILL.md— sibling skill: clones shared repos and handlessource.root_pathoverrides.../jetson-generate-kb/SKILL.md— sibling skill: consumes thedocuments:block this skill writes.
Frequently asked questions about Jetson Link Docs
Similar skills
Markdown to HTML Conversion
Efficiently convert Markdown documents to HTML.
Code Tour
Create structured walkthroughs for codebases.
Acquire Codebase Knowledge
Streamline onboarding with comprehensive codebase documentation.
Documentation & Modernization
Streamline codebase documentation and modernization planning.
Azure Resource Visualizer
Generate architecture diagrams for Azure resources.
CLAUDE.md Improver
Optimize your CLAUDE.md files for better project context.
