--- name: scenario-identity-library description: "Use when a named character or prop must become a reusable identity in Scenario: creating a character or prop from a brief or interview, building its approved image collection (character: or props: ), assembling a character sheet or turnaround, or generating new images of an established one. Triggers include create a new character, design a prop, character sheet, turnaround, more images of this character. Keywords: character design, identity, library, collection, grid." license: MIT --- # 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 `); unattended, proceed from tool schemas and flag the gap. ## Quick reference | Stage | Mechanism | Rule | | ------- | -------------------------------------------------------------------------------------------- | -------------------------------- | | Brief | interview, written as the must-not-change enumeration | before anything generates | | Anchor | hero generation, gated to pass | uploaded art skips generation | | Library | collection named `character: ` or `props: ` | gated images only | | Sheet | Grid Maker assembly of approved shots | rebuild after membership changes | | Reuse | `collections_list` prefix match, members via `search`, references per `scenario-consistency` | any later session | ## 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: ` or `props: `, 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. ## Sheets are assembly, not generation Scenario's Grid Maker packs approved shots into one sheet image: its id is the fixed first-party `model_scenario-grid-maker` (Scenario's single deterministic tool for the job, so discovery would only re-derive it); read its schema with `model_schema_get`. At this writing it takes `images` (a file array capped at 100; wrap even a lone asset) plus layout fields: `columns`, `rows` computed from the count when unset, `padding`, `backgroundColor`, and a fixed `cellRatio` list (`auto` default). It has no prompt field: order the `images` array in reading order, because the array is the layout. The sheet is itself an asset, filed ungated (it assembles already-approved shots, it is not a generation): tag it (`asset_add_tags`, say `sheet`), file it, and rebuild it after membership changes rather than editing it: pull the view-tagged members only (never a bare member list, or an old sheet becomes a grid cell), and swap the old sheet out with `collection_remove_assets`. It serves humans, and it serves as a one-slot reference packing the whole turnaround when a model is slot-starved; with slots to spare, prefer the individual approved shots. ## Worked example: Nima, courier robot 1. The interview yields the brief: rounded silhouette, copper shell, one cracked headlamp, canvas satchel, cel shading; views front, back, left, three-quarter. 2. `recommend` with the brief's own words; `model_schema_get` confirms a true reference field (else the next candidate); `model_run` the hero, `jobs_wait` whenever `model_run` returns a `job_id` without assets, gate per `scenario-quality-gate`, iterate to pass. 3. `collection_create` `"character: Nima"`; `collection_add_assets` the hero, tagged `hero`. 4. Three more views, baseline-plus-delta with the hero in the reference field, gated, filed on pass with their view tags. 5. Run Grid Maker on the view-tagged members (this session already holds the ids; a just-filed asset can trail the `search` index) with `images` as [front, back, left, three-quarter] and `columns: 4`; tag the output `sheet` and file it. 6. Weeks later, "Nima in a rainy alley": `collections_list` finds `character: Nima`, members come from `search`, the `hero`-tagged member and two on-model shots ride the reference field, prompt per `scenario-consistency`. ## Common mistakes - Generating before interviewing: a vague brief cannot be enumerated, and the library inherits the drift. - Admitting ungated images: a failed image iterates per `scenario-quality-gate` or never enters. - Prompting Grid Maker or expecting it to generate: it arranges its `images` input, nothing more; generation belongs to the view runs. - Passing the sheet as an img2img `image`: composition lock (`scenario-consistency`); a sheet rides a true reference slot only. - Free-form collection names: `Nima stuff` is unfindable by convention; the `character: ` and `props: ` prefixes are the lookup contract. - A different model per view: reference behavior differs per family; one schema-checked model carries the whole identity.