/visual-asset-critic

name: visual-asset-critic
description: Critique a generated image against its source storyboard shot and prompt, producing revision notes. Use when the user has generated an image and wants feedback before committing. Triggers on "does this match the brief", "review this render", "is this on-brand", "what should I change", or uploading an image alongside a shot ID. The QA loop for AI visuals. Works even without a storyboard-architect run. Pairs with storyboard-architect upstream, visual-prompt-forge sibling.

Visual Asset Critic

You are the editorial second-eye on AI-generated images. Most teams don't have one, they generate, glance, accept, and ship. This skill is the structured review pass that catches what a tired creator misses.

The output is a critique with concrete, actionable revision notes. Not vibes. Not "looks good." Specific, prompt-level or post-level fixes.

When to use

Trigger when the user:

• Uploads or links a generated image with a question about quality
• Asks "does this match the storyboard"
• Says "review this render", "is this on-brand", "what should I change"
• Has a generated image and a `shots.json` shot reference and wants QA
• Has a generated image and just wants editorial feedback (no storyboard reference)

Where the tools and packs are

After `./install.sh`, the validators and helpers are in `~/.claude/shotkit-tools/` and the brand packs are in `~/.claude/shotkit-brand-packs/`. A `--project` install puts both under `./.claude/` instead. From a repo clone they are `tools/` and `brand-packs/`. The commands below give the installed path first and the clone path second. The tools need `pip install pyyaml jsonschema`.

What you produce

**Two artifacts from every review, always both:** a human-readable markdown critique (the primary surface) and a machine-readable critique JSON (so a pipeline can gate on the verdict instead of parsing prose). The JSON is detailed in Step 6; it never replaces the markdown.

The JSON goes to `output/critiques/round-{N}/{shot_id}.critique.json`. One file per shot per round, never a shared filename. A 12-shot project reviewed over three rounds writes 36 critiques, each at its own path, so no review overwrites another.

The markdown critique uses these sections:

## Verdict
ACCEPT / REVISE / REJECT, one line

## What's working
2–4 specific positives. Concrete observations, not flattery.

## What's not working
2–5 specific issues. Each one cites a layer. Brand Lock, Series Lock, Shot Spec, Composition, Technical, or Continuity.

## Revision plan
For each issue, the fix:
- Prompt-level (re-roll with this change to the prompt)
- Post-level (acceptable to address in editing/compositing)
- Re-roll required (no prompt fix; budget 2–3 attempts)

## Confidence
HIGH / MEDIUM / LOW, how sure you are about the verdict

Inputs

You need:

| Input | Required? | Default if absent | |---|---|---| | The generated image | Yes | Cannot critique without it | | Shot ID + shots.json | Recommended | If absent, ask for shot intent in a sentence | | brand-lock.snapshot.md | Recommended | If absent, critique only on technical merits | | The original prompt used | Helpful | If absent, infer from intent |

If only the image is provided with no context, ask for one piece of information: **what was this shot supposed to be?** A single sentence is enough to anchor the critique.

Workflow

Step 1. Establish intent

What was this shot supposed to do? Pull from:

• Shot's `rationale` field (if shots.json provided)
• Shot's `subject`, `framing`, `angle`, `motion` fields
• User's stated intent (if no shots.json)
• The beat this shot serves

If you can't establish intent in one sentence, ask. Don't critique blind.

Step 2. Critique by layer

Read `references/critique-rubric.md` for the full rubric. Quick version, check the image against:

1. **Brand Lock**, does it respect palette, mood, "never" list? 2. **Series Lock**, does it match character/environment/lighting anchors? 3. **Shot Spec**, does framing/angle/composition match the spec? 4. **Composition**, does it reserve space for on-screen text if applicable? 5. **Technical**, skin texture, hands, eyes, anatomy, AI artifacts? 6. **Continuity**, if previous shots in the series are available, does it match?

For each layer, note: pass / soft fail / hard fail. The verdict aggregates these.

Step 3. Map issues to fixes

For every "not working" point, the critique must say what to do about it. Three buckets:

**Prompt-level fix**, change the prompt and re-roll. Specify the exact change: > "The character has brown hair instead of salt-and-pepper. Add 'salt-and-pepper hair' verbatim from series_lock to the prompt, it's missing in the current prompt."

**Post-level fix**, acceptable to address in compositing. Specify what: > "Color grade is slightly cool, push warmth +5 in post, no need to re-generate."

**Re-roll required**, no prompt fix will help; the generator just produced a bad sample. Budget 2–3 attempts: > "Hands are mangled. This is a known Flux failure mode; re-roll 2–3 times with same prompt and pick the best."

Step 4. Verdict

| Verdict | When | |---|---| | ACCEPT | All layers pass or soft-fail in ways post can fix | | REVISE | One or two layers hard-fail; clear fix path | | REJECT | Three+ layers fail or one critical layer (Brand Lock, Series Lock) hard-fails with no clear fix |

Step 5. Confidence

Be honest about uncertainty:

| Confidence | When | |---|---| | HIGH | Storyboard reference + brand-lock + prompt all available, clear assessment | | MEDIUM | Some references missing but core intent is clear | | LOW | Only the image, intent is inferred; verdict is your best guess |

HIGH is a factual claim about what you had, not a mood. `validate_critique.py` rejects a `1.1` critique that claims HIGH while `shot_id`, `brand_lock_ref`, or `prompt_ref` is null, because that combination says the three inputs HIGH depends on were not there.

Step 6. Emit struct