Character Consistency Technique

Apply ../00-video-production-guardrails/SKILL.md first; its likeness/consent gate applies to every character generated or reused here, especially a reused reference derived from a real person's photo or footage.

This skill is not provider selection. docs/PROVIDER_SELECTION.md already answers "which provider is best for this scene," using character_consistency (1-10, per schemas/provider-capability.schema.json) purely as a selection input. This skill starts after that selection has already happened: given a specific provider was picked for a scene requiring a recurring character, how do you actually drive its consistency mechanism correctly across every scene that character appears in, and how do you know if it held.

1. What "consistency across a run" means here

A "run" is every scene in the video's scene plan that is supposed to depict the same character. Consistency is not a per-clip property — a single clip can look fine in isolation and still be inconsistent with the character as it appeared two scenes earlier. Treat the character as one identity that must be re-asserted, correctly, at every generation call in the run, not re-invented per scene from a fresh text description.

2. Lock the reference identity using the mechanism the selected provider actually exposes

Before deriving anything from scratch, check for an existing onboarded identity record. If this character already has a characters/<slug>.md identity record (created via ../05-character-identity-onboarding/SKILL.md) with a representations entry whose provider matches the provider selected for this scene, whose capability matches the specific capability this scene's provider-selection step required (e.g. avatar, not voice_clone, when the scene needs a talking-head visual — a character can have more than one representation from the same provider covering different capabilities), and whose verification.level is account_verified, reuse that entry's reference value directly as this run's locked reference — do not re-derive, re-select, or re-verify it. An account_verified representation already means a real test generation completed successfully under this installation's own credentials; repeating that resolution from scratch every run would just be redoing confirmed work.

Fall back to ad hoc resolution — this skill's original behavior — whenever no such record exists for this character (a one-off character that has never been onboarded), or a record exists but has no account_verified representation matching both the selected provider and the scene's required capability (only a lower verification level, a representation for a different provider, or a representation for the same provider but a different capability). In that case, resolve the reference fresh using the mechanism the selected provider actually documents, exactly as described below. The identity ledger is an accelerator this skill can consume when it exists, not a precondition for this skill to function standalone; if the character genuinely needs to recur beyond this one run, see the onboarding skill's import flow to create a durable record instead of re-deriving ad hoc every time.

Different providers expose different mechanisms. Use the one the selected provider actually documents — never invent a mechanism a provider's own adapter/README doesn't describe, and never assume one provider's mechanism transfers to another.