What does this skill do, and when should you use it?
This skill helps users turn a LoRA into a browser-based Gradio demo on Hugging Face Spaces. It reads the LoRA repository and model card, determines the base model, task, trigger words, and inference settings, then designs a task-specific UI and diffusers workflow. The default target is a private Space using ZeroGPU hardware. It has first-class reference support for Qwen-Image, LTX, and Krea 2 families; other base models require an explicit analogy-based approach or a stop.
Reads files and model-card content from a LoRA repository on the Hugging Face Hub; selects and verifies the base model pipeline class; designs a Gradio interface around the LoRA's task and inputs; writes app.py, requirements.txt, and README.md; creates a private Gradio Space and uploads those files; configures HF_TOKEN for private or gated models; waits for the build, checks the endpoint signature, and runs one real inference smoke test.
- A LoRA author has trained a Qwen-Image adapter and wants a browser-based image-generation demo.
- A user has an LTX video LoRA for a specialized task such as pose control or aspect-ratio extension and needs a matching interface.
- A team hosts a private or gated LoRA on the Hub and needs to publish a private Space that can authenticate at runtime.
- A model author wants the model card's trigger words, steps, guidance, LoRA scale, and examples reflected in the demo.
How do you install this skill?
- Do not paste a write-scoped HF token into ordinary chat; use protected secret input and prefer least-privilege, short-lived credentials.
- Publishing has external side effects and should occur only after reviewing app.py, requirements.txt, and README.md together; no explicit rollback or revocation workflow is documented.
- Core operation depends on Hugging Face Hub/Spaces, ZeroGPU, remote models, and potentially CDNs; mainland-China reachability and stability are not established.
- git diffusers, Gradio, and model-pipeline APIs may drift; pin verified versions and add real CI, startup, and end-to-end tests.
- Shell / CLI
- Network access
- Local filesystem
PythonHugging Face HubGradioPyTorchdiffuserstransformersacceleratepeftsafetensorsspaces
From the huggingface/skills repository, copy or symlink the skills/huggingface-lora-space-builder folder into a standard Codex .agents/skills location, such as $REPO_ROOT/.agents/skills or $HOME/.agents/skills. The README does not document a separate installation command for this individual skill.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/huggingface/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/huggingface-lora-space-builder" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Build and publish a private Gradio Space for my Hugging Face LoRA `username/my-lora`.
After installation, give the coding agent a request such as: "Build and publish a private Gradio Space for my Hugging Face LoRA username/my-lora." For a private or gated LoRA, the skill first checks existing authentication and asks for a write-scoped Hugging Face token only if needed. It prepares app.py, requirements.txt, and README.md for one batched review before publishing.
What are this skill's strengths and limitations?
- Shapes the UI around the specific LoRA task instead of using a generic demo template.
- Verifies the pipeline class against the base model card, reducing variant and compatibility errors.
- Covers private Space creation, ZeroGPU configuration, dependency derivation, authentication, and upload.
- Requires a post-build endpoint check and a real inference smoke test.
- The LoRA must be available on the Hugging Face Hub, and publishing generally requires a write-scoped token.
- First-class reference support is limited mainly to the Qwen-Image, LTX, and Krea 2 families.
- ZeroGPU availability depends on a PRO, Team, or Enterprise account; otherwise the Space may fall back to CPU.
- The supplied material provides no independent test suite or cross-platform validation results.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| LoRA Space Demo Builder this page | 51 · Use with care | ★ 11k | 18d ago | Apache-2.0 |
| Hugging Face Spaces Builder | 50 · Use with care | ★ 11k | 18d ago | Apache-2.0 |
| Hugging Face ZeroGPU Builder | 56 · Use with care | ★ 11k | 18d ago | Apache-2.0 |
| HF Model Trainer (TRL on Hugging Face Jobs) | 52 · Use with care | ★ 38k | 14d ago | MIT |
| Azure OpenAI Deployment Assistant ✓ Microsoft · Official | 52 · Use with care | ★ 2.7k | 3mo ago | MIT |
Compared with hf-cli, which the README recommends for general Hugging Face Hub operations, this skill is narrower: it focuses on building and publishing a Gradio Space for a user-provided LoRA rather than managing the broader range of Hub resources.
How did FollowSkills review this skill?
The skill requires private Spaces, batched approval, input validation, and discloses some data flow and dependencies. However, it asks users to paste a write-scoped HF token, uses broader-than-necessary permissions, and lacks secure secret-entry guidance, revocation/rollback, post-publication cleanup, and complete data-handling disclosure. There is no evidence of malware, credential theft, or covert exfiltration, so the score is moderate but materially reduced.
Pipeline selection, dependency derivation, and several loading-failure categories are described in useful detail. Still, this review is static only, with no executable tests; key paths depend on moving git dependencies, evolving Gradio APIs, external model cards, and remote services, limiting reproducibility. The score follows the static ceiling.
Trigger conditions, five task families, LoRA-specific UI adaptation, and unsupported-model boundaries are relatively clear. Chinese-language support is not specified, and core operation depends on Hugging Face Hub/Spaces and ZeroGPU without evidence of mainland-China reachability. Some decisions also require live version or documentation checks.
The documentation is well structured and includes progressive disclosure, examples, dependency guidance, and known pitfalls; repository metadata supplies Apache-2.0 licensing. It does not clearly identify a maintainer, versioning policy, changelog, pinned reproducible dependency set, or update commitment, and external moving-target references add maintenance risk.
The intended output, file set, approval step, and private publication result are clearly defined, so the core task is plausible. No committed demo artifact, runtime result, or test coverage is provided, leaving actual usability, publication success, and marginal benefit over manual implementation unverified. The score therefore does not exceed the static ceiling.
Concrete snippets, failure categories, and parameter guidance provide limited auditability. There is no skill-specific test suite, CI coverage, pinned reproduction record, or third-party execution evidence; important claims remain primarily author assertions, so only a low score is justified.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →