Skip to content

Instantly share code, notes, and snippets.

@h4rm0n1c
Last active December 14, 2025 03:09
Show Gist options
  • Select an option

  • Save h4rm0n1c/ab3580a459380b631b08d6da51ac0315 to your computer and use it in GitHub Desktop.

Select an option

Save h4rm0n1c/ab3580a459380b631b08d6da51ac0315 to your computer and use it in GitHub Desktop.

This is gold for those using generative Ai to create sets of images that go together such as icons and emotes. I have personally used this technique to create more consistent image sets. it can be pasted into the likes of ChatGPT and you can ask to start the process and take it from there. it is essentially a refinement to the art generation capabilities of chatgpt through a formal structure of documentation and heuristic rules. in essence, I've reverse engineered the essence of professional asset production as a task in ChatGPT. using this and some manual editing for those emotes that are repetitive/memes, I was able to produce 22 emote images that are relatively consistent and generally look human made, in less than a day, I think I did that in 6-8 hours.

this is not perfect, this is not a "fix the Ai's inadequecies" magic spell, but it is really, really good at working with you to iterate over output (as long as you remember to say stop and go back to the documentation/rule setting phase to fix whatever went wrong and reinforce what you want), and to correct errors in output until you get something that fits what you're looking for. this is great for fine tuning output. being obsessive over detail here IS the art. commitment to this process of trial and error is what makes this more of a serious tool and less of a lazy man's way out.

junior asset artists worldwide may want to take note of this, please note however that your muse cannot be captured by a computer, the biggest value you have is your perspective and experiences and views that inform your creative ideas specifically, you may end up prompting a computer, but what's important here is that everything I produced via this method still drew heavily on what I wanted and what inspired me, it's just a tool. the key to avoiding it for now is to be able to better match the specific demands of your clients than an Ai can, with how people can be about artworks and creative projects, that is still a pretty low bar to get over in many cases these days.

truth be told, emotes and icons and such are the exact kind of assets I expected to end up being produced by automated processes, nearly two decades ago when the first tiniest glimmer of Ai potential started to show in research here and there.

Heuristic-Locked Asset Generation

A General Guide to Consistent Visual Output with Generative Models

This document describes a general-purpose, repeatable workflow for producing consistent visual assets using generative image models, especially in domains where:

  • Style consistency matters more than novelty
  • Small-format readability is critical
  • “Almost correct” outputs are worse than rejection
  • Iteration and constraint refinement are unavoidable

The method applies to:

  • Emotes & emojis
  • Icons & UI elements
  • Sprite sheets
  • Character variants
  • Meme-format art
  • Brand-locked illustration systems

1. Problem Statement

Generative image models optimize for plausibility, not compliance.

In constrained visual domains, this leads to:

  • Style drift (“generational loss”)
  • Hallucinated anatomy or props
  • Inconsistent lighting and rendering
  • Reintroduction of forbidden elements
  • Increasing variance over iterations

Naïve prompt tweaking fails because the model fills ambiguity with learned priors.

Solution: Remove ambiguity by progressively constraining the solution space.


2. Core Philosophy

2.1 Treat the Model as a Renderer, Not a Collaborator

The model should be treated as:

A stochastic renderer that must be boxed in by rules

Not as:

A creative partner with taste or intent

Creativity is allowed only where explicitly granted.


2.2 Rules Are Stronger Than Descriptions

Anything not explicitly forbidden will eventually appear.

If something must never happen, it must be:

  • Explicitly disallowed
  • Repeated
  • Enforced through rejection

Absence is not implied.
Absence must be commanded.


2.3 Iteration Is a Feature, Not a Failure

Errors are not setbacks. They are data.

Every repeated mistake reveals:

  • A missing rule
  • An ambiguous constraint
  • An unprotected invariant

3. The Three Pillars

The workflow is built on three documents:

  1. Style Bible – what never changes
  2. Iteration Protocol – how changes are introduced
  3. Acceptance Gate – what “done” means

All three are required.


4. The Style Bible (Invariants)

The Style Bible defines everything that must remain stable across assets.

4.1 Visual Invariants

Define, explicitly:

  • Canvas rules (size, padding, transparency)
  • Line art:
    • Thickness
    • Opacity
    • Consistency
  • Color rules:
    • Fixed palette or ranges
    • Saturation limits
    • No drift over generations
  • Lighting model:
    • Flat / cel / graphic
    • Explicitly forbid glow, bloom, vignette if unwanted
  • Texture policy:
    • Allowed vs forbidden textures
    • When damage or noise is acceptable

These are non-negotiable.


4.2 Structural / Anatomical Invariants

For characters or objects:

  • Fixed silhouettes
  • Fixed proportions
  • Fixed structural elements
  • Explicit bans on:
    • Extra parts
    • Shape reinterpretation
    • Expressive shortcuts

If an element must not be used for expression, say so explicitly.


4.3 Accessory & Prop Rules

Define:

  • Which props are canonical
  • How many props are allowed
  • Where props may appear
  • How props interact with the subject

Avoid symbolic interpretation unless explicitly desired.


4.4 “Never Again” List

Maintain a running list of recurring failure modes.

Examples:

  • Style drift
  • Painterly rendering
  • Unwanted anatomy
  • Abstract or surreal reinterpretation
  • Softening of edges
  • Added lighting effects

This list is referenced in every locked prompt.


5. The Iteration Protocol (The Loop)

This is the operational process.

Step 0 — Select ONE Change

Each iteration introduces exactly one new variable:

  • A pose
  • An emotion
  • A prop
  • An interaction

Everything else is frozen.


Step 1 — Planning Notes

Before generating, write brief notes covering:

  • Intended viewer read (what should be understood instantly)
  • Composition plan
  • Interaction physics (if relevant)
  • Anticipated failure modes

This primes constraint extraction later.


Step 2 — Locked Prompt Construction

All prompts should be structured, not prose.

Recommended sections:

A. LOCKED STYLE

Condensed Style Bible.

B. LOCKED STRUCTURE

Anatomy, geometry, or object rules.

C. ASSET DELTA

The only new information introduced.

D. NEGATIVES

Explicit list of forbidden elements.

E. OUTPUT REQUIREMENTS

Background, resolution, edge quality, etc.

Once written, the prompt is considered locked.


Step 3 — Generate

  • Generate conservatively
  • Reject aggressively
  • Do not “hope” the next run fixes systemic issues

Step 4 — Structured Critique

Critique using categories, not vibes.

Examples:

  • StyleMismatch
  • AnatomyViolation
  • PropUnreadable
  • PhysicsIncorrect
  • DriftDetected

This keeps feedback precise and repeatable.


Step 5 — Rule Patching

Each repeated failure results in:

  • A new explicit rule
  • A tightened constraint
  • A promotion from soft to hard constraint

Failures are folded back into the system.


Step 6 — Constraint Escalation

As needed, escalate:

  1. Conceptual freedom
  2. Guided generation
  3. Locked style
  4. Locked composition
  5. Locked geometry (rearrange only, no invention)

Escalation continues until outputs stabilize.


6. Acceptance Gate

Define when an asset is finished.

6.1 Pass Criteria

An asset is accepted only if:

  • It matches the reference set at a glance
  • It violates zero hard rules
  • It reads correctly at target display size
  • It shows no degradation vs previous accepted assets

6.2 Downscale Test

Always test at final usage size.

If it fails small, it fails.


6.3 Archival Discipline

For each accepted asset, store:

  • The locked prompt
  • The delta introduced
  • The primary failure modes encountered

This builds institutional memory.


7. Replicability Requirements

To reproduce the process across teams or time:

A. Prompt Templates

Reusable, parameterized templates.

B. Shared Critique Vocabulary

A fixed taxonomy for feedback.

C. Canonical Reference Set

A small, immutable anchor set that defines “on-model”.


8. Key Insight

This process succeeds because:

  • Errors become constraints
  • Iteration is intentional, not exploratory
  • Style is defended, not rediscovered
  • The model’s degrees of freedom are progressively removed

This is not prompt engineering.

It is design system enforcement for generative tools.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment