/brandware

name: brandware
description: Central brand and style registry manager for the knowledgeware plugin (formerly "steez"). Houses the canonical brandbook .md files, derived token JSONs, and brand assets (logos, wordmarks) that the slideware, knowledgebase, and chartware skills resolve named brands/styles from. Load this skill when (a) a consumer skill needs to resolve a brand/style referenced by name (e.g., "use the AcmeCorp brand", "in the AAB style"), (b) the user asks to add, import, derive, edit, or audit a brandbook, or to set or change the default brand/style, (c) the user wants to derive a style from a live website or import one from a file/Google Drive, (d) the user wants brand assets like logos gathered for a brand, or (e) the user says "brandware" or "steez". Do NOT trigger on generic mentions of branding, marketing, or visual design that aren't about applying or managing a stored visual identity.

brandware — Brand & Style Registry

One registry, many consumers. Brandbooks live here once; slideware decks, knowledgebase sites, and chartware diagrams all render from the same visual identity.

**Plugin root**: `${CLAUDE_PLUGIN_ROOT}` — two directories above this skill's folder (`../../` from here). All paths below are relative to it.

> **Needs the knowledgeware plugin.** The registry and its scripts live at the plugin root. If `../../scripts/list-styles.js` doesn't exist, the skill was installed on its own (for example from a skills directory): tell the user it needs the whole plugin, `/plugin install knowledgeware --marketplace andisab/swe-marketplace`, and stop.

Layout

styles/                    # the registry (plugin root)
├── README.md              # the folder layout, in short
├── style-1/ … style-5/    # 5 default generic styles — marketplace-safe, one folder each (below)
└── brands/                # brandbooks — brand-specific / proprietary (NOT in the plugin repo,
    │                      #   except the checked-in acmecorp example)
    ├── DEFAULT            # optional one-line marker: the registry name to use when no style is named
    └── <name>/            # one folder per brand (same shape as a default style):
        ├── brand.md       #   canonical brandbook — THE source of truth per brand
        ├── tokens.json    #   derived token cache (regenerable; never hand-edit)
        ├── assets/        #   logo-light.svg, logo-dark.svg, mark.svg, wordmark.png, icons … (never mixed across brands)
        ├── css/<name>.css #   optional: tokens as CSS variables + base styles for pages not built by a skill
        ├── css/slideware.css # optional: refinements for html decks, layered over slideware's pattern catalogue
        ├── starters/      #   optional: page, deck or document starters in the brand
        └── README.md      #   what's in the folder, where it came from (provenance), how to use it
<home>/brands/            # the user's own brands — same layout as styles/brands/
    │                      #   (DEFAULT marker, <name>/brand.md …). <home> is $KNOWLEDGEWARE_HOME, else
    │                      #   ~/.claude/knowledgeware (scripts/home.js; `init` creates it); set
    │                      #   $KNOWLEDGEWARE_BRANDS_DIR to keep brands anywhere else. It SURVIVES plugin
    │                      #   updates; its entries shadow plugin entries, and its DEFAULT marker wins.
<project>/.knowledgeware   # OPTIONAL per-project marker: one line naming the brand to use in this
                           #   repository, checked before any DEFAULT marker
scripts/                   # shared tooling (plugin root)
├── registry.js            # the one place that knows the layouts above (used by every loader)
├── load-style.js          # style/brandbook → tokens (with cache)
├── list-styles.js         # discover what's installed
├── derive-style.js        # live website → brandbook .md (heuristic)
├── install-fonts.sh       # install a brand's Google Fonts locally (see §Fonts)
└── fetch-resource.py      # Google Drive URL → local file
skills/brandware/references/
├── brandbook-spec.md      # the .md format every style/brandbook follows (prose layer + optional frontmatter)
├── consumer-contract.md   # what every consumer (adapter) owes, the intent per medium, and where each one's mapping lives
└── chart-styling.md       # how to style data charts (bar/line/pie/KPI) from a brandbook

Rules

0. **One folder per entry.** `<name>/brand.md` plus whatever the brand ships with (tokens cache, assets, css, starters, README). The older flat layout (`<name>.md` + `tokens/<name>.json` + `<name>/assets/`) is still read, and a folder entry wins over a flat file of the same name, so move a brand into a folder whenever you touch it: `mkdir <name> && mv <name>.md <name>/brand.md && mv tokens/<name>.json <name>/tokens.json` (the assets folder is already in place). 1. **The `.md` is canonical, and carries two layers** (see `references/brandbook-spec.md`): a required prose body (heuristically parsed; read directly by chartware/knowledgebase) and an optional YAML frontmatter block of exact tokens that wins over prose heuristics when present. Generators (derive-style.js, the html `.css` import) emit both layers together. Tokens JSON is a derived cache — auto-invalidated by mtime; if anything disagrees, the `.md` wins. 2. **Brands are private; styles are public.** The 5 default styles ship with the plugin. Brandbooks under `styles/brands/` are proprietary/brand-specific content, kept out of the plugin repository (`.gitignore`d) and copied in from a private source repo. Never commit a brandbook to the plugin repo. *Documented exception*: slideware's canonical sample decks (`skills/slideware/pptx/assets/samples/`) include derived token JSONs and rendered previews of publicly-derived identities — they exist to demonstrate layout quality, are not registry entries, and are the only brand-derived content allowed in the repo. 3. **Graceful degradation.** Consumers must work when no br