scenario-identity-library — Claude Code skill: characters and props

---
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: <name> or props: <name>), 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 <name>`);
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: <name>` or `props: <name>`                                      | 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: <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.

## 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.