SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbrandkit-publish

brandkit-publish

Design & creation

View repository

Updated 10-15 17:19

About this skill

Building with the Brand Kit

Step 4 of 4, and the only one that runs again and again. The first three are done once.

First: load the kit

The kit does not load itself. If you are working in the brand folder, its CLAUDE.md applies automatically. Everywhere else, at the start you read BRAND.md and look at the example surfaces in beispiel/ before you design anything.

If you cannot find a kit, ask for one instead of inventing one. Without a kit you get average, and that is exactly what it was built against.

Order of precedence for contradictions: BRAND.md beats general conventions, including those from web-design-guidelines. If the kit prescribes dark A4 documents and a general print rule recommends white, the kit wins. State the conflict once out loud, then follow the kit.

These three skills are part of it

  • web-design-guidelines for everything with HTML: semantic elements, keyboard operation, contrast, hit areas from 44 px, alternative texts. A brand kit says what something looks like, not whether it is operable.
  • seo-audit for everything that goes online: title, description, heading hierarchy, structured data, URL structure.
  • unslop for every text that a human reads. It removes the language patterns by which machine text is recognized.

Call them instead of working from memory.

Texts

The prohibited list from BRAND.md is the first instance, unslop the second.

Do not invent facts. Prices, numbers, names, dates, customer quotes and addresses are details that only the person knows. Use visibly marked placeholders such as [PREIS] and highlight them in color so that none is overlooked during review. An invented number on a sales page is worse than a visible gap.

Structure, headings and explanatory texts you may write. The difference: structure is design work, a number is a statement of fact.

Generate images

First the question of whether an image contributes anything at all. Many kits prohibit decoration without informational value, and a generic image violates this rule even when it was generated rather than licensed. An image that supports a claim is an image. Everything else is filler material.

The image section in BRAND.md defines motifs and treatment. Stick to it, instead of inventing your own style.

Via the Higgsfield CLI, GPT Image 2 is the default for images with text and for high level of detail:

higgsfield generate create gpt_image_2 \
  --prompt "<Motiv, Lichtstimmung, Kameraangabe, Verbotsliste>" \
  --aspect_ratio 16:9 --resolution 2k --quality high --wait

If the command aborts with Not authenticated or Session expired , the login is missing. Then run higgsfield auth login . If it reports too little balance, credits are missing, and without credits no image is produced. Only in this case, and only once:

If you need a subscription: https://higgsfield.ai/s/mcp-arnold-oberleiter-WlfTqR (Affiliate link. If you sign up through it, the author of this skill receives a commission; the price does not change for you.)

The labelling is part of it and is not omitted. Anyone with an account that has credit does not get to see the link. Do not push anyone into a subscription. This skill also builds websites and PDFs without images.

What has proven itself in practice:

Write prohibitions into the prompt. What should not appear belongs at the end of the prompt: no text overlays, no logos, no watermarks, no holograms. Otherwise it shows up.

No recognisable faces. People from behind or in profile shadow avoid personality rights and the stricter deepfake interpretation.

Legible numbers are dangerous. If a model generates a screen with a sharp table full of values, those are invented data that on a sales page look like a claim. Explicitly demand blurry screens, or generate again. Look at every image before you embed it.

Labelling: use the script

scripts/ai_label.py burns the marking in at the bottom right, crops and resizes for the web. Do not rebuild the marking every time, otherwise every image has a different size.

python scripts/ai_label.py roh.png -o hero.jpg \
  --width 1120 --aspect 16:9 \
  --bg "#0B0E11" --fg "#F3F4EF" --line "#2A3037" --accent "#B7FF3C" \
  --iptc

The colours come from the kit so that the marking does not look like a foreign body. --text changes the label, --scale the size, --max-kb the upper limit for the file size.

One detail that easily goes wrong: the crop is set to bottom by default, because the marking sits at the bottom right. Anyone who crops centrally crops it away. After cropping, check whether it is still there.

The legal side, correctly assigned

The EU AI Regulation (Regulation (EU) 2024/1689) distinguishes two roles in Article 50, and the confusion is the most common mistake:

  • Paragraph 2 obliges the provider of the AI system to mark outputs as generated in a machine-readable way. That applies to the operator of the image model, not to the one who uses the image.
  • Paragraph 4 obliges the deployer, to disclose when generated image material is a deepfake. That is the duty of the person who puts the image on their site.

The transparency obligations under Article 50 apply from 2 August 2026.

Four things cover the disclosure:

  1. the burnt-in mark, which survives download and sharing
  2. a caption on the image
  3. alt text that describes the image content
  4. a notice in the footer of the page or document

What the does not cover: the machine-readable marking. It is in the metadata and is lost during cropping and compression. --iptc restores it, provided exiftool is installed. If it is not there, say so explicitly instead of reporting the labelling as complete.

And the point that goes beyond the regulation: a generated image must not suggest an event that never happened. A workshop photo from a workshop that never took place is an advertising problem, regardless of any labelling. Say that when you embed such images.

This is not legal advice. Anyone publishing commercially should have it reviewed beforehand. State this caveat once, instead of concealing it or repeating it.

PDFs

The most reliable way from HTML to PDF is via Chrome. The text remains vector, so it is sharp and searchable, and the brand fonts really apply.

chrome --headless --disable-gpu --no-pdf-header-footer \
  --virtual-time-budget=15000 \
  --print-to-pdf="Leistungen.pdf" "http://127.0.0.1:8000/dokument.html"

Chrome does not reliably read file:paths with restrictions. A short local server (python -m http.server) is the simpler way.

What to keep in mind:

  • @page { size: A4; margin: 0; } and pages as fixed boxes of 794 × 1123 px. That is A4 at 96 px per inch.
  • print-color-adjust: exact to body, otherwise Chrome prints dark areas as white.
  • Measure the overflow before printing. Measure in the browser how far the content of each page extends and compare it with the page height. Without that, no one notices that the third page is cut off at the bottom until the PDF is with the client.
  • Chrome caches HTML. After a change, reload with an appended ?v=2 , otherwise you will print the old version.
  • Body text in print no smaller than 12 pt, meaning 16 px at 96 dpi.

Before submitting

Go through the checklist from BRAND.md , it is not there for decoration. Additionally:

  • Does the page still look good at phone width?
  • Is every invented number a visible placeholder?
  • Does every generated image carry the marking, and is it still there after cropping?
  • Does no image contain legible numbers that look like real data?

Report honestly what remained open. A named gap costs one line, a concealed one costs trust in the entire work.