Ghid ELI20 pentru skill-ul imagegen

Ce face

imagegen este skill-ul pentru imagini raster generate sau editate cu AI: fotografii, ilustrații, texturi, sprites, mockups, cutouts cu fundal transparent, variante vizuale sau asset-uri pentru proiecte.

Pe scurt: dacă rezultatul final trebuie să fie un bitmap, cum ar fi PNG, JPG sau WebP, imagegen este candidatul corect. Dacă rezultatul ar trebui să fie SVG, HTML/CSS, canvas sau o modificare într-un sistem existent de iconițe ori logo-uri, nu forța un bitmap. Acolo se taie cu bisturiul nativ, nu cu toporul generativ.

Are două moduri:

1. Modul built-in, implicit și preferat, pentru generare normală, editare și cereri simple de transparență.
2. Modul CLI fallback, folosit doar când ceri explicit CLI/API/model path sau când confirmi explicit fallback-ul pentru transparență nativă.

CLI fallback poate cere configurare suplimentară, inclusiv o cheie API. Sistemul nu trece singur acolo doar pentru calitate, dimensiune, batch sau control de fișier.

Când îmi folosește

Folosește imagegen când vrei:

• concept art, product shots, cover images sau website hero visuals;
• asset-uri pentru jocuri, texturi, sprites sau mockups UI;
• infografice, diagrame sau wireframes bitmap;
• transformări pe imagini existente: lumină, vreme, înlocuire fundal, eliminare obiecte, compunere;
• variante vizuale pornind de la imagini de referință pentru stil, compoziție sau mood;
• fundal transparent pentru un PNG/WebP cu alpha.

Nu-l folosi pentru forme simple, iconițe, logo-uri sau modificări mici când repo-ul are deja surse editabile în format vectorial ori code-native. Dacă asset-ul există deja într-un format curat și determinist, modificarea acelui format e de obicei mai sigură decât regenerarea.

Cum îl invoc / declanșez

Îl declanșezi cerând o imagine nouă sau o editare de imagine, de exemplu:

• „generează un hero image pentru pagina asta”
• „fă 5 variante de sprite pentru personaj”
• „editează imaginea asta și scoate obiectul din fundal”
• „creează un cutout cu fundal transparent”
• „folosește imaginile astea ca referință de stil”

Sistemul decide întâi intenția:

• dacă vrei să modifici o imagine existentă păstrând părți din ea, este edit;
• dacă imaginile sunt doar referințe de stil, compoziție, mood sau subiect, este generate;
• dacă nu dai imagini, se presupune generate.

Pentru multe asset-uri sau variante, modul built-in face apeluri separate pentru fiecare asset sau variantă. Cuvântul „batch” nu înseamnă automat CLI. În CLI, generate-batch se folosește doar dacă ai ales explicit modul CLI.

Pentru editare built-in, imaginea trebuie să fie vizibilă în conversație: atașată, generată mai devreme sau încărcată înainte de editare. Nu se promite editare arbitrară direct de pe un path local.

Exemplu practic

Ceri: „generează un website hero cinematic, dark, cu textură de sticlă mată și lumină rece, pentru o pagină de produs”.

Fluxul corect:

1. Se folosește modul built-in, pentru că este o generare normală.
2. Cererea este generate, nu edit, fiindcă nu modifică o imagine existentă.
3. Se stabilește dacă imaginea este doar preview sau asset pentru proiect.
4. Dacă este asset pentru proiect, rezultatul final se salvează în workspace înainte de finalizare.
5. Dacă există deja un asset cu același nume, nu se suprascrie fără cerere explicită; se creează un nume versionat.

Pentru transparență simplă, sistemul nu sare direct la CLI. Întâi generează subiectul pe un fundal chroma-key plat, apoi elimină local fundalul cu helper-ul instalat al skill-ului și verifică alpha-ul rezultat. Brutal, dar eficient.

Output / unde aterizează

În modul built-in, imaginile generate sunt salvate implicit într-o zonă internă a runtime-ului, nu într-o destinație de proiect aleasă stabil prin argument de tool. Nu te baza pe OS temp și nu presupune că există mereu un argument direct de destination path.

Regula practică:

1. Dacă ai cerut o destinație, rezultatul selectat se mută sau se copiază acolo.
2. Dacă imaginea este pentru proiectul curent, imaginea finală trebuie mutată sau copiată în workspace.
3. Dacă este doar preview sau brainstorming, poate fi afișată inline, iar fișierul poate rămâne în locația implicită.

Un asset folosit de proiect nu trebuie lăsat doar în locația internă implicită. Altfel ai o imagine care funcționează până dispare contextul. Foarte solid, ca o scară făcută din ceață.

Vezi și All guides pentru restul ghidurilor.

Limite / gotchas

CLI fallback nu se folosește automat. Dacă modul built-in e indisponibil sau eșuează, se explică existența fallback-ului și faptul că poate cere cheie API, apoi se continuă doar dacă îl ceri explicit.

Pentru transparență nativă, modelul implicit din calea CLI modernă nu suportă background=transparent. Dacă chroma-key removal nu este suficient, transparența nativă cere un fallback explicit către un model care suportă fundal transparent și output PNG. Sistemul trebuie să ceară confirmare înainte de această schimbare.

Pentru transparență complexă — păr, blană, pene, fum, sticlă, lichide, obiecte lucioase, umbre moi sau culori care se confundă cu fundalul chroma-key — calea built-in poate să nu fie suficientă. Asta se spune înainte, nu se ascunde sub optimism.

Pentru editări, se păstrează invariants agresiv și se salvează non-destructiv implicit. Nu se suprascriu asset-uri existente fără cerere clară.

Nu se modifică scripturile interne ale skill-ului. Dacă lipsește o funcție, se cere decizie înainte.