Scenario Identity Library

Scenario Identity Library

Overview

A game or brand runs on named identities: characters and props that must stay recognizable in every image that ships. This skill runs that lifecycle end to end: interview a brief, generate and gate a hero image, file approved shots in a named collection, assemble a sheet, and pull the library back out for new images. The per-image mechanics live in siblings and are not repeated here: connection and the core loop in scenario, holding a look with references in scenario-consistency, pass/fail verdicts in scenario-quality-gate. If a sibling skill named here is missing from your available skills, ask the user to install it (npx skills add scenario-labs/skills --skill <name>); unattended, proceed from tool schemas and flag the gap.

Quick reference

From interview to anchor

Interview before generating: the answers become the baseline enumeration every later image restates (scenario-consistency), so a gap here becomes drift later. Ask what it is, silhouette and proportions, palette by name or hex, two or three signature details that make it recognizable (the cracked headlamp, the brass buckle), the rendering style, and which views the set needs: a full view alone gives a reference slot too little detail to hold close-ups, so an identity that will be shot close also needs a straight-on close view of the face or signature detail and an exact profile. Non-interactive runs take what the task supplies and flag the rest. A user who already has art skips generation: their drawing or photo is the uploaded anchor, per scenario-consistency.

Pick one reference-capable model for the whole identity before the first run (recommend, then the schema gate in scenario-consistency): every later view rides its reference field, so a model without one disqualifies itself here, not at view three. Generate the hero, a neutral full view on a plain background (a reference slot isolates identity best from an uncluttered anchor: nothing beyond the brief in frame, no text), then gate it per scenario-quality-gate with a round cap fixed up front (its default is three); absent that skill and the gate itself, review against the brief enumeration, same cap. The hero is the anchor everything else cites.

The library is a named collection

collection_create with the exact name character: <name> or props: <name>, then collection_add_assets for the hero (catalog tools, write lane; the create call takes the name plus the scope pair, and no description field). The name is the registry key: collections are not a search target, so a later session finds the library by paging collections_list (read lane) and matching the prefix, then pulls members with search (target="assets", filters={"collection_ids": [...]} plus a tags filter for the views wanted, which keeps filed sheets out of reference pulls). Admission is the gate: only passing images enter, because every future generation samples this pool as reference truth, and one off-model member poisons every pull after it. Build out the views baseline-plus-delta, one model_run per view, gate each, file each pass tagged with its view (asset_add_tags: hero, back, and so on), so a later session can tell the members apart. A redesign (new wardrobe, haircut, age) rewrites the brief enumeration and needs a new hero off the old (scenario-consistency): rebuild views and sheet from it, and collection_remove_assets the superseded members before the next pull, or one pull feeds both versions into the reference field.