Skip to content
cccskills
FreePublished on GitHub

brand-asset-generation

Generate brand assets — banners, social cards, CIP elements — with brand-token injection + provider routing. Use when generating a banner / social image / branded asset.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md6.2 KB
  • evals/triggers.json953 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config13Updated Oct 22, 2026

See all skills by event4u-app

Report a problem with this skill