brand-asset-generation

Generate brand assets (banner, social card, CIP element) via structured prompting, brand-token injection, and provider routing. Rides on the existing pack-ai-image adapters — not a second image-gen stack.

When to use

• User asks to generate a banner, social card, header image, platform profile or cover image (a LinkedIn cover, an X header, a YouTube channel art), or a CIP (corporate identity) element.
• Branded asset production where palette, typography, or voice must stay consistent.
• When brand tokens are available and should drive the visual output.
• When a brief alone (no tokens) still needs a governance-aware image output.

Procedure

1. Identify asset type and spec — determine format (banner, social card, platform profile/cover image, CIP element), output dimensions (e.g. 1200×630 for Open Graph, 1080×1080 for square social), and target channel (web, print, social platform).

   A platform cover is a dimension constraint, not a new asset class, and it is the one case where guessing the number is the whole failure: a cover rendered at the wrong aspect ratio is cropped by the platform, so the brand marks land outside the visible area and the asset is unusable rather than merely off-brand. Take the required dimensions from the platform's own current spec at generation time — never from memory, and never from a number written here, because these change without notice. If the spec cannot be established, say so and ask rather than emitting an asset that will be cropped.

2. Ask the resolver, then inject what it reports — run ./agent-config brand:status --json before any colour, type or voice decision. Take hex values and font names from the tokens.json entry it reports as valid, and tone keywords from the brand-voice slot (agents/context-spine/brand-voice.md) when that is valid too; feed those <!-- ref-ignore --> into the prompt. Never load a token file by path on your own — a file the resolver marks invalid or shadowed is not the brand, and a dotted near-miss is not the brand either. When the resolver reports bare, or nothing valid for the axis in hand, derive palette and type from the brief; raw generation works, and every such value is labelled corpus-sourced in the output so brief-driven is never reported as token-driven.

3. Route and prompt — delegate provider selection to image-provider-routing (text-in-image → Ideogram, photoreal product shot → Flux, etc.). Author the provider-specific prompt with the asset spec, injected tokens, and any negative constraints.

4. Dry-run and validate — invoke the adapter (scaffold-tier; see Gotcha). Confirm the returned dry-run plan matches the spec: dimensions, style intent, brand token usage.

5. Rights and AI-disclosure governance — run image-likeness-and-rights if the asset depicts a real person or brand mark. Attach the AI-generation disclosure footer per media-governance-routing before delivering output.

Output format

1. Asset spec — type, dimensions, channel, and routing rationale (which provider and why).
2. Prompt — final provider-specific prompt string with injected brand tokens (or brief-derived palette/type if no tokens). Include key params: aspect ratio, style keywords, negative prompts.
3. Adapter invocation / dry-run note — the dry-run plan returned by the adapter, or an explicit note: "adapter is experimental (scaffold-tier) — dry-run plan only; no rendered asset until promotion per provider-lifecycle-discipline."
4. Governance confirmation — rights check result and AI-disclosure footer.

Gotcha

• Without a brand token layer the output is generic — feed the brief's exact palette (hex codes) and typography (font names or style descriptors) into the prompt. Vague color terms ("blue", "modern") produce inconsistent results. Brand tokens from pack-brand (Phase B of the brand pipeline) eliminate this gap; until that pack ships, rely on brief-supplied values.
• Brand tokens come from pack-brand (Phase B) — this skill consumes tokens; it does not author them. If tokens.json is absent, proceed brief-driven and note the gap.
• Adapters are scaffold-tier (dry-run only) — all pack-ai-image adapters are experimental. This skill produces a blueprint and dry-run confirmation; actual renders require a maintainer to capture a smoke trace and promote the adapter to stable.

Do NOT

• Do NOT invent brand colors or voice — use tokens from tokens.json or explicit values from the brief. Guessing palette values produces off-brand output.
• Do NOT omit the AI-generation disclosure — every delivered asset requires the disclosure footer per media-governance-routing, regardless of how generic the output appears.
• Do NOT claim a rendered asset is produced while adapters are scaffold-tier — surface the dry-run caveat explicitly every time.

See also

• logo-generation — logo-specific generation with vector and mark constraints.
• image-generation — general-purpose image generation end-to-end.
• image-provider-routing — select the right provider before writing the prompt.
• image-likeness-and-rights — rights check before generating real-person likenesses or brand marks.