New ml backend dependency audit
Skill kjuhwa/skills-hub/skills/agents/new-ml-backend-dependency-audit
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill new-ml-backend-dependency-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run a Phase-0 dependency audit on a candidate ML library before writing any integration code, so PyInstaller and runtime surprises are caught early.
SKILL.md
3.4 KB, as published. Nobody here has run it
New ML backend dependency audit
When to use
You are about to add a new ML model/library (TTS, STT, image, anything torch-based) to an app that ships as a PyInstaller binary. Skipping the audit reliably produces 3+ patch releases chasing frozen-build breakage (typechecked decorators, missing data files, hardcoded system paths).
Steps
- Clone the model library into a throwaway directory (
/tmp/engine-research). Do NOT install it into the main venv yet. - Grep the clone (and its transitive dependencies) for every pattern that breaks frozen builds:
@typechecked/inspect.getsource/torch.jit.script— forces--collect-all <pkg>because.pycfails source reads.importlib.metadata.version(/pkg_resources.get_distribution(— forces--copy-metadata <dist-name>.lazy_loader.attach/.pyistubs — forces--collect-allfor the stubs.- Hardcoded
/usr/share/.../data_path = Path(__file__).parent / "data"— forces env var fallback in the frozen entrypoint. torch.load(...)withoutmap_location=— forces a monkey-patch when CPU build loads CUDA-tensor checkpoints.token=Truein HF calls — forcessnapshot_download(token=None)+from_local()so users without an HF login can run the app.
- Produce a written audit covering:
a. PyPI vs git-only dependencies.
b. PyInstaller flags needed (
--collect-all,--copy-metadata,--hidden-import). c. Runtime data files (.pth.tar,.yaml,.json, G2P dictionaries) that must be bundled. d. Native libraries with hardcoded paths (espeak-ng, piper_phonemize, misaki) and the env vars needed to redirect them. e. Monkey-patches (torch.load, float64 casts, MPS workarounds). f. Sample rate expected by the model and any sample-rate-conversion needs. g. Model download method (from_pretrainedvssnapshot_download + from_local) and whether it respectsHF_HUB_OFFLINE. - Build and test model load + a single inference in the throwaway venv on CPU. Only then start the real integration.
- Test again with a clean HuggingFace cache so you catch download-path bugs that a warm cache hides.
Counter / Caveats
- Do NOT skip this audit "because the library is small" — the smallest lib can pull in 400 MB of descript-audiotools transitives.
- Upstream pretrained weights can move between HF repos; pin the exact
revision=in the download call to make cache behavior reproducible. - Nightly PyTorch is not shippable for releases (non-deterministic, regressions between runs). If a library requires nightly, prefer
TORCH_CUDA_ARCH_LIST=...+PTXor wait for a stable support window. - Keep the audit doc in the repo (e.g.
docs/engine-audits/<engine>.md) — it becomes the next maintainer's starting point and makes version upgrades routine.
Source references: .agents/skills/add-tts-engine/SKILL.md (Phase 0 / the lessons table from v0.2.3).