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.
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 installReview the instructions the agent will receive before you install.
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.
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.
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.
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.
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.
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.
provider-lifecycle-discipline."pack-brand
(Phase B of the brand pipeline) eliminate this gap; until that pack ships, rely on
brief-supplied values.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.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.tokens.json or explicit values
from the brief. Guessing palette values produces off-brand output.media-governance-routing, regardless of how generic the output appears.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.No reviews yet. Tell others what you thought.
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.
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.
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.
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.
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.
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.
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.