The hoodie stays: turning my mascot into a reusable Codex skill
My previous post, Systems in Motion, was about making the site look like it belonged to me. The portrait, the graphite and electric-blue palette, the typography and the moving Z gave the portfolio, blog and products one visual system.
The next experiment was smaller, but it exposed the same problem from another angle: could I generate my mascot twice and still recognise the same character?
A single good image is easy to celebrate. A reusable identity has to survive the next prompt.
One good image was not enough
I started with the small pixel-art mascot I already had: hood up, navy sweatshirt, orange drawstring tips, dark beard, laptop in one hand and a wave with the other. The first generated scene kept those details and turned a production bug into a literal creature. My mascot trapped it under a coffee mug at a desk lit by the moon.
The result had the right face and a rendering style I wanted to keep: crisp manga ink, halftone texture, dimensional skin, deep navy fabric and controlled orange accents. But it was still one image. When I asked for a full manga page, a second reference was needed to explain panel rhythm, gutters and visual continuity.

Three references, three separate jobs
The useful change was not a longer prompt. It was separating the references by responsibility.
- Identity: the original mascot decides the face, beard, smile, proportions and hoodie.
- Rendering: the successful single scene decides the ink, texture, colour treatment and lighting.
- Composition: the successful manga page decides the panel structure, pacing and continuity.
That separation is now explicit in the skill. The model is not asked to infer which parts of one image are permanent and which parts belong only to that scene. Each reference has a named role.

The interface is intentionally small
I packaged the result as a user-level Codex skill called zakaria-mascot. Without an option it creates one polished scene. Add --manga and the same request becomes a portrait comic page with roughly five to seven panels.
$zakaria-mascot in a futuristic systems landscape
$zakaria-mascot --manga crossing several software worlds
The flag is removed from the scene description, so it never becomes accidental text inside the image. It changes composition, not character. A user-supplied scenario still wins; when there is no scenario, the skill chooses something playful and appropriate to a developer without automatically repeating the midnight-deploy joke.
The manga mode also prefers silent visual storytelling. Generated dialogue is not the point of this experiment, and avoiding it keeps the page readable without gambling on distorted lettering. Exact captions can still be requested deliberately.
Consistency should not become repetition
The strict rules cover the parts that make the character recognisable: the warm face, dark eyebrows, short beard, broad smile, hood-up navy sweatshirt and orange tips. The rendering keeps the same ink, screentone and colour language. Across manga panels, the apparent age, face and clothing should not drift.
The setting remains open. The mascot can stand inside the moving Z, work at a visual-reference wall, move through a server room or cross a moonlit city. The whole point is to keep the person stable while allowing the story to change.

--manga changes the composition into a continuous page. The locations and camera angles move; the face and hoodie do not.The durable part is the decision layer
The skill does not contain a custom image generator. It contains the decisions I do not want to renegotiate every time: which references to load, what each one controls, what counts as drift, when to use a single frame and when to construct a page.
Its folder carries the three reference images beside a short SKILL.md and the metadata that makes it discoverable. The validator returned Skill is valid!. Because it lives at user scope, I can invoke it from another project without copying a prompt from an old conversation.
This is the same reason I keep my blog-writing workflow as a reusable skill. The model can already write and generate images. The value is in preserving the choices around those capabilities: my voice, my visual references, draft-before-publish, and the boundary between a creative example and evidence.
A second layer of Systems in Motion
The site’s design system and the mascot do not need to collapse into one palette. The publication still uses graphite, cool white and electric blue. The character keeps the navy hoodie and its small orange details. In the first new example, those two identities meet without either one replacing the other.
Systems in Motion made the products and writing look like they came from the same person. This sequel adds a character that can move through those systems and still look like himself in the next frame.