Localized reading guide

huggingface-lora-space-builderPurpose, usage and source

Build and publish a Gradio demo on Hugging Face Spaces for a user-provided LoRA. Use when someone asks to create, generate, ship, or publish a Space, demo, Gradio app, or playground for a LoRA — including LoRAs for Qwen-Image, Qwen-Image-Edit, LTX-Video, Wan, FLUX, SDXL, or other diffusion base models. Also triggers when someone describes a LoRA they trained or hosts on the Hub and wants to share it. Covers picking the right base pipeline and diffusers inference recipe, designing a UI tailored to the LoRA's task and inputs (Union/multi-task control, edit, video, image, etc.), respecting model-card recommendations (trigger words, steps, guidance, LoRA scale, example inputs), and shipping to ZeroGPU hardware as a private Space by default.

Source retrieved: 2026-10-29

Source repository: huggingface/skills
SKILL.md: skills/huggingface-lora-space-builder/SKILL.md
Repository stars: 11,241
Repository updated: 2026-10-30
Categories: Design
Last collected: 2026-10-31 10:38 UTC+08:00

License: Apache-2.0

Source SKILL.md

Workflow excerpts are reading aids, not executable instructions from Codez. No third-party Skill was run to produce this page.

The purpose and workflow passages below are upstream material, organized and translated for reading. They are distinct from the separately labeled Codez editorial analysis.

What this Skill does

How the upstream workflow works

Workflow

Work through these phases in order. Information gathered in one phase decides the next. Gather the LoRA info needed to pick a pipeline and design a UI. Pick the base pipeline and inference recipe. Design the UI for this specific LoRA's task and inputs.

Upstream passage · L24 ↗

Gradio LoRA Space Builder

Build and publish a Gradio demo on Hugging Face Spaces that runs inference with a user-provided LoRA. Use whenever someone asks to create, generate, ship, or publish "a Space", "a demo", "a Gradio app", or "a playground" for a LoRA — whether the base model is Qwen-Image, Qwen-Image-Edit, LTX, or another diffusion model. Also use when someone describes a LoRA they trained or hosts on the Hub and wants to share it. The default target is ZeroGPU hardware and the default inference library is diffusers when the base model supports it. The output is a real, published Space (private by default) that the user can try in the browser, not a local script.

Upstream passage · L6 ↗

What "good" looks like for these demos

The demo should feel handcrafted for this specific LoRA, not a generic template with the LoRA bolted on. Two LoRAs that share a task can still need different demos: a pose-control video LoRA and an outpainting video LoRA both take video in and produce video out, but the inputs the user provides, the preprocessing, and the controls are completely different. Recognizing that is the central job here. Concretely, a good demo:

Upstream passage · L12 ↗

Upstream passage · python ↗

from huggingface_hub import HfApi, get_token

cached_token = get_token()  # picks up HF_TOKEN env var or cached CLI login
if cached_token:
    try:
        info = HfApi().whoami(token=cached_token)
        username = info["name"]
        # info also has fine-grained token scope info if applicable
    except Exception:
        cached_token = None  # token exists but is invalid/expired

Requirements and setup

`requirements.txt`

Don't ship a fixed minimal list and hope for the best. The "minimal" list works for plain T2I LoRAs and breaks the moment the base model has a vision-language text encoder, video output, or any non-trivial preprocessing. Derive requirements.txt from what the Space actually needs, in this order: Every top-level non-stdlib import in app.py. If app.py does import cv2, requirements.txt has opencv-python. If it does from controlnet_aux import OpenposeDetector, requirements.txt has controlnet-aux. Walk the imports mechanically. (Note the exclusions in the next paragraph — some imports are runtime built-ins and don't need to be listed.)

Upstream passage · L188 ↗

Limits and quality checks

No separate limits passage was selected from this file. This does not mean the Skill is safe for every input or environment. Review the complete source and validate your own result.

Start with a safe trial

Check the supported host and the repository installation instructions. Keep the Skill directory and its referenced scripts, assets and documentation together; SKILL.md alone may omit dependencies.
Give the agent your real input, desired output and acceptance criteria. Invocation syntax and available tools depend on the host; this site does not assume a universal install command.
Try the source workflow in a disposable project or on a copy. Review operations that change files, remote services or billable resources before allowing them.
Validate the output against the source quality checks and your own requirements. A successful trigger or a high repository Star count does not establish a correct result.

Skill format and directory specification ↗

Read further in the source

Translation and scope

This reading guide selects passages from the pinned upstream SKILL.md. Translation is assisted. It is not a complete manual or a claim of tested compatibility. Read the original and its referenced files before use.

This introduction refers to the pinned version below; current repository activity and collection time are shown separately.

Pinned source: Read the original ↗
Source retrieved: 2026-10-29T09:32:23Z
Source commit: fabc634a893f62ad5c2039830397efa35fa62715
Source SHA-256: 7192d4a44172609eb073334e0410aff1d3b9134f82b94f1329435ca7fcfa0ad2

Back to the full Skill catalog