Art you made yourself

umicat's editors generate art, sound and music, and there is no local equivalent for that. But plenty of creators already have tools they prefer — Blender, Aseprite, a DAW — and work made there has to get in.

That is what uploading is for. Ask your assistant:

Upload ~/models/lantern.glb to my Cave Crawler project

The file lands in that project's Assets Manager, exactly like something made in umicat: visible in the web editor, reusable, and packaged with the project. It is also written into your local clone, under public/uploaded/, which is where the game loads it from — see below.

A file in the repository is not an asset

This is the distinction worth getting right, because both look like "the file is in the project".

If the point of the file is to be an asset — something you or the agent will reach for again — upload it. If it is a one-off that only this game's code loads, committing it is fine.

A whole folder at once

Point it at a directory and the structure comes with it — what you see in the Assets Manager matches what is on your disk:

Upload ~/blender/forest-kit to my Forest Kit pack

Subfolders become folders. Files umicat does not accept (a .blend, a readme) are skipped and listed rather than quietly dropped. A single request uploads up to 200 files and tells you how many are left, so a stray directory cannot run away with your storage.

Or take something that already exists

Before making art at all, it is worth asking whether umicat already ships it:

Search the library for a wooden crate, then add the best one to my game

The free CC0 library is searchable and importable from here. Importing costs nothing — no credits, and no storage, because the project references the same stored file — and the asset arrives in your clone ready to load.

The project's own pictures

A cover, a logo and screenshots are not assets — they are the project's listing — but they are still files you made, so they go up the same way:

Set the cover to ~/renders/cover.png, and add the last playtest
screenshot to the listing

A logo is required to publish and must be exactly 1024×1024; your assistant checks that before sending, so a wrong size comes back as a sentence rather than a rejected upload. A listing needs at least one screenshot — umicat_playtest already produces exactly the right thing.

The cover's URL never changes, so a browser may keep showing the old one for a while after you replace it. That is caching, not a failed upload.

Screenshots work the other way round — each one is its own picture, up to ten, and adding another appends rather than replaces. To swap one out, ask for it by what it is; your assistant can see what the listing currently holds and will take the right one off before adding the new one.

Show me what pictures this project has, then replace the second
screenshot with ~/renders/boss-fight.png

Saying what your assets are

An uploaded file arrives with no description and no tags, and nothing in umicat writes them for you. The library search matches on exactly those two things — so crate_02.png can be found only by someone who already knows it is called crate_02.png.

Your assistant can fill them in, and it has a real advantage here: the files are on your machine, so it looks at each one rather than guessing from a filename.

Go through my pack and tag everything — look at each file
and write what it actually is

A good description reads the way someone searching would phrase it ("red wooden crate with a dark border, front-facing"), and the tags cover subject, kind and look, art style included. There is no separate style field.

Listing the assets marks what is still missing, so a large library can be done in batches without losing track of where you got to.

A model has to be rendered before it can be described

There is nothing in a .glb an assistant can look at. So it renders one first — which also gives the model a thumbnail, in place of the file icon umicat shows for anything it cannot draw:

Render my models, then tag them

You can already search your own

Searching looks through your own assets as well as the free library, so the pack you made last month is findable from whatever project you are in now — and you can bring an asset from one of your projects into another, published or not. Your unpublished work is visible to you and to nobody else.

Do I already have a crate, or should I make one?

Paid packs

Some packs cost money. Your assistant will show you the price and offer to open the pack's page — it cannot buy one for you, and umicat refuses the import until the pack is yours. That is deliberate: spending your money is not a decision to delegate.

Once you own a pack, its assets are yours like anything else you uploaded — they turn up in search and your assistant can add them to any project.

It becomes searchable when the pack is published

Describing an asset makes it findable by you straight away. What publishing changes is who else can find it: an asset reaches the public library only if it was in a pack at the time that pack was published. A file added since your last release stays private no matter how well described — so finishing the descriptions before a release, rather than after, is what gets them out there.

A project that is only art

umicat_create_project can make an asset pack: a project that holds art rather than a game. It is the natural home for a library you build locally and use across several games.

Make me an asset pack called Forest Kit, then upload everything
in ~/blender/forest/*.glb into it

Limits

Those sit inside an account-wide storage quota, which you can see — and extend — in Settings → Storage. Your assistant will be told which limit it hit if an upload is refused.

Two stores, and the game loads from one of them

This is the part worth understanding, because it is not obvious.

An uploaded asset lives in the asset library — that is what the Assets Manager shows and what a pack contains. But the game itself loads from public/ in its repository, and the published build serves the copy bundled there. The library is not a live source the game reads from; if it were, deleting an asset would break games that already shipped.

So both copies matter, and your assistant handles both at once: it uploads the file and writes it into the clone's public/uploaded/. Commit and push it like any other file.