Add winml-cli skill#733
Conversation
Adds .claude/skills/winml-modelkit/SKILL.md — a Claude Code skill that teaches an agent to drive the `winml` CLI for the Build-Your-Own-Model (BYOM) pipeline across NPU/GPU/CPU execution providers. The body covers install (uv venv + uv pip install winml-cli), discovering the CLI via --help, the inspect -> export -> analyze -> optimize -> quantize -> compile -> perf pipeline, the config + build shortcut, hardware/EP mapping (QNN/OpenVINO/VitisAI/NvTensorRTRTX/DML/ CPU), in/out scope (classic DL vs generative), and the published-output principle that each winml command exposes outputs via -o or stdout while caches and internal byproducts are not supported outputs.
ModelKit now requires Python 3.11 exactly (>=3.11,<3.12). Updated the install section's venv command and the version pin language.
|
winml-cli not winml-modelkit |
There was a problem hiding this comment.
Two findings + a meta question on the SKILL.md location.
Meta concern: where should SKILL.md live? This PR ships it at .claude/skills/winml-modelkit/SKILL.md, which is the Claude Code convention. That's fine if Claude Code is the team's primary agent. But the same skill won't be picked up by other agents whose loaders look elsewhere (GitHub Copilot CLI looks under .github/skills/... or .github/extensions/... for example). If WinML CLI wants this skill discoverable by both Claude Code and Copilot CLI, the simplest options are: (a) commit a copy at .github/skills/winml-modelkit/SKILL.md too, accepting the maintenance cost, or (b) standardize on one agent and document the choice in the repo's contributor docs. Worth at least adding a CONTRIBUTING/README note explaining which agent this targets so future contributors don't put a second skill in a different location.
Moves the skill to .claude/skills/winml-cli/ to match the published package name (winml-cli on PyPI). Updates SKILL.md frontmatter `name:` to `winml-cli`, the H1 title to `winml CLI`, and replaces all "ModelKit"-branded prose in the body with the CLI's actual name.
@timenick: - `hub` is not a real winml subcommand. The actual command that prints catalog/hub info to stdout is `catalog`. Fixed both references (one in the published-output principle list, one in the gotchas section). The "don't fabricate flags" rule applies to subcommand names too — trains agents to invent. - The Hardware/EP status table was already 5 days stale on PR day. Replaced with prose that points at the README's Supported Hardware table as the canonical source and emphasizes `winml sys --list-ep` as ground truth on each machine. Matches the skill's own "read it live" philosophy and removes a drift surface that would have silently rotted between releases.
|
do we need RAI for this? |
Addresses review: SKILL.md is a public artifact that ships with the winml-cli package, not project-private Claude Code config. Hosting it under .claude/ implied this was dev-only / hidden tooling. Moving to skills/winml-cli/SKILL.md makes its scope match its role.
Asked Qianhao, FoundryTK did't do RAI for releasing skills before... |
The `winml-cli` slug collided with the published package name. Skills
are imperative agent instructions ("use the winml CLI"), so prefixing
the skill slug with `use-` disambiguates and makes the agent-facing
intent obvious.
Renamed both the directory and the frontmatter `name:` field.
Summary
Adds
skills/use-winml-cli/SKILL.md— a skill that teaches an agent to drive thewinmlCLI for theBuild-Your-Own-Model (BYOM) pipeline across NPU/GPU/CPU execution providers.