Ask an agent for a logo and you get one good image and no memory of why. Brand Studio makes the whole thing repeatable: it reads what your repo has already settled on, hands that as structured weight to whichever producer you've bound, puts every candidate in front of humans, and seals only what you accept.
Theme tokens, references, and everything previously accepted — read before a single pixel is planned.
Structured brand weight goes to the bound producer skill and your configured backend. In parallel, one subagent per deliverable.
A round board — keep / maybe / drop, with notes. Share it as one link and read the verdicts back.
Keepers are sealed into approved assets with a manifest and checksum. Nothing accepted is ever lost.
That one sentence is the architecture. Generation belongs to producer skills and rendering backends you choose; Brand Studio owns the durable, deterministic, human-gated spine between them — which is exactly the part that's hard to keep consistent across a year of asset requests.
theme.md frontmatter and campaigns
Validation, handoff, settle and reporting dispatch on modality — never on a
hard-coded image-extension list. Text is a first-class asset, which is why release
notes and brand-tone copy settle the same way a logo does.
image, video, logo, copy, slide, social — each maps to a skill you already have installed. Brand Studio ships a recommendations catalog: names and links, not vendored implementations.
A producer decides what the prompt is; the declared backend decides what renders it — your local codex exec, an API, an MCP server. Swap either without touching the other.
Org standard, product theme, sibling-repo assets, the accepted portfolio — distinct inputs, named and assembled into the context a producer receives. That's why round 4 still looks like round 1.
It reads CHANGELOG.md, summarizes releases into an editable copy.yaml, and turns that text asset into a normal campaign — so the release graphic is about the release, not a generic hero.
Candidates go up as one board. Reviewers open it, decide, submit. The agent reads the verdicts back and settles the keepers — no screenshots in chat, no copy-paste shuttle.
The skill payload lives in skills/brand-studio/. Fork first if you want your own org defaults, producer preferences, and templates to travel with it.
For real team use, fork it: treat Sma1lboy/brand-studio as the generic upstream
and your fork as the shared source of truth for metadata, policy, and producer
preferences. Product repos pin the fork through a submodule or tag — product assets
always stay in the product repo, never in the skill repo.