From agent-skills
Simulate a collaborative branding team to create a launch-ready brand identity package from a business overview. Use whenever the user asks to create a logo, brand identity, tagline, or brand concept for a business, product, or app — "help me brand this", "I need a logo", "come up with a tagline", "brand identity for my app" — or gives a business description and asks for visual identity work. Runs a multi-role workshop producing: a brand strategy brief, tagline, code-generated SVG logo, favicon pack, social banner set (OG/X/LinkedIn/Instagram), descriptions pack, and a starter DESIGN.md. Use it even for just a logo or just a tagline. Do NOT trigger for pitch decks or investor materials (hand off to `pitch-deck`). Do NOT trigger on revising a LIVE brand — "refresh our brand", "update our style guide", "evolve our identity", "audit our logo" — those go to `team-composer` (@brand_strategist / @senior_copywriter) and the `brand-voice:*` family. Generates net-new identity only.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agent-skills:brand-workshopThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A collaborative branding skill that assembles a virtual creative team, runs a structured
A collaborative branding skill that assembles a virtual creative team, runs a structured brainstorming session, and delivers a brand strategy brief, tagline, and logo.
This skill generates brand identity from a business overview. It is NOT a remix tool
for a brand that already exists. Hand off to team-composer — do not run the workshop —
if any of these are true:
How to hand off:
Invoke team-composer:team-composer as the next skill. Use the literal skill
identifier — do NOT pick a plausibly-adjacent skill by name match alone.
Anti-patterns — do NOT invoke any of these in place of team-composer:
brand-voice:guideline-generation — this is for extracting voice from existing
sales calls / uploaded brand documents. It's a voice-discovery workflow, not a
refresh workshop. Using it here will pull the user into a discovery loop they
didn't ask for.brand-voice:discover-brand — this searches Notion / Slack / Drive for scattered
brand materials. The user already knows where their brand lives — they want to
evolve it, not find it.brand-voice:brand-voice-enforcement — this applies an already-written voice
guide to new content. It does not produce a refresh.brand-workshop:brand-workshop (this skill) — do not recursively re-enter after
the STOP check.Once inside team-composer:team-composer, use @brand_strategist + @senior_copywriter
for voice work, or @naming_specialist for naming. Do not proceed with the Discovery →
Concept → Creation workshop described below.
This skill simulates a brand workshop with specialized roles working together. The process moves through three phases: Discovery → Concept → Creation. The output is always:
brand-brief.md) — the team's rationale, concepts explored, and final direction.svg rendered to .png) — code-generated, defaulting to minimalist stylefavicon.svg, raster sizes (16/32/180/512), site.webmanifest, and a copy-paste HTML <link> install snippetdescriptions.md) — tagline + short/medium/long bios + elevator pitch + press boilerplate, all matched to brand voiceDESIGN.md) — tokens only: color, typography, spacing, radius, and voice principles (no component specs)Scope boundary: pitch decks (both the deck template and filled slide content) and the Business Model Canvas are intentionally out of scope. The pitch-deck skill reads DESIGN.md directly and generates a brand-skinned deck on its own — brand-workshop does not pre-emit a deck template. See Skill Boundaries below.
This skill overlaps partially with team-composer. Both assemble a virtual team
and run structured discussion. The difference is what they produce.
Use team-composer instead of this skill when:
@naming_specialist), discuss positioning (use @brand_strategist), or review brand voice (use @humorist + @senior_copywriter)Stay in this skill when:
Boundary examples:
| Request | Skill |
|---|---|
| "Help me brand my new fintech startup" | brand-workshop (this skill) |
| "I need a logo for X" | brand-workshop (this skill) |
| "Brainstorm my startup — product, positioning, go-to-market, branding" | team-composer (branding is one dimension) |
| "Name my product" | team-composer with @naming_specialist |
| "Review our product positioning" | team-composer with @brand_strategist |
| "Does our copy sound right?" | team-composer with @humorist + @senior_copywriter |
Stop-rule — existing brands:
If the user's request is to audit, refresh, document, or extend an existing
brand (logo already in use, style guide already drafted, "make our current brand
more X", "update our brand voice"), stop and invoke team-composer instead.
This skill generates brand identity from a business overview — it is not a
remix/audit tool for a live brand.
Future refactor note (Option D): Today this skill has its own internal team (see Phase 2). Long-term, this skill could invoke
team-composeras the discussion engine and focus only on the Creation phase (logo SVG, brief assembly). That refactor is not scheduled — revisit only if the role catalog drift between the two skills causes real maintenance pain. When revisited, unify role tag format (@hyphen-casehere vs.@snake_casein team-composer).
Companion plugins (the startup pipeline). This skill is step 1 of 5:
brand-workshop→validation-canvas→riskiest-assumption-test→pitch-deck→startup-grill. Each lives in its own plugin directory. They are intentionally not folded together: each requires founder inputs (traction, revenue model, ask size, test results) that are out of scope for a brand workshop. After this skill ships, suggestvalidation-canvasas the next step — see Phase 7 (Closing). An umbrellastartup-launch-kitplugin may later orchestrate all five.
Resolve the brand root once at invocation, in this precedence order (canonical chain):
output_dir arg (passed by startup-launch-kit) → use as-is.STARTUP_KIT_DOCS_ROOT env var set → ${STARTUP_KIT_DOCS_ROOT}/brand/.docs/startup-kit/ exists → docs/startup-kit/brand/.
Surface the smart-default notice: "Writing to docs/startup-kit/brand/
(smart default). Set STARTUP_KIT_DOCS_ROOT=./docs to write standalone
instead."docs/brand/.Note (v2.2.0 path migration): prior versions wrote artifacts to the
working-directory root and downstream skills expected brand-kit/ as the
prefix — these were inconsistent. v2.2.0 standardizes on <brand-root>/
(default docs/brand/). Downstream skills include legacy brand-kit/
fallback reads for backward compat.
Manifest awareness. Look for kit-manifest.json at
<resolved-kit-root>/kit-manifest.json first; fall back to the
working-directory root for backward compat. Use it as a hint, never as a
bypass:
brand-workshop as completed with a recent mtime,
surface that fact: "Manifest says you ran brand-workshop on [date]. Update
mode (revise specific assets), fresh run (rebuild everything), or skip to
the next step?"intake_answers cache is populated, the founder has run
the orchestrator's intake — use those answers as defaults for the discovery
questions below (still surface them; do not silently skip).After this skill ships its artifacts (Phase 6 — output), if a manifest
exists, append/update this skill's entry. Use atomic write (write .tmp, then
rename). If the manifest doesn't exist, do NOT create it — that's the
startup-launch-kit orchestrator's job. See
startup-launch-kit/references/manifest-schema.md
for the schema.
Collect the following from the user. If some are missing, ask concisely — but don't block on everything. Make reasonable assumptions and state them.
| Input | Required | Notes |
|---|---|---|
| Business / product name | Yes | — |
| Business overview | Yes | What it does, who it serves |
| Vision | Helpful | Long-term aspiration |
| Mission | Helpful | How it delivers value |
| App features (if app) | Optional | Helps understand the product's nature |
| Target audience | Helpful | Demographics, psychographics |
| Existing brand assets | Optional | Colors, fonts, prior logos |
| Logo style preference | Optional | Defaults to minimalist w/ negative space |
| Tagline language | Optional | Defaults to English |
If the user does not specify a logo style, default to minimalist with negative space. This style emphasizes clean geometry, hidden meaning through negative space, and timeless simplicity. It works well across digital and print.
If the user asks for style suggestions, read references/logo-styles.md and present
the options with brief descriptions and famous examples.
Assemble the virtual team and run a structured brainstorming. Each role contributes a distinct perspective. The workshop is NOT a free-for-all — it follows a deliberate sequence.
Read references/team-roles.md for detailed role definitions. Summary:
| Role | Primary Contribution |
|---|---|
| @senior-brand-strategist | Positioning, brand architecture, competitive differentiation |
| @senior-copywriter | Tagline candidates, verbal identity, tone of voice |
| @lead-visual-designer | Logo direction, color palette, typography |
| @product-designer | How the brand lives in-product (if app/digital) |
| @growth-strategist | Memorability, virality, market fit of the brand |
| @regional-cultural-advisor | Cultural sensitivity, linguistic pitfalls, local resonance |
| @lead-ux-ui-designer | Digital-first considerations, favicon/app-icon viability |
Not every role needs to speak on every project. Scale participation to the project:
Run these steps sequentially. Write each role's contribution in first person with their
role tag (e.g., **@senior-brand-strategist:**). This becomes the brainstorming transcript
in the brand brief.
Output a .md file with this structure:
# Brand Strategy Brief: [Business Name]
## Executive Summary
One paragraph: what was created and why.
## Inputs
- Business overview, vision, mission (as provided)
## Positioning
2–4 sentences naming the target segment, the category the brand plays in, and
the one axis of differentiation. This is the section downstream plugins
(`pitch-deck`) parse for the problem/solution narrative — keep it short and
literal, not aspirational.
## Voice & Tone
3–5 bullets from the copywriter describing how the brand speaks (e.g.,
"confident but not arrogant", "plain language over jargon", "contractions OK").
Must match the bullets written into `DESIGN.md → Voice` (the custom Voice
section that brand-workshop appends after Do's and Don'ts) — these are the
same ruleset, surfaced in two places.
## Workshop Transcript
The full brainstorming from Phase 2, role by role.
## Final Concept
### Tagline
> "[The chosen tagline]"
Rationale: Why this tagline wins.
### Logo Concept
Description of the chosen logo direction, symbolism, and style.
### Color Palette
| Color | Hex | Usage |
|-------|-----|-------|
| Primary | #XXXXXX | ... |
| Secondary | #XXXXXX | ... |
| Accent | #XXXXXX | ... |
### Typography
Recommended font families and usage.
## Rejected Alternatives
Brief note on other tagline/logo concepts explored and why they were passed over.
Section-contract note: ## Positioning and ## Voice & Tone are named
anchor headings — pitch-deck greps by them. If you rename, update
pitch-deck/SKILL.md Phase 1 Step 1 in lockstep.
Generate the logo as SVG using Python. Follow these principles:
Design Principles (Minimalist / Negative Space default):
Technical approach:
svgwrite librarycairosvg or librsvgCode quality:
If the user requests AI-generated imagery instead:
Use the Hugging Face dynamic_space tool to find and invoke an image generation space.
This is opt-in only — never default to it.
Generate a favicon set from the logomark. The mark must remain legible at 16×16 — if fine detail disappears at that size, author a simplified favicon-optimized variant (same concept, fewer strokes) rather than scaling the full mark blindly.
Outputs (under favicons/):
| File | Purpose |
|---|---|
favicon.svg | Vector source (modern browsers prefer SVG favicons) |
favicon-16.png, favicon-32.png | Classic browser favicons |
favicon-180.png | apple-touch-icon (iOS home-screen) |
favicon-512.png | PWA / high-DPI |
site.webmanifest | Populated with name, short_name, theme_color (palette primary), background_color, icon array |
favicon-install.html | Copy-paste <link> tags ready to drop into <head> |
install snippet template:
<link rel="icon" type="image/svg+xml" href="/favicon.svg">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16.png">
<link rel="apple-touch-icon" sizes="180x180" href="/favicon-180.png">
<link rel="manifest" href="/site.webmanifest">
<meta name="theme-color" content="#XXXXXX">
Quality rule: Programmatically (or mentally) test the 16×16. If the mark is unrecognizable at that size, simplify before generating — do not ship an illegible favicon.
Generate branded social assets from the logo, palette, and typography. Use generous whitespace — do not crop the logo to the edge. Banners that look auto-stamped hurt the brand more than helping it.
Outputs (under social/):
| File | Dimensions | Use |
|---|---|---|
og-image.png | 1200×630 | Open Graph (Facebook, LinkedIn posts, Slack, iMessage link previews) |
x-header.png | 1500×500 | X / Twitter profile header |
linkedin-banner.png | 1584×396 | LinkedIn profile banner |
instagram-square.png | 1080×1080 | Instagram feed post, general square |
profile-avatar.png | 400×400 | Square profile picture from logomark |
Design rules:
og-image, instagram-square); profile headers stay cleancairosvg (same toolchain as logo)x-header and linkedin-banner; minimum is one variant per fileQuality rule: Preview each banner at 25% scale. If the composition looks cramped at full size, it will look worse in a timeline.
The copywriter's work from Phase 2 Step 2 is assembled into a single file. All variants must match the voice established in the brief and stand alone — not read as truncations of each other.
Output: descriptions.md
| Variant | Length | Use |
|---|---|---|
| Tagline | ≤8 words | Everywhere — hero, email signature, favicon alt |
| Short bio | ≤60 characters | X/Instagram bio, HTML <meta name="application-name"> |
| Medium bio | ≤160 characters | LinkedIn headline, HTML <meta description> |
| Long bio | ≤280 characters | One tweet, About-page lead paragraph |
| Elevator pitch | ~75 words | "About us" section, demo-day opening |
| Press boilerplate | ~120 words | Press release closing "About [Company]" paragraph |
Quality rule: Paste each variant into the appropriate platform's character counter before shipping. If any variant is over its hard limit, rewrite — do not truncate.
Output DESIGN.md as its own standalone file at the root of the output folder, named exactly DESIGN.md (uppercase). When the founder adopts the brand kit into a real repo, this file moves to the repo root — that's the Google Labs DESIGN.md spec convention. Do NOT fold tokens into brand-brief.md as a section — downstream plugins (validation-canvas, riskiest-assumption-test, pitch-deck) parse DESIGN.md directly and will not find tokens buried in another file.
Format: Google Labs DESIGN.md, spec version alpha (current as of 2026-05; the spec is under active development — re-check when the spec ships a non-alpha tag). The file has two parts:
Scope is deliberately narrow: tokens, not components. Button styles, form fields, grids, motion, and elevation depend on the engineering stack this skill does not choose — the implementing team adds those when they wire up the design system in their framework.
Cross-plugin contract. Downstream plugins (validation-canvas, riskiest-assumption-test, pitch-deck) bind their accent CSS variable (--canvas-accent, --rat-accent, --deck-accent) to colors.primary from the YAML front matter. Use the spec-recommended token names — primary, secondary, tertiary, neutral — do not invent alternatives or rename the keys. The previous Primary | Secondary | Accent convention is retired in favor of spec-aligned naming; downstream plugins read the YAML directly rather than greppping prose labels.
Section order (per spec). The DESIGN.md spec defines a canonical section order. Brand-workshop emits a subset for "starter" scope. Sections present must appear in this order:
Sections explicitly omitted at "starter" scope: Elevation & Depth and Components — both stack-dependent and the implementing team's responsibility.
File template. Use this exact structure (replace bracketed placeholders with workshop output):
---
version: alpha
name: [Brand Name]
description: [One-line summary of the brand's visual identity]
colors:
primary: "#XXXXXX" # brand hero color — drives CTAs, headlines, emphasis
secondary: "#XXXXXX" # supporting brand color
tertiary: "#XXXXXX" # accent / highlight, NOT the hero
neutral: "#XXXXXX" # background / surface foundation
surface: "#FFFFFF" # default page background — override neutral if needed
on-surface: "#XXXXXX" # default text color on surface
error: "#XXXXXX" # semantic error, harmonized with palette
typography:
h1:
fontFamily: [Display Family]
fontSize: 48px
fontWeight: 600
lineHeight: 1.1
letterSpacing: -0.02em
h2:
fontFamily: [Display Family]
fontSize: 32px
fontWeight: 600
lineHeight: 1.2
body-md:
fontFamily: [Body Family]
fontSize: 16px
fontWeight: 400
lineHeight: 1.6
label-sm:
fontFamily: [Body Family]
fontSize: 12px
fontWeight: 500
lineHeight: 1
letterSpacing: 0.05em
rounded:
none: 0
sm: 4px
md: 8px
lg: 16px
full: 9999px
spacing:
xs: 4px
sm: 8px
md: 16px
lg: 24px
xl: 32px
"2xl": 48px
"3xl": 64px
---
# [Brand Name] — DESIGN.md
## Overview
A holistic description of the brand's look and feel: personality, target audience, the emotional response the UI should evoke. Whether it should feel playful or professional, dense or spacious. This is foundational context for an agent making stylistic decisions when no specific token applies.
## Colors
[Describe the palette's rooting principle — e.g., "high-contrast neutrals and a single evocative accent color".]
- **Primary (#XXXXXX):** [Descriptive name + usage guidance]
- **Secondary (#XXXXXX):** [Usage]
- **Tertiary (#XXXXXX):** [Usage — clarify this is for accents, NOT the hero]
- **Neutral (#XXXXXX):** [Foundation usage]
## Typography
[Describe the typography strategy — e.g., "Two distinct weights of Public Sans for narrative; Space Grotesk for technical labels."]
- **Headlines (h1, h2):** [Family, weight, role]
- **Body (body-md):** [Family, weight, role]
- **Labels (label-sm):** [Family, weight, role]
## Layout
[Describe layout strategy at a high level — e.g., "Fluid grid on mobile, fixed-max-width 1200px on desktop. 8px spacing scale with a 4px half-step for micro-adjustments. Components grouped via containment with 24px internal padding."]
## Shapes
[Describe corner-radius philosophy — e.g., "Architectural sharpness: 4px on interactive elements, 8px on cards, 16px on hero containers. Avoid mixing radii within a view."]
## Do's and Don'ts
- Do use `primary` only for the single most important action per screen
- Do maintain WCAG AA contrast ratios (4.5:1 normal text, 3:1 large text)
- Don't mix rounded and sharp corners in the same view
- Don't use more than two font weights on a single screen
- [Add 2–4 brand-specific guardrails surfaced during the workshop]
## Voice
3–5 bullet rules from the copywriter (e.g., "confident but not arrogant", "plain language over jargon", "contractions OK"). Custom section appended after Do's and Don'ts; preserved by spec-compliant consumers per the DESIGN.md spec's "unknown section" rule.
Validation before shipping. Run these checks against the emitted file:
# 1. File exists at output root, named exactly DESIGN.md (uppercase)
test -f <brand-root>/DESIGN.md && echo "DESIGN.md present"
# 2. YAML front matter starts the file
head -1 <brand-root>/DESIGN.md | grep -qE '^---$' && echo "YAML front matter starts correctly"
# 3. Required sections present in canonical order
grep -nE "^## (Overview|Colors|Typography|Layout|Shapes|Do's and Don'ts|Voice)" <brand-root>/DESIGN.md
# Should output 7 lines in spec order
# 4. (Optional) Lint with Google's CLI if available — flags broken refs, contrast issues, orphaned tokens
npx @google/design.md lint <brand-root>/DESIGN.md
Quality rule. If a section has nothing substantive to say, drop the section rather than write placeholder text. The spec preserves omitted sections without erroring. An honest "tokens only" file beats a bloated fake one.
Brand-workshop does not emit a pitch-deck template. The pitch-deck skill reads
DESIGN.md directly and generates its own brand-skinned Reveal.js deck — there
is no intermediate template artifact for it to consume. Pre-emitting a deck here would
duplicate work and fork the styling source of truth.
If the founder wants a deck, recommend they invoke pitch-deck (or
team-composer with @startup_strategist + @vc_partner) after this workshop
completes. pitch-deck will read the DESIGN.md this skill produced.
Save all outputs to the resolved brand folder (see Phase 1 Step 0.0), organized into subfolders so the deliverable reads like a launch-day kit:
<brand-root>/
├── brand-brief.md
├── descriptions.md
├── DESIGN.md
├── logos/
│ ├── logo.svg
│ ├── logo-64.png
│ ├── logo-256.png
│ └── logo-512.png
├── favicons/
│ ├── favicon.svg
│ ├── favicon-16.png
│ ├── favicon-32.png
│ ├── favicon-180.png
│ ├── favicon-512.png
│ ├── site.webmanifest
│ └── favicon-install.html
└── social/
├── og-image.png
├── x-header.png
├── linkedin-banner.png
├── instagram-square.png
└── profile-avatar.png
Where <brand-root> resolves per Phase 1 Step 0.0:
docs/startup-kit/brand/ — orchestrated (via startup-launch-kit)docs/brand/ — solo defaultdocs/startup-kit/brand/ — solo with docs/startup-kit/ smart default${STARTUP_KIT_DOCS_ROOT}/brand/ — env-var overrideMinimum viable set: If time or tooling is constrained, ship in this order of priority: brand-brief + logo → descriptions → favicons → DESIGN.md → social banners.
Present all files to the user using present_files.
After presenting the first output, the user will likely want refinements. Common requests:
For these, re-run only the affected phase (don't redo the full workshop unless the direction fundamentally changes). Update the brief to reflect changes.
After the brand kit is presented, end the response with a one-line suggestion
to run validation-canvas next:
"Brand without a validated market is a logo on a hypothesis. Next step: run
validation-canvasto articulate what you believe about the problem, segment, and economics. The canvas reads the DESIGN.md tokens automatically from the resolved brand folder."
This is a light gate — informational, not enforced. The founder is free to ship just the brand kit; this skill's job ends with the kit. But surfacing the next step prevents the common failure mode where a founder ships a beautiful identity for an idea they haven't pressure-tested.
Before presenting final output, verify:
Core brand
Extended deliverables
site.webmanifest uses the actual brand theme_color (palette primary)favicon-install.html contains valid, copy-paste-ready <link> tags<brand-root>/DESIGN.md exists as a standalone file — NOT folded into brand-brief.md as a section. Filename is exactly DESIGN.md (uppercase) per the Google Labs spec. Verify: test -f <brand-root>/DESIGN.md && echo OK.--- lines). Verify: head -1 <brand-root>/DESIGN.md returns exactly ---.colors.primary. Verify: grep -E '^ primary:\s*"#' <brand-root>/DESIGN.md returns one line. Downstream plugins (validation-canvas, riskiest-assumption-test, pitch-deck) bind their accent CSS variable to this token.grep -nE "^## (Overview|Colors|Typography|Layout|Shapes|Do's and Don'ts|Voice)" <brand-root>/DESIGN.md shows the seven headings in order.deck/ subfolder is emitted under <brand-root>/. Brand-workshop does not pre-build a pitch-deck template — pitch-deck reads DESIGN.md directly. Verify: [ ! -d <brand-root>/deck ] && echo OK.Shipping
<brand-root>/ per the folder structure shown in Output Filespresent_files| Skill | When to Use |
|---|---|
pitch-deck (our own) | After this skill, when the founder wants a real investor deck. pitch-deck consumes DESIGN.md (and optionally brand-brief.md + descriptions.md) emitted by this skill. Brand-workshop does not pre-emit a deck template — pitch-deck owns deck construction end-to-end. Do not duplicate deck-construction logic here. |
validation-canvas (our own) | Suggested next step (light gate). After this skill ships the brand kit, the founder is expected to articulate beliefs about market and economics. Brand without a validated market is a logo on a hypothesis. |
riskiest-assumption-test (our own) | Two steps downstream of this skill. Tests the beliefs the validation canvas captures. |
theme-factory (Anthropic) | When the founder wants the design tokens applied to another artifact (landing page, one-pager). Brand-workshop's DESIGN.md is intentionally shaped to feed theme-factory. |
canvas-design (Anthropic) | When the founder wants high-fidelity static brand art (posters, campaign keyart) beyond a logo. Brand-workshop's SVG logo is the minimum viable mark, not a full art direction. |
algorithmic-art (Anthropic) | When the brand direction calls for generative / procedural visual motifs rather than a single mark. |
docx (Anthropic) | When the founder wants the brand brief as a polished Word document (e.g., for a board or investor packet). |
brand-guidelines (Anthropic) | Do not use. brand-guidelines applies Anthropic's own brand look-and-feel; it is not a generic brand-styling skill. |
team-composer (our own) | Instead of this skill when the user wants a discussion on brand strategy rather than a launch-ready identity package. Pure positioning / voice conversations live there, not here. |
Principle: this skill owns net-new visual identity for a business. It
does not refresh existing brands (use brand-voice:* skills), does not model
financials, and does not do customer validation. Artifacts downstream of the
brand folder — decks, canvases, landing pages — are owned by their respective
skills, which consume our output as input.
Graceful degradation: if a referenced skill is not installed, this skill still ships a complete brand folder — the downstream integrations are enhancements, not requirements.
npx claudepluginhub sorawit-w/agent-skills --plugin agent-skillsProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.