LoRA Space Demo Builder
Build and publish a tailored Gradio Space for a Hugging Face LoRA.
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.
- 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.
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.
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 do you install this skill?
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.
How do you use this skill?
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.
How does this skill compare with similar options?
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.