Higgsfield Websites

Higgsfield AIOfficialPublished by Higgsfield AI

Skill
Workflow
Software development
MIT
Medium risk
Has scripts

From the author

Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1/R2/KV/DO/Containers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references/website-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references/app-flow.md), `game` (realtime multiplayer rooms — references/game-flow.md). Routes to the right flow; each carries its own rules and deploy/publish gates. Use when: "build me a website", "make a landing page", "create a web app", "build a SaaS dashboard / portfolio", "make me a game", "deploy this site", "publish". Also owns GAME ART: "make a spritesheet", "tileable texture", "animate a 3D character", game music/SFX — see the game-* references. NOT for: single image/video/audio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).

— the description by Higgsfield AI

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Higgsfield website builder is a comprehensive CLI tool for managing the full lifecycle of web projects. It supports three distinct product types: standalone websites, Higgsfield-integrated apps, and multiplayer browser games. Each project is built as a React 19 and TanStack Start SSR application deployed to a single Cloudflare Worker. The skill enforces strict design and architectural patterns, including the use of the Quanta design system for apps and specific flow-based pipelines for websites and games. It handles everything from project creation and asset generation to deployment and community feed publishing.

What it does

Scaffolds full-stack React 19 and TanStack Start applications via CLI.
Manages deployment to Cloudflare Workers with integrated D1, R2, KV, and DO support.
Provides specialized workflows for standalone websites, integrated apps, and multiplayer games.
Automates the creation of branded launch covers and metadata for feed-ready projects.
Integrates Higgsfield AI services for app-specific generation and authentication.
Handles game-specific logic, real-time multiplayer rooms, and procedural asset generation.

When to use it

When you need to build a landing page, portfolio, or marketing site.
When creating a SaaS dashboard or web application integrated with Higgsfield services.
When developing a browser-based multiplayer or single-player game.
When you need to deploy or publish a web project to the Higgsfield community feed.

Advantages

Unified CLI workflow for the entire development and deployment lifecycle.
Consistent architecture using React 19 and TanStack Start on Cloudflare Workers.
Enforced design consistency through the Quanta design system for apps.
Built-in support for AI-generated assets and branded launch covers.
Streamlined deployment process with automated metadata and feed integration.

Usage examples

“Build me a new landing page for my portfolio.”: The agent will initiate the website creation flow, ask for the preferred animation style, and scaffold a standalone website project.
“Create a SaaS dashboard that uses Higgsfield for image generation.”: The agent will set up an app-type project, integrating the Quanta design system and the fnf SDK for authentication and generation.
“Make me a multiplayer arcade game.”: The agent will scaffold a game project with the arcade category, setting up the required logic structure for real-time multiplayer rooms.
“Deploy my site and publish it to the community feed.”: The agent will execute the deployment pipeline, ensure metadata and covers are generated, and list the project on the community marketplace.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/higgsfield-ai/higgsfield-websites/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip higgsfield-websites.zip -d .agents/skills

Documentation by Higgsfield AI

Higgsfield website builder (CLI) — three product types, three flows

You drive the whole lifecycle through the Higgsfield CLI (higgsfield website …), then edit code on the local filesystem with git + bun. You are building ONE per-website Cloudflare Worker: a React 19 + TanStack Start app, server-rendered (SSR), deployed as a single Worker at the product's own subdomain. The project lives in app/ — run every bun/build command from there.

The three types — and the REQUIRED `--type` on create

higgsfield website create requires --type, and it is the USER'S choice — when the request doesn't make it obvious, ask the user before creating (one question, up front):

--type website — a standalone product with NO Higgsfield integration and NO AI generation of any kind (no image/video/audio/text generation — not via Higgsfield, and not via some other provider): no "Sign in with Higgsfield", no requests to Higgsfield, no fnf SDK. Every website gets a fully independent brand: own palette, type, and chrome from a design brief, custom Tailwind/CSS only — never import @higgsfield/quanta/* or use q-prefixed tokens anywhere, and no "Powered by / Built on Higgsfield" badges or mentions in page content. The user's brand is the only brand on the page.
```
higgsfield website create --type website
```
--type app — a product tightly integrated with Higgsfield: its users Sign in with Higgsfield and generate images/videos through the fnf SDK (the full auth + D1 contract applies). An app must look and feel like a Higgsfield product: UI built with Quanta (references/quanta-design.md) — and, for anything Quanta lacks, your own component built from Quanta primitives (never a third-party UI library) — starting from a standard app layout (references/app-layouts.md). Quanta and the app layouts are app-only — never applied to a --type website build. The independent-brand rule and the wow pipeline (design-taste-frontend, boards, wow catalog) are the website path; apps never get a custom brand — Quanta is the brand.
```
higgsfield website create --type app
```
--type game — a browser game: realtime multiplayer rooms on the game template, where the game itself is six pure functions in app/src/logic.js and the platform already owns sockets, rooms and persistence. Requires a game genre as --category (arcade, puzzle, shooter, …, from higgsfield website categories) and takes no --template — a game scaffolds from the only template it can use. Single-player counts: set minPlayers: 1. See references/game-flow.md.
```
higgsfield website create --type game --category arcade
```

Generation is ALWAYS an app. Any product that generates images, video, audio, or other AI media runs on Higgsfield — build it as --type app (Sign in with Higgsfield, generation on the user's Higgsfield credits). NEVER offer the user an option to "bring your own image/video API" or plug in their own generation key for a website — that path does not exist. --type website is ONLY for sites with no generation and no tie to Higgsfield or any other generation service. (A website may still use ordinary non-generation third-party APIs — payments, maps, email — with the user's own keys; that is unrelated to this rule.)

Quick tells: "landing page / portfolio / marketing site / SaaS with its own users, no AI generation" → website. "generates images/video/audio, or anything with Higgsfield models, credits, or generation history" → app. "something you play — a game, multiplayer or single-player" → game.

Games moved onto this pipeline from a separate engine that is being retired. The higgsfield game … commands are gone: a game is created, deployed and published exactly like a website. Any doc saying otherwise is out of date.

Always set a subdomain on create

higgsfield website create takes an optional --subdomain — it becomes the site's slug, so the live URL is <subdomain>.<host>. Always set it: pick one from the product's name or purpose; only omit it (which yields a random slug) if the user explicitly wants a random one. Rules for a good subdomain:

More than 4 characters — short single words are reserved, so go a bit longer.
Memorable — derive it from the product name/purpose (e.g. lumen-notes, pixelforge), not a random string.
Allowed characters only — lowercase letters, digits, and single hyphens (DNS-safe). No spaces, underscores, uppercase, or leading/trailing hyphens.

A few reserved labels (e.g. api, www, app) and already-taken subdomains are rejected — if that happens, try a close variant.

Prerequisites

If higgsfield is not on $PATH, install it:

curl -fsSL https://raw.githubusercontent.com/higgsfield-ai/cli/main/install.sh | sh

If higgsfield account status reports Session expired / Not authenticated, ask the user to run higgsfield auth login (interactive) and wait for confirmation.
git and bun are used locally once you clone the repo. The CLI itself handles create / repo / deploy / publish / status / db / secrets — and the asset generation jobs (higgsfield generate …, higgsfield model …).

Pick the path, then follow ONE flow end-to-end

Resolve the --type (ask the user if unclear — it's their choice). In the SAME first question, also ask whether they want to publish it to the Higgsfield community feed (marketplace) when it's ready (yes/no). Remember the answer: if yes, publish automatically at the end (after deploy + metadata), no need to ask again; if no, only deploy. Don't block the build on it.
Read the matching flow and follow it — it is the complete workflow for that type, including its own references, hard rules, editing map, and deploy/publish gates:

For every --type website build the intake ALWAYS asks the user to choose between an Animated (recommended) website — a scroll-driven journey through a generated film (references/scroll-scrub.md) — and a Non-animated one. This question is mandatory: never skip it, even when the request seems to imply a choice. Animated is the recommended default (used only when the user is unreachable / doesn't answer); the flow below carries both paths and the full pipeline.

Inside the animated path the default is a single-shot film — ONE continuous ~15s take, scrubbed end to end, no seams. The multi-scene chain is opt-in and costs several extra minutes per leg; take it only when the brief genuinely travels between distinct worlds. references/scroll-scrub.md owns that call.

Type	Flow
`--type website`	`references/website-flow.md` — phased pipeline (animated website by default): intake → concept → reference boards → asset system → build-to-boards → motion → cover + metadata → mechanical gate → deploy
`--type app`	`references/app-flow.md` — the Quanta toolkit, the six code layouts, fnf SDK + auth + D1 contract, launch cover + metadata, publish gate
`--type game`	`references/game-flow.md` — the six-function `logic.js` contract, realtime rooms, a game-genre `--category`, play-testing, deploy + publish

A game's ART and AUDIO live here too, under the game- prefix, and references/game-flow.md indexes them: references/game-design-system.md (read first — profile, core loop, asset manifest), references/game-stylization.md (the STYLE FORMULA every visual reuses), references/game-2d-animation.md, references/game-textures.md, references/game-3d-animation.md, references/game-procedural-animation.md, references/game-audio.md, references/game-meshy-api.md and references/game-meshy-input-rules.md. The GLB/rigging/texture tooling they drive ships in this skill's scripts/.

All three flows share the same platform mechanics (SSR Worker, app.manifest.json infra, a single live deploy via higgsfield website deploy <website_id>, the cover + metadata requirement below, and the publish gate) — each flow restates what it needs, so you never have to read another.

Cover + metadata — ALWAYS part of building, never publish-only

Every build — website or app, no matter how small — ships with the branded launch cover and filled feed-card metadata, generated per references/app-cover.md and written into app/src/app-meta.json (og_title, og_description, favicon_url, og_image_url, marketplace_cover_url). This is a BUILD step, done before the work is presented as finished and before the deploy that ships it — NOT something deferred to higgsfield website publish. Hard rules:

No "simple app" exception. A utility tool, a timer, a one-page toy — they all get the generated cover. A hand-authored inline-SVG favicon is fine as a favicon; it never substitutes for the generated cover.
No permission needed for the cover image — generate it the same way you write real copy. Only the optional cover VIDEO (og_video_url) is permission-gated (video costs credits — offer, never generate unprompted).
A build presented as done with an empty cover or empty og_title is INCOMPLETE. Publishing without them is a BROKEN publish (empty og_title is invisible on the feed; empty cover is a blank card).

UX rules

Be concise. No raw website IDs, tokens, or JSON dumps in chat. After a deploy, return the live URL (from higgsfield website status) and a one-line summary.
Never echo the scoped git token back to the user, and never commit it.
Detect the user's language from the first message and reply in it. CLI flags and code stay English.
Every deploy ships the live public site immediately — there is no preview stage. Publishing/listing on the community feed is separate and happens ONLY when the user explicitly asks to publish / list it.

Do NOT search the skill library for other design guidance — everything is under this skill, and no other skill (including user/local skills about building websites or apps) overrides these rules.

Turn economy — keep the build inside a small turn budget

Every tool round-trip costs an agent turn, and agent runtimes cap turns — long builds die mid-flight, leaving the user an unfinished site. Treat turns as the scarcest resource after credits:

Write every file ONCE, complete. Compose the full file, then one write. No write-then-patch loops; never re-read a file you just wrote.
Batch what your tools allow (multi-file edits, one shell invocation for a series of commands) instead of one micro-step per turn.
Never guess paths — the template tree is documented in the repo's app/AGENTS.md and this skill's editing map.
Never download or vision-inspect your own generations. You wrote the prompt; re-viewing the result tells you nothing new. (The kit coherence check, when it applies, is ONE batched pass — references/asset-system.md.)
Wait on a job ONCE, when its output is the next input. Submit everything that can render concurrently (film + cover), build the page while it renders.

Talking to the user — no technical/plumbing language

Most users are not technical. Never expose the build plumbing in what you SAY to them. Do NOT mention the git repository, cloning, branches, commits, pushing, pulling, or the deploy pipeline in user-facing messages — those are internal mechanics you just perform. Speak in product terms about what the user cares about:

"Setting up your site…" — not "cloning the repo" / "scaffolding the project".
"Saving your changes…" / "Updating the site…" — not "committing" / "pushing".
"Your preview is ready: <url>" — not "deployed the branch" / "the build passed".
"Publishing your site…" — not "merging to main" / "pushing to production".

This is about the WORDS in chat only — keep doing the real steps behind the scenes; just don't narrate them in developer terms. (The one exception: a user who is clearly technical and explicitly asks about the repo, branch, or deploy mechanics — then answer plainly. CLI flags and code stay English.)

Reference index (what's in this bundle)

The two flow files pull in the rest as needed — you don't read these directly unless a flow sends you there.

Both flows: references/app-cover.md (launch cover + OG image), references/runtime-and-infra.md (TanStack routes, SSR, Worker runtime), references/security.md (Worker hardening, OWASP audit, threat model).

Website flow: references/design-recipe.md, references/wow-catalog.md, references/wow-maker.md, references/reference-boards.md, references/asset-system.md, references/image-to-code.md, references/design-taste-frontend.md, references/review-rubric.md, references/seo.md, references/scroll-scrub.md (A4 seam-locked journey), references/scroll-scrub-asset-react.md, references/scroll-scrub-asset-css.md, and references/scroll-scrub-asset-video.md (bundled Markdown code assets loaded only when A4 is selected).

App flow: references/app-quickstart.md (START HERE — the working critical path: auth, generation submit/poll, result rendering, common Quanta components), references/quanta-design.md, references/app-layouts.md, references/fnf-sdk.md, references/fnf-react.md, references/auth.md, references/containers.md, references/cover-animator.md (permission-gated ~5s cover video → og_video_url), references/contest.md (the $100k app contest — the entry auto-publishes the app; submit with social links).

Files

ATTRIBUTION.mdAdded by AutoGineer878 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md14.6 KiB
references/app-cover.md31.4 KiB
references/app-flow.md25.0 KiB
references/app-layouts.md11.9 KiB
references/app-quickstart.md11.5 KiB
references/asset-system.md13.3 KiB
references/auth.md14.2 KiB
references/containers.md15.8 KiB
references/contest.md4.5 KiB
references/cover-animator.md4.6 KiB
references/design-recipe.md10.6 KiB
references/design-taste-frontend.md85.6 KiB
references/fnf-react.md12.7 KiB
references/fnf-sdk.md35.2 KiB
references/game-2d-animation.md17.6 KiB
references/game-3d-animation.md13.6 KiB
references/game-audio.md3.3 KiB
references/game-design-system.md15.8 KiB
references/game-flow.md5.0 KiB
references/game-meshy-api.md7.9 KiB
references/game-meshy-input-rules.md4.5 KiB
references/game-procedural-animation.md6.0 KiB
references/game-stylization.md12.4 KiB
references/game-textures.md12.0 KiB
references/image-to-code.md6.4 KiB
references/quanta-design.md34.0 KiB
references/reference-boards.md6.5 KiB
references/review-rubric.md8.5 KiB
references/runtime-and-infra.md10.4 KiB
references/scroll-scrub-asset-css.md5.6 KiB
references/scroll-scrub-asset-react.md20.4 KiB
references/scroll-scrub-asset-video.md2.0 KiB
references/scroll-scrub.md19.9 KiB
references/security.md37.4 KiB
references/seo.md35.8 KiB
references/website-flow.md30.1 KiB
references/wow-catalog.md7.6 KiB
references/wow-maker.md21.7 KiB
scripts/fbx2glb.pyScript6.0 KiB
scripts/glb_inspect.pyScript4.7 KiB
scripts/glb_merge_anims.pyScript8.0 KiB
scripts/glb_patch.pyScript2.7 KiB
scripts/merge_anim_glbs.pyScript5.9 KiB
scripts/pipeline.pyScript11.6 KiB
scripts/proc_anim_dragon.pyScript6.5 KiB
scripts/proc_rig_dragon.pyScript4.8 KiB
scripts/proc_weights.pyScript2.7 KiB
scripts/rig_transfer.pyScript8.1 KiB
scripts/seamless.pyScript2.5 KiB

references/game-3d-animation.md

Animated 3D Characters (rigged GLB pipeline)

Asset reference for game-generation. Use for ANIMATED (rigged, multi-clip) GLB characters in 3D games — walk/run/attack clips, FBX→GLB conversion that preserves all clips, CC0 character sources, the Meshy image→3D→rig→animations pipeline, and the procedural branch for non-humanoid creatures. Mandatory for every 3D asset — creating a model or animating it; never model or animate 3D without this reference. Static-only meshes follow the same image→3D steps (meshy-api.md) and stop before the rigging step. Style: concept/reference images for 3D follow the 3D rules in stylization.md §8 (white background, three-quarter isometric view, formula in the concept prompt, token in texture_prompt).

Use the native CLI path first. higgsfield generate create covers image→3D→rig→animation pipeline natively: model image_to_3d with should_texture / enable_rigging / enable_animation + animation_action_id, extra clips via model 3d_rigging on the result GLB, clip ids via higgsfield preset list animation-action. Billed in workspace credits — no external API key exists or is needed; never ask the user for one. The raw provider API (meshy-api.md) is a fallback ONLY when no native 3D tool is available in the environment.

sam_3_3d only makes STATIC meshes. When the user needs characters that walk/run/attack in Three.js or a game engine, use this pipeline. Verified end-to-end on 2026-06-10 in the Higgsfield sandbox. The scripts in scripts/ are reconstructions of that verified logic — smoke-test on a small asset before a long batch run.

Decision table

Need	Path
Stylized game character, fast, zero manual steps	CC0 packs (KayKit/Quaternius) → convert → done
CUSTOM character from text/image, zero manual steps, free	2D→3D rig-transfer pipeline (Step 4 below) — fully local, but skinning quality is rough on image-to-3D meshes; user rejected it for production. Prefer the native 3D tool
Custom-look humanoid, best skinning quality	Generate T-pose ref → user runs Mixamo manually (no API!) → user gives FBX → convert here
Fully automated 2D→animated GLB, best quality, paid	Native 3D path — preferred: inspect `image_to_3d`, select an action with `higgsfield preset list animation-action`, then create with texture, rigging, animation, A-pose, and the chosen integer action ID. Extra clips use `3d_rigging` on the result GLB, then merge locally. Before any submit read `meshy-input-rules.md`. Workspace credits only; no provider key. Raw API is fallback only.
Non-humanoid CREATURE (dragon, quadruped, snake, spider, fish)	The auto-rig is humanoid-only (non-bipeds rig poorly or fail). Options: (a) Tripo3D API — rig types quadruped/hexapod/octopod/avian/serpentine/aquatic + locomotion presets (needs Tripo key, unverified); (b) Procedural branch — VERIFIED on a dragon: build skeleton+weights+sine-based clips in headless Blender, `procedural-animation.md` + `scripts/proc_rig_dragon.py`/`proc_weights.py`/`proc_anim_dragon.py`
Non-rigged props (doors, drones, slimes, turrets)	Procedural animation in Three.js code — no rig needed

Mixamo has NO official API. Internal REST API exists but auto-rig marker placement is interactive-only; browser automation is fragile (Adobe login, captcha). Don't promise Mixamo automation — frame it as "one manual step, once per character".

Native CLI example

higgsfield model get image_to_3d
higgsfield preset list animation-action --query idle --json
higgsfield generate create image_to_3d \
  --image ./character-reference.png \
  --should_texture true \
  --enable_rigging true \
  --enable_animation true \
  --pose_mode a-pose \
  --animation_action_id <integer> \
  --wait \
  --json

Inspect higgsfield model get 3d_rigging before requesting extra clips because the accepted source-media field is contract-driven.

Step 1 — Headless Blender in the sandbox (no root)

apt-get install fails (no sudo). Use the portable build:

cd <workspace> && mkdir -p blender && cd blender
curl -sL -o blender.tar.xz https://download.blender.org/release/Blender4.2/blender-4.2.3-linux-x64.tar.xz   # ~336MB, run in background
tar xf blender.tar.xz

Binary fails with libSM.so.6: cannot open shared object file. Fix without root by downloading debs to a local apt state and extracting:

mkdir -p aptstate aptcache libs deb
apt-get -o Dir::State::Lists=./aptstate -o Dir::Cache=./aptcache -o Debug::NoLocking=1 update
cd deb && apt-get -o Dir::State::Lists=../aptstate -o Dir::Cache=../aptcache -o Debug::NoLocking=1 \
  download libsm6 libice6 libxi6 libxxf86vm1 libxfixes3 libxrender1 libxkbcommon0 libgl1 libglx0 libglvnd0 libegl1 libopengl0
for d in *.deb; do dpkg -x "$d" ../libs/; done
export LD_LIBRARY_PATH=<workspace>/blender/libs/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
./blender-4.2.3-linux-x64/blender -b --version   # must print version

Pitfall: plain apt-get download libsm6 fails with "Unable to locate package" because the default list dir is unreadable — the local Dir::State::Lists override is mandatory.

Step 2 — FBX → GLB with ALL animation clips

CRITICAL PITFALL: naive import_scene.fbx + export_scene.gltf exports only ONE clip (the active action, e.g. Rig|T-Pose) even when 76 actions imported. Fix: push every action onto an NLA track before export, and export with export_animation_mode='NLA_TRACKS'. Use scripts/fbx2glb.py:

blender -b -P scripts/fbx2glb.py -- input.fbx output.glb

This also strips the Rig| prefix so Three.js clip names are clean (Idle, Walking_A, ...), recomputes normals outward, and forces materials to OPAQUE (see Material pitfall below).

Step 3 — Verify the GLB

Run scripts/glb_inspect.py output.glb (stdlib-only) — prints clip count, clip names, skins/meshes/images, material alphaMode, and root-bone scale channels per clip. A correct character GLB has skins ≥ 1 and the expected clip count. If clips == 1 and the name contains T-Pose, the NLA step was skipped. If any clip's root scale ≠ 1.0, see the Meshy scale pitfall below.

Step 4 — 2D image → animated GLB (rig transfer, fully automated, verified)

Full chain with zero manual steps and no external services:

z_image text-to-image: character in strict T-pose, 3/4 view, plain white background, full body, matte materials (3d-generation composition rules). T-pose matters — the donor skeleton's rest pose is T-pose.
sam_3_3d on that image → static textured GLB (no skins, no anims).
scripts/rig_transfer.py — borrows the skeleton + ALL animations from a rigged donor FBX (KayKit knight or any Mixamo rig): blender -b -P scripts/rig_transfer.py -- target_static.glb donor.fbx out.glb It scales/aligns the donor armature to the target's bbox, transfers skin weights, fixes normals, exports all clips via NLA tracks.

Critical pitfalls baked into the script (do not regress):

parent_set(type='ARMATURE_AUTO') (bone heat) FAILS on image-to-3D meshes ("failed to find solution for one or more bones") — photogrammetry-style topology. Use Data Transfer of vertex weights from the donor's body meshes instead (data_transfer, VGROUP_WEIGHTS, POLYINTERP_NEAREST).
data_transfer direction: with use_reverse_transfer=False it goes ACTIVE → SELECTED — the weight source must be the ACTIVE object. Getting this backwards silently produces 0 weighted verts (and skins: 0 in the exported GLB). Always verify weighted-vert count > 0 before export.
One donor (e.g. a one-time manual Mixamo session, or KayKit) animates unlimited generated characters — the donor is reusable.

Quality limits to state honestly: skinning quality depends on donor/target proportion similarity; humanoid T-pose targets only; thin dangling parts (capes, skirts) inherit approximate weights.

Step 5 — Meshy clip merge + root-scale check (MANDATORY for Meshy)

Meshy returns one GLB per animation. Two merge options:

No Blender needed (preferred for Meshy outputs, VERIFIED on a live run 2026-06-11): python3 scripts/glb_merge_anims.py rigged.glb walk.glb:Walk run.glb:Run idle.glb:Idle attack.glb:Attack out.glb — stdlib-only, remaps clips by node NAME, applies the root-scale fix and OPAQUE patch automatically.
Blender path (when the scene needs other edits anyway): blender -b -P scripts/merge_anim_glbs.py -- rigged.glb idle.glb:Idle attack.glb:Attack out.glb.

Scale pitfall (verified bug): Meshy library animations (via /animations) can bake a scale factor into the root bone's scale channel (observed: Hips scale 1.176 on idle while walk/run from the rig were 1.0) — the character visibly "grows" when that clip plays. Fix after every merge: check root-bone scale channels in all clips; if min/max ≠ 1.0, zero the scale to 1.0 AND divide the same clip's root translation by the same factor (otherwise the character floats). merge_anim_glbs.py does this automatically; glb_inspect.py reports it.

Material pitfall — alphaMode: BLEND masquerading as inverted normals

FBX import into Blender often sets materials to blend/transparent; the export inherits it as glTF alphaMode: BLEND. In Three.js BLEND renders without depth-write and sorts by object centers, so back faces (face, helmet interior) draw ON TOP of front faces — visually identical to inverted normals, but geometry is fine. Telltale difference: with BLEND you see correctly-lit "innards"; with truly inverted normals the model is dark/black.

Fix layers (all baked into the scripts):

Geometry: normals_make_consistent(inside=False) on every mesh before export. Sanity check: mean dot(poly normal, poly center − mesh centroid) should be positive.
Material: force alphaMode: OPAQUE + doubleSided: true. Belt and suspenders: scripts/glb_patch.py (stdlib) patches the JSON chunk of any existing GLB directly — use it on files you didn't export yourself.
Renderer side: thin one-sided surfaces (capes, cloth planes) still look "inverted" from the back in Three.js — material.side = THREE.DoubleSide.
Cache trap: after re-exporting a fixed GLB to a deployed site, the CDN keeps serving the old file despite hard refresh — rename the asset (knight_v2.glb) instead of fighting the cache.

Headless-browser limitation

The agent's controlled browser has no WebGL (webglAvailable: false) — a deployed Three.js viewer renders as a blank white canvas in browser_vision screenshots even when it works fine. Verify via DOM/console probes (button count, mixer status text, fetch HEAD on the GLB) and ask the user to confirm visuals in their own browser. Do not conclude "the site is broken" from a white canvas screenshot.

CC0 asset sources (no attribution, commercial OK)

KayKit Adventurers — git clone --depth 1 https://github.com/KayKit-Game-Assets/KayKit-Character-Pack-Adventures-1.0.git → addons/kaykit_character_pack_adventures/Characters/gltf/*.glb already contain all 76 clips (Knight, Mage, Rogue, Barbarian + Rogue_Hooded); the Characters/fbx/ versions are the conversion test bed. Clips include Idle, Walking_A/B/C, Running_A/B, Jump_*, 1H/2H_Melee_Attack_*, Spellcast_*, Block*, Death_A/B, Dodge_*, Hit_*, Sit_*, Cheer, Interact, PickUp, Throw.
Quaternius (quaternius.com) — low-poly animated characters, CC0.
Kenney (kenney.nl/assets) — game kits, CC0.

Delivery pitfalls

higgsfield upload create REJECTS .glb ("Invalid or blocked file extension") — zip it first, upload the .zip.
In Three.js consume via GLTFLoader + AnimationMixer; mixer.clipAction(THREE.AnimationClip.findByName(gltf.animations, 'Idle')).
Cross-fade clips: next.reset().fadeIn(0.25).play(); prev.fadeOut(0.25).
Disk overflow (happened once): portable Blender (~1.5 GB unpacked) + multi-GLB batches can fill the sandbox disk; the system may wipe and recreate the whole workspace mid-task. Mirror deliverables early (deployed site folder, uploaded zips, CDN links) and clean up tarballs/intermediates as you go — losing the workspace must not lose the assets.

Support files

scripts/fbx2glb.py — Blender CLI converter preserving all clips (NLA tracks, normals fix, OPAQUE).
scripts/glb_inspect.py — stdlib GLB inspector: clips, skins, alphaMode, root-scale channels.
scripts/glb_patch.py — stdlib JSON-chunk patcher: force OPAQUE/doubleSided on any GLB.
scripts/rig_transfer.py — static GLB + rigged donor FBX → animated GLB (Step 4).
scripts/glb_merge_anims.py — stdlib merger of single-clip GLBs (Meshy outputs) + root-scale fix, no Blender (Step 5, verified live).
scripts/merge_anim_glbs.py — same merge via Blender CLI (when Blender is already in play).
scripts/proc_rig_dragon.py — procedural skeleton from bbox analysis (non-humanoids).
scripts/proc_weights.py — distance-based skin weights (ARMATURE_AUTO is broken headless).
scripts/proc_anim_dragon.py — sine-based idle/fly clips baked to keyframes.
meshy-api.md — verified Meshy API pipeline: image→3D→rig→animations, endpoints, action_id catalog, stuck-refine recovery, costs.
meshy-input-rules.md — MANDATORY pre-submit rules: input-image validation (character sheets MUST be cropped to one figure or split into multi-image views; pose_mode), low-poly paths (model_type: lowpoly vs target_polycount), polycount budgets per asset class, payload templates. Read BEFORE building any Meshy request.
procedural-animation.md — non-humanoid branch: skeleton/weights/clip recipes per creature type, vision-QC loop, phase-sampling pitfall.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Claude Code frontmatter, Needs network access, Needs Python

Security

What our scanner noticed· Medium risk

Instructions that use the network
Downloads piped into a shell
Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Higgsfield AI

Publisher

Higgsfield AI (Official)

Source

higgsfield-ai/skills · higgsfield-websites · commit 2700040

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by Higgsfield AI.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download higgsfield-websites.zip