Character Identity Onboarding

Apply ../00-video-production-guardrails/SKILL.md first. Its Gate 2 principle — a provider's technical ability to clone a likeness never implies the legal right to use it — is not a citation to satisfy in passing here; it is the reason this skill records face_consent/voice_consent as their own fields, separate from every representation, and refuses to onboard a representation for a modality with no captured consent.

This skill is not 03-character-consistency-technique. That skill assumes an identity already exists and answers "how do we keep reusing the same reference correctly across a scene plan." This skill answers the question that has to be true first: "does a canonical record of this identity exist at all, and does at least one provider-specific representation of it actually work." Once this skill has produced a record under ../../characters/, 03-character-consistency-technique is what a workflow skill reaches for to use it.

The identity is the root abstraction, not a provider

A character identity — ../../schemas/character-identity.schema.json — can exist with zero provider-specific representations attached. A HeyGen avatar_id, a Google Flow character_N reference, a future voice-cloning provider's voice ID: these are attachments (representations) to an identity, never the identity itself. Never model onboarding as "create a HeyGen avatar" — model it as "onboard this identity, and attach a HeyGen representation to it." Capability booleans never live on the identity record; they live only on providers/<name>/capability.json (see ../../schemas/provider-capability.schema.json) and every representation implicitly inherits whatever its named provider already declares there.

Before either flow: resolve or create the identity record

1. Determine whether a characters/<slug>.md record already exists for this identity (same real person or persona, regardless of which provider is being onboarded now). If it exists, load it — you are adding a representation to an existing identity, not creating a new one.
2. If no record exists, create characters/<slug>.md with face_consent and voice_consent both starting { captured: false, evidence_uri: null } and an empty representations list. Consent is recorded at the identity level because it is a fact about the depicted person's authorization to be depicted at all, cutting across every provider attachment — never per-representation, and never a single combined boolean for both modalities, since a face representation and a voice representation may come from different providers and be authorized separately.
3. Do not proceed to either flow below for a given modality (face or voice) until that modality's consent is captured: true with a real evidence_uri. A provider being technically capable of creating or rendering a representation never authorizes onboarding it — this is Gate 2 applied at the one point in this repo's pipeline where a representation first comes into existence.

Create flow

Use when no representation of this identity exists yet on the target provider and one must be generated from scratch.