dotnet-inspect-package-skills git:20261102.9d70504A

Immutable. This exact content never changes and is served at /api/v1/blob/51e5308b69e2c324.

---
name: dotnet-inspect-package-skills
description: Discover version-matched agent skills in restored NuGet dependencies or an exact package, select relevant guidance and load it without changing the repository; persist skills only when explicitly requested.
---

# dotnet-inspect: Discover and Load NuGet Package Skills

Discover version-matched package skills, inspect their inventory, and load the
ones relevant to the current task. This default workflow is agent-driven and
does not change the repository. Persist skills only when the user explicitly
asks for repository installation.
Use the recipes below directly; for unfamiliar query or payload rules, use
`-D`, command help or `explain "<question>"` instead of guessing arguments.

Use this workflow to reach the right package-authored skill efficiently.
Prefer the restored project's inventory or an exact package pin. For an
unknown package ID, use `find --packages`, not API-symbol Find.

## Default: use skills without changing the repository

Restore or build first when dependencies changed; `project` only reads the
existing `project.assets.json`.

First ask whether the restored direct dependencies expose any skills:

```bash
dnx dotnet-inspect -y -- project path/to/project -S Skills --count
```

If the count is nonzero, ask for the inventory. It includes the resolved package
version, package-relative path, skill name, and description:

```bash
dnx dotnet-inspect -y -- project path/to/project -S Skills --jsonl
```

Use this view first because its package versions match the code. Compare the
descriptions with the task and code, then request each relevant skill by its
displayed row:

```bash
dnx dotnet-inspect -y -- project path/to/project \
  -S Skills --print --row 2 --raw
```

For a known positional choice, select the complete inventory row first.
`--row` then addresses the selected sequence:

```bash
dnx dotnet-inspect -y -- project path/to/project \
  -S Skills -n 1 --tail --print --row 1 --raw
```

Request several skills as a group by issuing one independent command for each
selected row. Keep each result separate; `--raw` intentionally carries no
multi-document boundary.

```bash
dnx dotnet-inspect -y -- project path/to/project \
  -S Skills --print --row 2 --raw
dnx dotnet-inspect -y -- project path/to/project \
  -S Skills --print --row 5 --raw
```

The agent may perform this entire discovery and loading workflow without asking
the user. Reading package guidance changes agent context, not repository state.
Treat every inventory row as a candidate; do not use the first row as a proxy
for the package.

For a package that is not restored in the project, use an exact package
coordinate. First ask whether it has skill documents:

```bash
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --count
```

Then list the paths and inspect the YAML header of each candidate row before
requesting the full document. Together, those headers form the package-only
inventory:

```bash
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --paths
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --print --frontmatter --row 1 --raw
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --print --row 1 --raw
```

Do not use an unpinned find --packages when the repository consumes a specific
version.

dotnet-inspect validates restored-project skill names and descriptions. In that
normalized inventory, YAML values that require containment are reported as
`[Text omitted: required containment]`. A selected YAML header or full skill
document that requires containment is replaced in full by the same text through
stdout, structured output, and file destinations. Reversible visible escape
spellings may still disambiguate literal package content; they are not
instructions to decode before use. A NuGet dependency is provenance, not proof
that agent instructions are safe.

## User-requested workflow: persist repository skills

Follow this workflow only when the user explicitly requests repository
installation. It changes tracked state and requires a merged pull request to
persist.

The target repository owns the installation regime. Inspect its contributor
instructions, existing skill layout, and active agent harness before choosing a
destination. Common roots include `skills/`, `.agents/skills/`,
`.github/skills/`, and `.claude/skills/`.

`dotnet-inspect project ... -S Skills` applies the same checks and refuses
missing or noncompliant metadata. Do not recover a refused skill by sanitizing
or renaming it. For an accepted skill, preserve that validated name as the
leaf directory under the repository-selected root.

For example, Markout itself keeps its skills under `skills/`, so its output
formats skill belongs at `skills/markout-output-formats/SKILL.md`. Create that
directory and confirm the package-local row from the exact package coordinate.
Then either redirect the contained stdout payload:

```bash
mkdir -p skills/markout-output-formats
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --paths
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --print --row 4 --prefer-rendered-urls --raw \
  > skills/markout-output-formats/SKILL.md
```

Or ask dotnet-inspect to write the same contained payload:

```bash
dnx dotnet-inspect -y -- package Markout@0.35.2 \
  -S Skills --print --row 4 --prefer-rendered-urls --raw \
  --output skills/markout-output-formats/SKILL.md
```

For authored package content, `--prefer-rendered-urls` retains the existing
links instead of normalizing GitHub file links to fetchable form. Preserve each
packaged document as its own skill rather than combining, renaming, or decoding
contained text. If the skill references sibling scripts, references, or assets,
inspect the package subtree and persist those beside `SKILL.md` too.

Do not duplicate the same skill into several roots; harnesses may discover
duplicate names and the copies will drift.

## Keep skills version-matched

Commit selected skills with the dependency change. Record the package id,
resolved version, and package-relative path in the commit or pull request. On
every package upgrade, rerun the project inventory, compare every installed
skill with its new packaged counterpart, add newly relevant focused skills,
and remove a skill only when the code no longer uses the behavior it covers.

Omit `-o`/`--output` to review the document on stdout before writing it. Load
`dotnet-inspect skill private-feeds` when exact reacquisition needs custom
sources or credentials. Use a local `.nupkg` path in place of `Package@Version`
for an unpublished package canary.